[SIPForum-techwg] Question re Application Server

[Paul Kyzivat]

inline

Chris Sibley wrote:
> Paul,
> 
> Once again, very good observations. I still believe that we need to
> maintain the ability for the PBX to register one or more URIs with the
> SP, but it does look like we need to add a little more detail around how
> the registered contact address actually gets used. 
> 
> In general, I agree that the concept of implicitly updating the contact
> address of associated AORs (ala-IMS) probably makes more sense than
> updating a DNS record. In fact, the idea of implicit contact address
> inheritance was actually part of the draft early on but was removed.
> More discussion is needed, of course, to determine how this
> contact-inheritance process would fit into the overall specification.
> 
> That said, I don't think we will be in a position to get all of the
> nuances worked out prior to Tuesday so my suggestion would be to change
> the text as follows. The idea is to go ahead and define the (optional)
> ability for the PBX to register so that we can build on the
> functionality in later versions of the specification..
> 
> Section 7.1, last paragraph:
> 
> The PBX MAY register a contact address against one or more or more SIP
> URIs assigned to it by the Service Provider with the Service Provider's
> SIP Application Server. These URIs MUST be associated with the Service
> Provider's domain/realm.
> 
> Section 7.2, last paragraph:
> 
> 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. The Service Provider MUST NOT use an E.164
> address in the user portion of any such assigned URI. Note that this
> interface specification does not currently define any specific action
> that is triggered by a successful registration.

My immediate goal is to figure out what is intended, whether or not that 
makes it into this version of the spec.  The above eliminates some of 
the confusion, so it is an improvement in that regard. But it certainly 
isn't enough.

The existing comment about the possibility of updating DNS is pretty 
mysterious, but I guess it is a hint to the intent. We could perhaps 
thrash that out here on the list and leave it as a pending agreement for 
a future version.

The reference above to "one or more SIP URIs assigned to it by the 
Service Provider" ... "Application Servers MUST be prepared to accept 
... registrations for any valid URI that the Service Provider has 
assigned to the Enterprise" now raises added questions that it doesn't 
answer:
- is the SP *required* to assign such a URI to each enterprise?
   (Or is this only if it wishes to allow registration?)

- What would it mean for more than one to be assigned to an enterprise?

- What would it mean for a PBX to register to more than one?

- Is there any purpose to these URIs other than to accept
   this registration? What should happen if requests are sent
   to these URIs?

	Paul

> Let me know your thoughts..
> 
> Thanks!
> 
> --Chris
> 
> 
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
>> Sent: Thursday, September 07, 2006 5:09 PM
>> To: Chris Sibley
>> Cc: SIP Forum Tech WG
>> Subject: Re: [SIPForum-techwg] Question re Application Server
>>
>> Chris,
>>
>> I understand a desire to not be overly proscriptive about how things
> are
>> done, so being a bit vague is ok. But there needs to be enough
>> specification about the interactions so that each component can be
>> implemented independently and interoperate. And it doesn't seem like
> it
>> currently meets that bar.
>>
>> Here are some things that seem unclear to me:
>>
>> - if registering is optional, then who gets to decide?
>>    the SP or the PBX?
>>
>> As you describe it below, it seems that the decision must be made
>> consistently by both sides. Namely the registration is required if the
>> PBX doesn't have a static IP address configured for its domain name
>> *and* the SP is in a position to do something with it, such as update
>> the DNS entry.
>>
>> Since registering is apparently necessary to make things work in some
>> cases, and not in others, I think the conditions under which it is
>> needed should be spelled out.
>>
>> - does registering guarantee that requests addressed to the
> enterprise's
>>    domain will in fact be delivered to the address in the registered
>>    contact?
>>
>> E.g. what if the enterprise has a fixed IP address that is already
>> recorded in the DNS, but it registers anyway? Will its fixed address
> be
>> *replaced* by the registered address? Or will it be added in addition,
>> with both being considered candidates? Or will the registered address
> be
>> used *instead* of the DNS entry but without altering DNS?
>>
>> - is it permissible for the contact that is registered to contain a
>>    user part and/or URI parameters? If so, will those be made
> available
>>    to the PBX when requests are routed? How?
>>
>> If the routing is in fact done by updating a DNS server, then I guess
>> these values will be lost. If the registration value is used *instead*
>> of doing a DNS lookup, then they could be made available by including
>> the complete URI in a Route header.
>>
>> - is it permissible for the REGISTER to contain a Path header?
>>    If so, how does that influence subsequent routing of requests
>>    to the enterprise?
>>
>> I assume this is implicitly forbidden, since it probably can't work
> with
>> the envisioned implementation. Would be good to say so.
>>
>> - is it possible that registration will affect requests sent to the
>>    enterprise domain from sources other than the SP? Is that ok?
>>
>> If the approach is to update a DNS server that is publicly accessible,
>> then it could have that effect. Its debatable whether that is a good
>> thing or not. The real problem here is that using REGISTER in this way
>> is an incredible hack, and an abuse.
>>
>> - what happens if a request is targeted at the AOR to which the
>>    enterprise registers? Will that be routed "normally" according to
>>    the registration? Or what?
>>
>> (I'd like to think it would, because anything else would be pretty
>> misleading.)
>>
>> I guess maybe I am thinking about a scope broader than what the
> current
>> document covers, but I'm confused by the relationship of various
>> addresses. If Acme has address sip:++12125551234 at acme.com;user=phone,
>> then it seems to me that
>> sip:++12125551234 at service-provider.net;user=phone will be an AOR
> managed
>> by the service provider, that must be *translated* to the
> corresponding
>> Acme address by the SP. Extrapolating from the current spec, this
>> translation is based on configuration, not registration. Meanwhile,
>> registration is being used, but not to determine routing in the
>> conventional way.
>>
>> Then there is the address that is the registration target. It must be
> an
>> address in the domain of the SP. But it would be very bad if it was
> the
>> SP equivalent of one of the enterprise's phone numbers. (E.g.
>> sip:++12125551234 at service-provider.net;user=phone) It would be bad
>> because once registration is accepted to that it will be *extremely*
>> surprising if a request targeted to that address isn't routed to the
>> registered contact. (It is *legal* but surprising and misleading.) And
>> it would be equally bad if it was a phone number assigned to somebody
>> else. So I guess maybe it shouldn't be a phone number at all. Perhaps
> it
>> would be best if it were something like
> sip:acme.com at service-provider.net.
>> The mechanism of implicit registration sets introduced by IMS blends
>> more harmoniously with SIP. (Not that I love the mechanism.) With it,
>> you register to one of your AORs, and a bunch of associated ones are
>> *implicitly* registered with the same contact. Requests addressed to
> any
>> of those AORs are routed using normal registrar/home proxy methods,
>> replacing the R-URI with the registered contact. Because the same
>> contact is shared by many AORs, a new P-Called-Party-ID header is
> added
>> that contains the untranslated value of the R-URI. I think that might
>> have been a better mechanism to use here, but perhaps it is too late
> for
>> that.
>>
>> 	Paul
>>
>> Chris Sibley wrote:
>>> 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
>>>
> **********************************************************************
> 
> 
> **********************************************************************
> 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 
> **********************************************************************
>