[SIPForum-techwg] Question re Application Server

Paul Kyzivat pkyzivat at cisco.com
Thu Sep 7 17:39:14 EDT 2006 


Francois Audet wrote:
> Sorry, I realize I might have been a little brief in my explanation...
> :^)

Disclaimer. I find phone-context potentially very useful, under-used, 
and in need of some further guidelines for use.

But I don't know that it is relevant to the current discussion.

> In most cases, there is really no "phone-context" parameter per say as
> the "+" sign at the begining basically means "global phone-context".
> 
> When receiving a phone number (i.e., "user=phone" parameter is there), 
> the enterprise should route it based on the phone number. The domain
> is irrelevant and would often be an IP address in the Request-URI at
> this point.

AFAIK, the enterprise gets no special dispensation to ignore the domain 
in the R-URI. If it gets a request where the domain of the R-URI isn't 
one belonging to it then it should either forward it toward the 
specified domain or else reject the request.

So I don't think a enterprise (pbx) should be interpreting the phone 
number in the user part unless the domain belongs to it. If it does, 
then it can translate it in order to reach the appropriate UAS.

> And in the To field, it would be the domain of the orininating 
> domain.

What is in the To-URI should be irrelevant. Nobody should be using it 
for anything important.

> If the "+" is used instead of an explicit phone-context, then the
> routing
> is strictly based on the phone number, and the domain is still
> irrelevant.
> This is likely to be the most common cases.

I would simply state this as: if the domain is owned by the server then 
it may route based on the phone number in the user part.

> If the phone-context is there, but is of the for "+XXXX", then the same
> logic
> applies, it is still representing a pure E.164 routing context. Again,
> the
> domain in the To is or Request-URI is irrelevant to the enteprise.

I'm pretty sure that how phone-context is used for routing isn't 
standardized anywhere. But one thing is specified. The following are NOT 
guaranteed to be equivalent:

	sip:+12125551234 at foo.com;user=phone
	sip:1234;phone-context=+1212555 at foo.com;user=phone

(They *could* route to the same places if that is how the phone context 
happens to be defined, but no guarantees.)

I think there is very little we can say about this. Nor need we as long 
as we are using sip URIs. The hard part is how to route
	tel:1234;phone-context=+1212555

That isn't defined either. (But I'm tempted to use enum to translate the 
context and then use that as a Route header while leaving the tel uri 
untranslated.)

> So far, this is pretty simple and obvious.
> 
> If the phone-context is of the form "example.com" or
> "sanjose.example.com", then
> it gives you information about private domain routing. This would
> typically be
> used in "virtual private network" environments. In the context of this
> group,
> this would be a service facilitated by the service provider. This is the
> case I
> was alluding to a little to obscurely.

Yes, its tempting to define that too.

> What this allows you to do is provide a service where a phone number can
> have 
> a meaning that is specific to a certain domain. Let's say example.com (a
> company)
> wants to route through it's different branches using a Service provider 
> example.net. But it wants it's private phone numbers to be routed to. In
> this case,
> the target URI could look like
> sip:2653756;phone-context=example.com at example.net;user=phone.
> 
> The target domain (example.net) is the service provider.
> The phone number domain (example.com) is the phone-context.
> 
> The remote side, when receiving the URI then doesn't care about the
> target domain.
> The To field will remain intact, and the request-URI will probably be
> replaced by some
> IP address. The remote side will be able to route internally using the
> phone number
> and the phone context.

Modulo the comments I made earlier about when it is ok to look at the 
user part, I agree. Note that it doesn't matter whether the 
phone-context is an fqdn or a e164 number.

> This is why we don't need to mandate a B2BUA that "mucks around" with
> the domain
> to make it do the role of the phone-context.

So are I don't think the specification calls for B2BUA behavior *for 
that purpose*. Right now it is solely because the domain name used in 
the To and From is so restrictive that it requires a B2BUA to comply if 
the SP wants to route calls between two different enterprises.

> What I would be proposing is that we describe something like this in the
> document...
> 
> I'm expecting that today, most people are more interested in the simpler
> case of
> pure E.164 numbers as per the beginning of the email, but the virtual
> private
> network stuff is still something I would rather document sooner rather
> than later.
> 
> As a side note, the phone-context idea also allows you to neatly have
> "federation" of 
> private numbers. A company X.com could make it's private numbers
> reachable to company
> Y.com. This is something that traditionally didn't exist in TDM network.
> But with SIP
> and phone-context, it could be easy to do. I can imagine for example
> phones in 
> company X having a special dial prefix (or button) that would result in
> it's partner 
> company Y's phone context to be inserted.

Yes, I have considered that too.

But I find it of marginal utility. Maybe I live a sheltered life, but I 
don't think I have ever worked anywhere that used private numbers for 
anything but really special cases. Everybody has always had an extension 
that maps directly to an E.164 DID number. Special dialing plans simply 
provide abbreviations for E.164 numbers. I know that isn't always true, 
but I bet its getting more true every day. And I bet its mostly the 
little companies where private numbers are used frequently, and those 
are the least likely to have such a special federation arrangement.

So, while conceptually interesting I have doubts if it will ever be a 
compelling feature.

	Paul

>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat at cisco.com] 
>> Sent: Thursday, September 07, 2006 10:21 AM
>> To: Audet, Francois (SC100:3055)
>> Cc: Chris Sibley; SIP Forum Tech WG
>> Subject: Re: [SIPForum-techwg] Question re Application Server
>>
>> Francois,
>>
>> I don't understand what you have in mind for the use of 
>> phone-context in this scenario. Can you clarify?
>>
>> 	Thanks,
>> 	Paul
>>
>> Francois Audet wrote:
>>> I think it would be worthwile to explain the respective usage of 
>>> phone-context and domain when routing.
>>>
>>> In particular, for "incoming calls". 
>>>
>>>> -----Original Message-----
>>>> From: techwg-bounces at sipforum.org
>>>> [mailto:techwg-bounces at sipforum.org] On Behalf Of Chris Sibley
>>>> Sent: Thursday, September 07, 2006 8:21 AM
>>>> To: Paul Kyzivat; SIP Forum Tech WG
>>>> Subject: Re: [SIPForum-techwg] Question re Application Server
>>>>
>>>> Hi Paul,
>>>>
>>>> Firstly, my apologies for taking so long to respond. I 
>> have been on 
>>>> vacation and it's taken a while to dig myself out.
>>>>
>>>> Secondly, thanks for your very astute comments! You are 
>> quite right 
>>>> that, given the current wording, calls between Enterprises 
>> (handled 
>>>> by the SP) would require a B2BUA. When this text was 
>> written, we were
>>>> (only) contemplating calls that ORIGINATED from the PSTN and were 
>>>> destined to an Enterprise. So, in this scenario, since the headers 
>>>> are actually being created for the first time the text would be 
>>>> correct.
>>>>
>>>> However, as you pointed out, there is certainly 
>> significant value in 
>>>> the SP handling calls BETWEEN Enterprises. That said, I 
>> think we need 
>>>> to clarify Section 13 to define rules for calls that 
>> originate from 
>>>> the PSTN (current wording) as well as calls that originate from 
>>>> another Enterprise (and handled by the SP, of course).
>>>>
>>>> What do you think? If everyone agrees I can put together something 
>>>> today / tonight and send it out for your review..
>>>>
>>>> Thanks,
>>>>
>>>> --Chris
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: techwg-bounces at sipforum.org
>>>> [mailto:techwg-bounces at sipforum.org]
>>>> On
>>>>> Behalf Of Paul Kyzivat
>>>>> Sent: Friday, September 01, 2006 1:41 PM
>>>>> To: SIP Forum Tech WG
>>>>> Subject: [SIPForum-techwg] Question re Application Server
>>>>>
>>>>> 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
>>>>
>> *********************************************************************
>>>> * _______________________________________________
>>>> techwg mailing list
>>>> Send mail to: techwg at sipforum.org
>>>> Unsubscribe or edit options at:  
>>>> http://sipforum.org/mailman/listinfo/techwg
>>>>
>

More information about the techwg mailing list