[SIPForum-techwg] Registration mode and contact URIs

[Elwell, John]

> -----Original Message-----
> From: David Hancock [mailto:D.Hancock at CableLabs.com] 
> Sent: 26 February 2009 23:03
> To: Elwell, John; techwg at sipforum.org
> Subject: RE: [SIPForum-techwg] Registration mode and contact URIs
> 
> John -- comments inline below...
> 
> David
> 
> > -----Original Message-----
> > From: techwg-bounces at sipforum.org 
> [mailto:techwg-bounces at sipforum.org]
> On
> > Behalf Of Elwell, John
> > Sent: Thursday, February 26, 2009 3:25 AM
> > To: techwg at sipforum.org
> > Subject: [SIPForum-techwg] Registration mode and contact URIs
> > 
> > Continuing the discussions on registration mode from the 
> last call, I
> > would like some opinions on contact URIs.
> > 
> > When the SIP-PBX sends a dialog-forming request or 
> response, it needs
> to
> > send a contact URI. For various reasons it may need to be globally
> > routable. For example:
> > 
> > 1. Attended call transfer or similar feature within the SP 
> may result
> in
> > delivery of a future out-of-dialog request to that contact URI
> > containing a Replaces or Join header field.
> > 
> > 2. Following an emergency call, a return call from the PSAP to the
> > particular UA that made the emergency call.
> 
> [dch] This would apply only to IP-based PSAPs, correct? i.e., unlikely
> to be encountered in the near/medium term. A PSTN-based PSAP 
> could only
> call-back an E.164 number, which would get translated to an AOR.
[JRE] Correct. So the question is whether we want to allow in SIPconnect
1.1 behaviour that might not be consistent with IP-based PSAPs in the
future.

> 
> > 
> > (Note that globally routable does not necessarily mean that the GRUU
> > mechanism has been used between the enterprise UA and the enterprise
> > registrar/proxy to obtain the URI.)
> 
> [dch] I agree that the contact doesn't necessarily need to be a GRUU.
> But it would be nice if it was a GRUU, because it tells the remote
> entity "this is globally routable". Without this assurance, the remote
> entity might reasonably assume the received contact isn't globally
> routable, and therefore not use it. 
[JRE] If it is globally routable I think it can be marked as a GRUU,
even if it does not use the GRUU mechanism between the UA and the
SIP-PBX. This is because many SIP-PBXs function as B2BUAs and map the
contact URI used between the UA and the B2BUA onto a different contact
URI used for trunking. Therefore the latter might be globally routable
whereas the former is not. I think the latter could still be claimed to
have GRUU properties and could be flagged as a GRUU.

> 
> What I've heard is -- most endpoints that don't support GRUU 
> also don't
> provide a globally routable contact address. 
[JRE] Yes, but see above.

> As a result, remote
> endpoints and applications that want to reach that non-gruu-enabled
> registered instance don't use the received contact. Instead, they use
> other techniques to reach the target registered instance. For example,
> for the attended call-transfer case, refer-to the transfer-to AOR
> instead of the contact, knowing that only the intended target will
> recognize the dialog identified in the Replaces header. This is what
> I've heard via the grapevine -- others may have more accurate data on
> what's actually happening in current deployments.
> 
> Bottom line -- are we likely to see requests addressed to 
> contacts that
> aren't GRUUs?
[JRE] I am not sure, but possibly not if SIP-PBXs are able to use
globally routable contact URIs as described above and these can be
marked as GRUUs. So would it be an excessive burden on SIP-PBXs always
to mark their contact URIs as GRUUs? Of course, if IP addresses are used
in the domain part and NATs are involved, this is a problem. But we are
trying to get away from that.

> 
> > 
> > During the meeting we discussed 3 possibilities for the domain used
> for
> > AoRs (Enterprise Public Identifiers).
> > 
> > If the enterprise uses its own domain name, or is delegated
> > responsibility for a sub-domain of the SP's domain, the 
> enterprise has
> > responsibility for the domain part and can assign whatever user-info
> > parts it likes.
> > 
> > So for example, if using its own domain name (enterprise.com), the
> > enterprise could issue a contact URI something like:
> > sip:ag43T5cU at enterprise.com
> > 
> > Registration would need to implicitly register 
> *@enterprise.com (where
> *
> > is the complete set of user-info parts when user=phone is not used),
> and
> > on receiving a request addressed to sip:ag43T5cU at enterprise.com it
> would
> > need to route that request to the registered contact for the SIP-PBX
> > using the transport that has been established at registration time
> > (e.g., a TLS connection).
> > 
> > Similarly if using a sub-domain of the SP's domain, a 
> contact URI like
> > sip:dcv765G7 at enterprise.sp.net would be handled in a similar way.
> > 
> > Is that folk's understanding? If not, how do folks think it would
> work?
> 
> [dch] Yes, this lines up with my understanding.
> 
> > 
> > The case where the SP's domain itself is used, without delegating a
> > sub-domain to the enterprise, is much more problematic. How does the
> > enterprise choose contact URIs that do not conflict with other URIs
> used
> > by the SP and its other customers?
> 
> [dch] This shouldn't be a problem for Public GRUUs, since a 
> Public GRUU
> reveals the associated Public Identity. The SP network can ignore the
> "gr" parameter, and normal (loose) routing will deliver the request to
> the SIP-PBX. (Which is another reason I prefer GRUUs over globally
> routable contacts that aren't GRUUs.) 
[JRE] I am not sure. Even for a public GRUU, the constraint is only that
the user part contains the AoR, but the AoR might not be one that the SP
is aware of, particularly if the call has come from a different part of
the enterprise not normally served by that particular SP.

> 
> I agree this is a problem for temporary GRUUs, and at this 
> point I don't
> see a solution. Maybe the shared-domain option can't be used when the
> SIP-PBX supports GRUU (especially if it uses temp-GRUUs). 
[JRE] Yes, that was where I was heading.

John


> 
> > 
> > John
> > 
> > _______________________________________________
> > techwg mailing list
> > Send mail to: techwg at sipforum.org
> > Unsubscribe or edit options at:
> > http://sipforum.org/mailman/listinfo/techwg
>