[SIPForum-techwg] Question re Application Server

[Hadriel Kaplan]

Hi Chris - I think we may be in violent agreement. :)
I was not suggesting to NOT specify PSTN service from/to/etc. - the doc
already does that just fine.  I was referring to not specifying other
services' from/to/etc.  That's why I said "this section specifies what the
To/From MUST look like for PSTN...".  In other words, keep what you have
from draft 5, but put in it that the From/To may be different for non-PSTN
based services and leave it at that.

Written as is in this new section 13, the From/To can now look like anything
going to the enterprise, because the service provider must leave it alone if
it comes from another Enterprise.  Nothing says that other originating
Enterprise is a sip-connect one and formats its URIs per SIP-Connect, so it
can be anything - IP Addresses, for example, tel-URIs, etc.  Unless you only
meant sip-connect enterprise through SP to sip-connect Enterprise?

Regardless, I don't care that much either way.  If you want to specify them
as specific formats that's fine with me too.

-hadriel


> -----Original Message-----
> From: Chris Sibley [mailto:chris.sibley at cbeyond.net]
> Sent: Sunday, September 10, 2006 7:14 PM
> To: 'Hadriel Kaplan'; 'Paul Kyzivat'; 'SIP Forum Tech WG'
> Subject: RE: [SIPForum-techwg] Question re Application Server
> 
> Hi Hadriel,
> 
> Comments inline below..
> 
> Thanks,
> 
> --Chris
> 
> > -----Original Message-----
> > From: Hadriel Kaplan [mailto:HKaplan at acmepacket.com]
> > Sent: Friday, September 08, 2006 3:53 PM
> > To: 'Chris Sibley'; 'Paul Kyzivat'; 'SIP Forum Tech WG'
> > Subject: RE: [SIPForum-techwg] Question re Application Server
> >
> > Hi Chris,
> > Inline...
> >
> > > -----Original Message-----
> > > From: Chris Sibley [mailto:Chris.Sibley at cbeyond.net]
> > >
> > > I agree that we need to limit scope, but the points that Paul brought
> up
> > > are hard to ignore. If we don't at least cover the
> > > Enterprise<-->Enterprise scenario then I think we would have a serious
> > > functionality deficiency given the way the text currently reads (i.e.
> > > the SP couldn't route calls between two Enterprises that it services
> > > without being a B2BUA.)
> >
> > Yup, and the part that creates the problem is the doc specifies what the
> > To/From MUST look like when coming from the SP.  We don't have to cover
> > any
> > specific "scenario" if we just say something like: "This section
> specifies
> > what the To/From MUST look like for PSTN-originated calls from the
> Service
> > Provider.  The To and From headers may be different from those
> specified,
> > for other call path scenarios.  For example, the requests may not come
> > from
> > an Application Server at all, but rather through Proxies.  A PBX MUST be
> > capable of using the Request-URI as the target identifier and not the
> > To-URI."  Or something like that.
> >
> >
> 
> Actually, I think there is considerable value in defining what the 'To:'
> and
> 'From:' fields will look like when coming from the SP. The whole point of
> this specification is to define a "profile" of SIP that can be used to
> accomplish a specific function, PSTN interconnection. If we restrict
> ourselves to only defining rules for the Request URI then IMO we
> significantly "water down" the spec.
> 
> At the very least, I think it is very important for the PBX to know in
> advance what URIs will look like in the 'From:' field so that they will
> have
> a predictable format that can be used to properly deliver calling number
> and/or name identification to the callee. Knowing in advance that an E.164
> address will be present in this field is highly useful for delivering that
> feature. I'm pretty sure it would also be useful for a myriad of other
> traditional PBX features.
> 
> > > I'm not sure what you meant by consumer/subscriber. Would this class
> of
> > > user really be fundamentally different enough to warrant different URI
> > > formatting conventions?
> >
> > Yup.  They don't have to be e164 sources at all. (and of course neither
> do
> > "Enterprise" sources) And the parameters can be different.
> >
> > -hadriel
> >
> 
> Again, since this is a profile of SIP for PSTN interconnection why would
> we
> want to use non-E.164 addresses and/or different parameters for these
> users?
> What are the critical factors that would drive the need for them to behave
> differently (in the scope of PSTN interconnection)?
> 
>