I-CSCF does have an ISC interface (it is called Ma)?

In case you didn't see it, A couple of weeks ago Aayush posted a great comment on my post correction on Figure 3.13:

I-CSCF has to have an ISC interface. How else will it route incoming INVITE requests addressed to pre-configured sub-domain PSIs to the SIP-AS? Sometimes the I-CSCF sends an incoming INVITE directly to the AS, and the S-CSCF is not required in the signaling path for iFc processing. Similarly, the AS can also send requests to the I-CSCF directly.

I-CSCF and AS interaction is given in TS 23.228, Rel-8..Section 5.4.12.3 point c and Section 5.4.12.5 point c.

Gordon Beith (the Hammer G5 Product Manager and book co-author) and I did some research on this. Gordon found the following:

Actually, it [the AS to I-CSCF interface] was assigned an interface name, Ma, in R7.

In 23.002-710, it lists the following…

This interface between Interrogating-CSCF and the Application Servers (i.e. SIP Application Server, OSA Service Capability Server, or CAMEL IM-SSF) is used to forward SIP requests destined to a Public Service Identity hosted by an Application Server directly to the Application Server.

Details are described in TS 23.228 [34], subclause 5.4.12.

23.228-760 clause 5.4.12.2 states…

1. The HSS maintains the address information of the AS hosting the PSI for the "PSI user". In this case, the AS address information for the PSI is returned to the I‑CSCF in the location query response, in which case the I‑CSCF will forward the request directly to the AS hosting the PSI.

That’s about as much as it says in R8 as well.

We checked our notes and could not find any customer off hand who was implementing the "ISC" on the I-CSCF to check (this does not mean they aren't though). We wrote the book based on R7 which further adds to the confusion. We did make reference to the Ma interface from the VCC AS to the I-CSCF in Section 5.5.2 in the book and Figure 5.9, but not in the Section 3.3.2 that covers the I-CSCF. We will see if we can dig into this a bit more with some customers.

Anyone else out there implementing this spec?

Comments

[Dragos Vingarzan]

Good point Chad! We had the "Ma" interface in the Open Source IMS Core for a long time, yet we never called it "Ma". So yes, there is for sure one implementation that you could test with ;-). (However, the same testbed/non-carrier grade targets of the our project apply also for this item, so don't expect full security or reliability.)

The exact case of the PSI routing is supported by us. And I suspect that many more implementation would support this case because the HSS holds a generic SIP URI of an S-CSCF that would service that identity. This URI could just as well belong to the AS in cause. The I-CSCF might not notice the difference between the Mw and the Ma as newly defined. Anyway, this is more a functional difference that does not affect the immediate signaling routing.

But this is not the only purpose for I-CSCF - AS interface and I think that in this next case the standards should be more clear. For any initial request generated at the AS, the next hop that it should be sent to is an I-CSCF (for both the originating or terminating cases). The reason is that AFAIK there is no specified way for a simple SIP AS to discover the right S-CSCF that it needs to route the messages to and anyway, this is the exact job that the I-CSCF must do.

From our experience in the open source community, we have seen this AS to IMS core network topic quite often. People often start with just one S-CSCF, then the AS routes everything there, to a hard-coded address. Everything works until the testbed grows and the subscribers would get segmented between different S-CSCFs. Then the applications need an unfortunate redesign, for proper routing...

[Gordon Beith]

Thanks for the comment, Dragos. It is interestign to know you have this interface implemented and have some experience with it. From our experience, vendors are still strugglign with the main ISC from S-CSCF to AS as well as the whole I-CSCF function. The I-CSCF is still primarily used for inter-domain routing, and not so much for multi S-CSCF in a singel domain.
Whilst the Ma interface makes soem sense, your other suggestion seems a little unlikely, since if an AS does not know where to locate its S-CSCF, then how does it know where the I-CSCF is? The I-CSCF seems to be the only element that somehow magically knows where all the core elements are, i.e. P-CSCF, S-CSCF, I-CSCF, HSS, and AS.