[SIPForum-techwg] Overview of Registration Mode - Proposed text

[Elwell, John]

> -----Original Message-----
> From: techwg-bounces at sipforum.org 
> [mailto:techwg-bounces at sipforum.org] On Behalf Of David Hancock
> Sent: 22 April 2009 06:19
> To: Bharrat, Shaun; techwg at sipforum.org
> Subject: Re: [SIPForum-techwg] Overview of Registration Mode 
> - Proposed text
> 
> Hi Shaun,
> 
> I think you have a point, at least as far as the Request-URI host-name
> received by the SP-SSE is concerned. I've been meaning to ask 
> the group
> a question on this, actually.
> 
> We've discussed in-depth the case where the SIP-PBX and 
> SP-SSE share the
> same domain. But we haven't talked much about the case where 
> the SIP-PBX
> has its own domain; i.e., a sub-domain on the SP network, or an
> enterprise domain.
> 
> Say a service provider deploys a few thousand small SIP-PBXs, each
> having a sub-domain on the SP network. For example...
>  - aaa-carpet-cleaners.sp.com
>  - joes-garage.sp.com
>  - doctor-robert.sp.com
>  - cablelabs.sp.com
>  - etc
> 
> In this type of deployment, I doubt the home service provider 
> would want
> to push the E.164-address-to-enterprise-sub-domain translation data to
> the peer networks, due the management overhead, and maybe due to
> competitive data-hiding concerns. Assuming the peer networks are using
> ENUM to translate dialed E.164 numbers to destination SIP 
> URIs, I assume
> the peer network ENUM translations in this type of deployment would
> always return the domain of the SP network (sp.com), and not the
> sub-domain assigned to the target called enterprise.
> 
> This means that when the home SP-SSE receives a request from a peer
> network with a Request-URI such as...
>  - sip:+13036615555 at sp.com;user=phone
> 
> ... and the E.164 number in the Request-URI belongs to an enterprise
> served by the SP network, then the SP-SSE must translate the domain of
> the incoming Request-URI to the domain of the target called enterprise
> before sending the request to the SIP-PBX, for example... 
>  - sip:+13036615555 at cablelabs.com;user=phone
> 
> Is this the way it works? If yes, then I agree the SP-SSE 
> would need to
> update the domain of the Request-URI before sending the request to the
> SIP-PBX. 
[JRE] Yes, that might be acceptable, if the SP has information to map
sip:+1303661555 at sp.net;user=phone to Enterprise Public Identity
+1303661555 at cablelables.com;user=phone.

> 
> The home SP-SSE could also receive requests from peers 
> addressed to the
> correct enterprise domain (say someone calls a GRUU) in which case no
> domain update is needed.
> 
> I'm not aware of the need to update the URI parameters in the incoming
> Request-URI from a peer to include registered contact address
> parameters. I assumed that if these parameters are needed, 
> they would be
> included in the Route header entry containing the registered contact
> address.
[JRE] I think it is positively dangerous to manipulate parameters. For
example, it could cause the loss of a GRUU parameter in the original
request.

John

> 
> Thanks
> David
> 
> > -----Original Message-----
> > From: Bharrat, Shaun [mailto:SBharrat at sonusnet.com]
> > Sent: Tuesday, April 21, 2009 6:09 PM
> > To: David Hancock; techwg at sipforum.org
> > Subject: RE: [SIPForum-techwg] Overview of Registration Mode -
> Proposed
> > text
> > 
> > Dave:
> > 
> > This will probably be clear when we get examples but a question
> > on the following:
> > 
> > > registered. The SP-SSE does this following the normal 
> procedures for
> > routing requests to registered SIP endpoints, except that 
> it skips the
> > request-retargeting step; i.e. based on locally configured data, the
> > SP-SSE does not overwrite the enterprise Public Identity 
> contained in
> > the Request-URI with the SIP signaling address of the SIP-PBX. The
> > SP-SSE identifies the SIP-signaling address of the SIP-PBX in an
> > out-of-dialog request only if the request contains a Route 
> header, as
> > described in Section 17.7.
> > 
> > I was presuming that the above applied to the username but that
> hostname
> > and parameters would be replaced with the registered contact values.
> > 
> > From the current text, it seems that if the IP-PBX registered with
> > REGISTER sip:fqdn1
> > To: <sip:user1 at fqdn1>
> > From: <sip:user1 at fqdn1>
> > Contact: user1 at fqdn2;param=value1
> > 
> > And the SP-SSE got
> > INVITE sip:user2 at fqdn1 SIP/2.0
> > To: sip:user2 at fqdn1
> > From: sip:anybody at anyfqdn
> > 
> > Then according to the text above, what is sent is exactly the above
> and
> > NOT
> > INVITE sip:user2 at fqdn2;param=value1 SIP/2.0
> > To: sip:user2 at fqdn1
> > From: sip:anybody at anyfqdn
> > 
> > Am I interpreting this correctly?
> > 
> > Thanks and cheers,
> > Shaun
> > 
> > 
> > 
> > -----Original Message-----
> > From: techwg-bounces at sipforum.org on behalf of David Hancock
> > Sent: Tue 4/21/2009 6:12 PM
> > To: techwg at sipforum.org
> > Subject: [SIPForum-techwg] Overview of Registration Mode - Proposed
> text
> > 
> > On last week's call, Richard asked me to write some 
> introductory text
> in
> > section 17 that provides an overview of the Registration 
> mode. Here is
> > my 1st-pass attempt at doing that. This is pretty high-level at this
> > point - I could add more detail if people think necessary. I'm also
> > working on a new "Registration Examples" section that hopefully
> provides
> > more details by documenting some of the registration examples we've
> been
> > discussing on the reflector.
> > 
> > 
> > 
> > 
> > 17 Annex A: Registration Mode
> > 
> > 
> > In the Registration mode, the SIP-PBX provides its SIP signaling
> address
> > to the SIP-SSP using the SIP registration procedure defined in RFC
> 3261.
> > In effect, the SIP-PBX registers with the SP network, just like a
> > directly hosted SIP endpoint would register. Once the SIP-PBX has
> > registered, the SP-SSE uses the location binding information
> established
> > during registration to route subsequent dialog-initiating 
> requests to
> > the SIP-PBX.
> > 
> > 
> > 
> > Prior to registration, the SIP-PBX and the SP-SSE are each 
> configured
> > with the enterprise Public Identities served by the SIP-PBX. This
> > includes the single Main Public Identity that identifies the SIP-PBX
> > itself, and the zero or more Alternate Public Identities 
> that identify
> > the individual enterprise users served by the SIP-PBX (see Section 9
> for
> > a more detailed definition of Main and Alternate enterprise Public
> > Identities).
> > 
> > 
> > 
> > When the SIP-PBX first starts up (or comes back online after a
> failure),
> > it registers the assigned Main Public Identity following normal SIP
> > registration procedures. The registration of this single Main Public
> > Identity does two things within the SP-SSE:
> > 
> > *	It creates a binding in the SP-SSE between the Main Public
> > Identity and the SIP signaling address of the SIP-PBX that was
> > identified in the Contact header of the REGISTER request ,
> > *	It implicitly registers the assigned Alternate Public
> > Identities, thus creating a binding between these alternate 
> identities
> > and the SIP signaling address of the SIP-PBX.
> > 
> > 
> > 
> > When the SP-SSE receives an out-of-dialog request containing a
> > Request-URI that identifies either the Main or an Alternate Public
> > Identity assigned to the SIP-PBX, it routes the request to 
> the SIP-PBX
> > using the location binding that was established when the SIP-PBX
> > registered. The SP-SSE does this following the normal procedures for
> > routing requests to registered SIP endpoints, except that 
> it skips the
> > request-retargeting step; i.e. based on locally configured data, the
> > SP-SSE does not overwrite the enterprise Public Identity 
> contained in
> > the Request-URI with the SIP signaling address of the SIP-PBX. The
> > SP-SSE identifies the SIP-signaling address of the SIP-PBX in an
> > out-of-dialog request only if the request contains a Route 
> header, as
> > described in Section 17.7.
> > 
> > 
> > 
> > Thanks
> > 
> > David
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at:  
> http://sipforum.org/mailman/listinfo/techwg
>