[SIPForum-techwg] Thoughts on registration in SIPconnect

[Elwell, John]

> -----Original Message-----
> From: Hadriel Kaplan [mailto:HKaplan at acmepacket.com] 
> Sent: 15 October 2008 15:22
> To: Elwell, John; techwg at sipforum.org
> Subject: RE: Thoughts on registration in SIPconnect
> 
> 
> 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
[JRE] In fact, I had neglected to cover the case where the enterprise
does not have its own domain name or a permanent IP address. However, I
had in mind section 11.4 of the spec, which currently mandates use of
the enterprise domain name. I don't recall reviewing that section.

> 
> 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?)
[JRE] Yes, I think we agreed on this loose routing concept, in which the
AoR of the target (as opposed to the registered contact URI) is in the
Request URI when delivered to the enterprise. But I had assumed this
would have the enterprise domain in the domain part - otherwise, if the
enterprise receives the SP's domain, it is likely either to reject the
request (404) or route it back to the SP, since the enterprise is not
responsible for the SP's domain.

> 
> 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.
[JRE] Yes.

John

> 
> -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
>