[SIPForum-techwg] Thoughts on registration in SIPconnect

[Hadriel Kaplan]

I think we agreed in Denver that registering an Enterprise's domain into an SP would be a valid use-case, but the more rare case.

Just to make sure we're on the same page, the more common case was the Enterprise would register an AoR in the SP's domain, such as:
sip:+123456000 at serviceprovider.net;user=phone

And I think we agreed in that case that if a call came to the SP destined to the Enterprise, such as:
sip:+1234561234 at serviceprovider.net
That the Service Provider would not change the req-uri to the registered AoR's Contact-uri, but rather just insert a Route header to the registered contact.  Right? (or am I forgetting what we agreed to?)

That's still consistent, BTW.  In this case no retargeting is occurring, because the target is within the same domain context.  In the Enterprise.com registered case, it is a retarget because it's changing the domain context.

-hadriel


> -----Original Message-----
> From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On
> Behalf Of Elwell, John
> Sent: Tuesday, October 14, 2008 12:00 PM
> To: techwg at sipforum.org
> Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect
>
> I have had some off-line discussions with some IETF experts, and I have
> detected some concern about the direction that SIPconnect is heading
> with its use of registration. There was already concern during the
> Denver meeting about the complexities of the registration-based
> approach.
>
> I could try to summarise the registration-based approach as follows:
>
> With registration, a PBX to registers a default AoR such as:
>         sip:+123456000 at enterprise.com;user=phone
> and as a result can receive all inbound requests to that enterprise.
>
> In principle, this should mean all requests targeted at
> sip:*@enterprise.com, e.g.:
>         sip:alice at enterprise.com
>         sip:12345 at enterprise.com
>         sip:+123456789 at enterprise.com;user=phone
> should be delivered to the PBX.
>
> In these cases, the domain part is enterprise.com, so the SP shouldn't
> look at the user part.
>
> However, in practice, the SP is also going to receive requests targeted
> at, for example:
>         tel:+123456789
>         sip:+123456789 at serviceprovider.net;user=phone
>
> In these cases, the E.164 number is "assigned" to enterprise.com, the SP
> needs to recognise this and forward the request to the PBX, but with,
> enterprise.com in the domain part (otherwise the PBX will reject the
> request, or try to forward it back to the SP). So it would end up being
> forwarded as:
>         sip:+123456789 at enterprise.com;user=phone
>
> The fact that the PBX has registered really makes no difference to the
> SP's decision to forward a request to the PBX:
> - whether or not the PBX has registered, requests targeted at
> *@enterprise.com need to be delivered to the PBX;
> - whether or not the PBX has registered, requests targeted at an E.164
> number assigned to the PBX need to be retargeted to a SIP URI with
> enterprise.com in the domain part, and then delivered to the PBX as
> above.
>
> The only difference that registration makes is that it provides a "flow"
> over which requests can be delivered (rather than using RFC 3263 to
> determine where to route to) and that "flow" is kept alive.
>
> It seems that a similar result could be obtained by using connection
> re-use and some sort of keep-alive (e.g., SIP OPTIONS). For example, the
> PBX could establish a connection to the SP using OPTIONS and keep it
> alive using OPTIONS, and the SP could re-use this connection for inbound
> requests to the PBX. This would avoid the use of REGISTER, and would be
> closer to SIPconnect 1.0 (where the PBX was not required to register).
>
> By doing something like this, we could converge on a single mode of
> operation and keep the basic implementation requirements to a minimum.
>
> If something along these lines does not satisfy requirements, let's get
> the requirements on the table so that we can see which items in the SIP
> tool kit would do the job.
>
> John
>
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at:
> http://sipforum.org/mailman/listinfo/techwg