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

[David Hancock]

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. 

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.

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