[SIPForum-techwg] Question re Application Server
Francois Audet
audet at nortel.com
Thu Sep 7 14:06:04 EDT 2006
Sorry, I realize I might have been a little brief in my explanation...
:^)
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. And in the To field, it would be the domain of the orininating
domain.
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.
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.
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.
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.
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.
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.
> -----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