[SIPForum-techwg] Question re Application Server

[Chris Sibley]

Hey Paul,

I think the main idea here is that the Enterprise is registering a
contact address for a "valid URI that the Service Provider has assigned
to an Enterprise." The intent was not really for the Enterprise to
register a contact address against a particular phone number (PSTN
identity) but rather an (arbitrary) AOR that is associated with the
Service Provider's domain/realm. 

With that in mind, section 7.1 states that DNS NAPTR and SRV lookups
should be the mechanism used for routing requests to the Enterprise's
proxy server (for its associated PSTN identities). So, since we aren't
allowing the Enterprise to register its PSTN identities, the guidelines
in Section 13.3 should still be valid..

So why do we allow a registration from the Enterprise in the first place
(again, against an AOR valid in the Service Provider's domain/realm)?
The main reason is simply to provide a mechanism that the Service
Provider can utilize to dynamically update any DNS (NAPTR/SRV) record(s)
it might have for the associated Enterprise's zone. This admittedly
assumes that the Service Provider would be hosting the Enterprise's
domain on its server(s), which will not be the case for all deployments
(however, the requirement to register *IS* optional). A second (albeit
less important reason) is for "backwards compatibility" with PBX systems
and/or SIP Application Servers that expect a registration to occur. 

Do you think this would be clearer if I added a statement to Section 7.2
that states that the URI assigned by the Service Provider to the
Enterprise MUST NOT be a URI that conflicts with the Enterprise's PSTN
identities?

Thanks,

--Chris

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: Wednesday, September 06, 2006 3:19 PM
> Cc: SIP Forum Tech WG; Chris Sibley
> Subject: Re: [SIPForum-techwg] Question re Application Server
> 
> I have another related question - the relationship of registration to
> routing of requests.
> 
> Section 7.2 says:
> 
> "SIP Application Servers MUST be prepared to accept (but MUST NOT
> require) registrations for any valid URI that the
> Service Provider has assigned to an Enterprise. This interface
> specification does not define any specific action that is triggered by
a
> successful registration; however one possible use of this information
> might be to update a DNS entry associated with the PBX in a DNS zone
> managed by the Service Provider."
> 
> This isn't specific enough to create an interoperable pair of nodes.
> 
> According to 3261, registration updates an abstract location service
> with the provided contact(s). Subsequent routing addressed to the AOR
> results in the request URI being replaced by a registered contact. The
> receiving UAS then determines the target of the request by the value
of
> the R-URI.
> 
> But section 13.3 specifies what the R-URI should be, without regard to
> whether registration has happened or not.
> 
> This seems to suggest that you *forbid* the registration from causing
a
> request addressed to the target of the registration from being
> retargeted to the registered contact. There is in fact no clear
> indication that the registered contact has any relevance to how
requests
> are routed.
> 
> Yet it seems there is some implication that this will determine where
> requests to the enterprise are routed, though without influencing the
> value of the R-URI.
> 
> WIthout getting overly normative, can you clarify what expectations an
> anterprise server (pbx) can expect?
> 
> Does registration to *any* enterprise number affect the routing of
> requests addressed to *all* enterprise numbers? What if there is
> registration ot more than one enterprise number, using different
contact
> addresses? If the registered contact contains a user part, or URI
> parameters, will the UAS receive those in the requests that result?
> 
> 	Thanks,
> 	Paul
> 
> P.S. I'm also still hoping for an answer to my first set of questions,
> below.
> 
> Paul Kyzivat wrote:
> > I am trying to understand the nuances of draft 5, and there is
something
> > I am unsure of: Is the Application Server required to act as a
B2BUA, or
> > is it permitted to act as a proxy? There is no mention of B2BUAs in
the
> > document, but I think it may be implied.
> >
> > In particular, suppose we have one service provider servicing two
> > enterprises: acme.com and bozo.com.
> >
> > Acme has a phone number +12125551234, and Bozo has +14085556789.
Then
> > Acme calls Bozo. According to the spec, the call from Acme is
addressed
> as:
> >
> > 	INVITE sip:+14085556789 at serviceprovider.net;user=phone SIP/2.0
> > 	To: <sip:+14085556789 at serviceprovider.net;user=phone>
> > 	From: <sip:+12125551234 at acme.com;user=phone>
> >
> > But then the instructions for service provider addressing say that
when
> > this is sent to Bozo that it should be addressed as:
> >
> > 	INVITE sip:+14085556789 at bozo.com;user=phone SIP/2.0
> > 	To: <sip:+14085556789 at bozo.com;user=phone>
> > 	From: <sip:+12125551234 at serviceprovider.net;user=phone>
> >
> > To change the To and From fields in this way requires that the
> > Application Server be a B2BUA. If this is routed using proxy
routing,
> > then the message going to Bozo would perhaps look like:
> >
> > 	INVITE sip:+14085556789 at bozo.com;user=phone SIP/2.0
> > 	To: <sip:+14085556789 at serviceprovider.net;user=phone>
> > 	From: <sip:+12125551234 at acme.com;user=phone>
> >
> > So, is it a requirement to have a B2BUA in the path, or is proxy
routing
> ok?
> >
> > 	Thanks,
> > 	Paul
> > _______________________________________________
> > techwg mailing list
> > Send mail to: techwg at sipforum.org
> > Unsubscribe or edit options at:
> http://sipforum.org/mailman/listinfo/techwg
> >


**********************************************************************
This email may contain confidential information. If you are not
the intended recipient, please advise by return email and delete
immediately without reading or forwarding to others.
 -- Cbeyond 
**********************************************************************