[SIPForum-techwg] Question re Application Server

Hadriel Kaplan HKaplan at acmepacket.com
Fri Sep 8 14:09:23 EDT 2006


I think the problem with going down this road is the same problem we had
several months ago, where we go beyond the scope of the doc to cover what an
SP does inside their network, and an end-to-end perspective for one
particular service.  This is an interface spec/profile between an SP and
Ent, and no more.  What the SP does inside their network, whether it be on
one App Server, or on 14 proxies, or just with one PSTN-GW integrated,
doesn't really matter for this doc's purpose.

For example, now you've got a section on Calls originating from another
Enterprise.  What about calls originating from a consumer/subscriber?  Or
calls originating from another service provider?  Or calls originating from
another voip protocol?  Down the slope we go.

But I also agree with Paul/Francois that we should not break an end-to-end
model.  So... can't we just say that PSTN-originated calls will look like
XYZ as defined, but that the enterprise PBX should expect that the To/From
can be different, for example if calls didn't come from the PSTN?


Other comments:

Section 13.2.3 example is not a start line with a request-URI format.
It should be:
INVITE sip:+16789901234 at acmerockets.com;user=phone SIP/2.0

Out of curiosity, why is the display-name of the From example in 13.1.1 set
to the destination Enterprise's name?  I recommend you don't have a
display-name at all, or we get hampered with what should be in it.

Editorial: section 13.1.3, last sentence needs to reference 13.1.2 now, not
13.2.  Also sections 13.2.2 should be 13.2.1, and the To part should be
labeled section 13.2.2.

Section 13.2.2: This is a nit, but I think Paul/Francois' point was that the
App Server should not be mandated to "populate" the To or From fields at
all, it should really act as a Proxy.  (unless of course it is providing an
anonymization service, in which case it does the same as section 13.1.1)

-hadriel


> -----Original Message-----
> From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On
> Behalf Of Chris Sibley
> Sent: Friday, September 08, 2006 10:45 AM
> To: Paul Kyzivat; SIP Forum Tech WG
> Subject: Re: [SIPForum-techwg] Question re Application Server
> 
> Team,
> 
> Attached is the first pass of my edits for Section 13 to address the
> issue that Paul brought up. Please take a look and let me know what you
> think. In case you are not aware, I believe we are scheduled to announce
> the availability of this recommendation on Tuesday so I would appreciate
> your feedback as soon as you can.
> 
> Thanks!
> 
> --Chris
> 
> 
> > -----Original Message-----
> > From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
> On
> > Behalf Of Chris Sibley
> > Sent: Thursday, September 07, 2006 11: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
> 
> 
> **********************************************************************
> 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