[SIPForum-techwg] Question re Application Server
Paul Kyzivat
pkyzivat at cisco.com
Thu Sep 7 17:08:51 EDT 2006
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
> **********************************************************************
>
More information about the techwg
mailing list