Hello, My clarifications below.
Regards, Laurent Etiemble. Need an IMS Client ? Why don't you try out Mercuro IMS Client. More information at http://www.mercuro.net/ 2009/4/3 john ipds <john.i...@gmail.com>: > Thanks much Laurent! > > I'd like to ask a few clarifications, if you don't mind > > On Fri, Apr 3, 2009 at 12:24 PM, Laurent Etiemble > <laurent.etiem...@inexbee.com> wrote: >> Hello, >> >> My answers below. >> >> Regards, Laurent Etiemble. >> >> Need an IMS Client ? Why don't you try out Mercuro IMS Client. >> More information at http://www.mercuro.net/ >> >> 2009/4/3 john ipds <john.i...@gmail.com>: >>> I understand that the P-Asserted-Identity can include both a tel and a >>> SIP or SIPS URI. I wonder if anyone has any insight into the following >>> questions, particularly with regard to IMS (realizing that PAI is also >>> used outside IMS): >>> >>> >>> 1. Is there any scenario where the PAI MUST include ONLY a tel URI, >>> i.e. where it must never include a SIP (or SIPS) URI instead of/in >>> addition to the tel URI? >> >> When dealing with a MGCF connected to a fixed/mobile legacy networks, >> it can requires to only have a Tel Uri, for ACL or best-cost routing >> reasons. >> > > john: Are you saying that the MGCF _MAY_ include only a tel URI in the > P-Asserted-Identity, or that it MUST send only a tel URI (i.e. it MUST > NOT send anything in addition to a tel URI in the > P-Asserted-Identity)? > According to the equipment the MGCF is connected, it MAY requires a Tel Uri as first PAI for compatibility with legacy equipments that base their processing (ACL, load-balancing, whatever) on a phone number. > >>> >>> 2. Same as above, but where it would be unlikely/unreasonable (as >>> opposed to forbidden) to expect a SIP or SIPS URI instead of/in >>> addition to a tel URI in the PAI? >> >> When dealing with mutli-ringing (both on IMS and legacy networks), the >> SIP Uri is used in the IMS part and the Tel Uri is used in the legacy >> part. >> > > John: Laurent, are you saying that different P-Asserted-Identity would > be sent toward the IMS part and towards the MGCF? Would it be the > S-CSCF that replaces the SIP URI in the P-Asserted-Identity with a tel > URI in the P-Asserted-Identity, upon determining that the call is > bound for the PSTN? Also, is it not possible to send a P-A-I > containing a SIP URI (or containing _only_ a SIP URI) to a MGCF? > The multi-ringing behavior is mostly handled by a TAS (Telephony Application Server), which may require the entire set of IMPU from the IMS part before deciding what IMPU goes on which branches. The possibilities and the setup are endless. >>> >>> 3. Under what circumstances would the provider go out of their way to >>> insert a tel URI when a SIP or SIPS URI already exists? (I'm thinking >>> possibly some IMS emergency calling scenarios) >> >> This can be the case with implicit set of IMPU. An operator assigns >> you a SIP Uri (sip:+33612345...@mobile.fr) with your mobile number, >> and associates an implicit set containing a Tel Uri (tel:+33612345678) >> for outgoing call on fixed/mobile legacy networks. >> > John: Would this be done only when it's known that the call would go > to the PSTN (sounds not very feasible), or would it always be done > because of the implicit set of IMPU? > > The fact that a Tel Uri is associated with a Sip Uri is mostly useful when dealing with equipment that process incoming calls from PSTN. This allow a fast translation from the PSTN addressing to the IMS addressing. >>> >>> 4. Is there ever a case where a PAI contains both SIP/SIPS and tel >>> URIs, and the SIP URI is not a transformation of the tel URI? >> >> This can the case with implicit set of IMPU. An operator assigns you a >> SIP Uri (sip:john....@mobile.fr) with an arbitrary username, and >> associates an implicit set containing a Tel Uri (tel:+33612345678) for >> outgoing call on fixed/mobile legacy networks. >> > John: Thank you, that is a good example. > > >>> >>> 5. Is there ever a case where a PAI contains multiple URIs (e.g. >>> SIP/SIPS and tel), and the URIs do not represent the same entity? >> >> I don't see any valid scenarii for this. >> >>> >>> Thanks for any thoughts >>> _______________________________________________ >>> Sip-implementors mailing list >>> Sip-implementors@lists.cs.columbia.edu >>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>> >> > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
