[SIPForum-techwg] Question re Application Server

Francois Audet audet at nortel.com
Thu Sep 7 17:49:55 EDT 2006 

 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com] 
> Sent: Thursday, September 07, 2006 2:40 PM
> To: Audet, Francois (SC100:3055)
> Cc: Chris Sibley; SIP Forum Tech WG
> Subject: Re: [SIPForum-techwg] Question re Application Server
> 
> 
> 
> 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.

Agree. It should check that the domain in the Request-URI (normally an
IP address by
now) is itself.

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

Agree. 


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

Right, that was my point. No need for a B2BUA to much around with it.

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

I'm OK with that.

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

Correct.

A good example is when you use PSTN gateways, where you can load
balance.

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

I like you clarfifications, and agree with them.

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

Perhaps. I'm not proposing we talk about this last part.

Cheers.

> 	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