[SIPForum-techwg] Question re Application Server

[Chris Sibley]

Hi Hadriel,

> Unless you only
> meant sip-connect enterprise through SP to sip-connect Enterprise?

Yes, that really was my intent. The way I look at is we are defining a
profile that governs communications between devices that actually
implement the profile. IMO, everything else (i.e. calls coming from a
non-SIPconnect endpoint) should really be out-of-scope as far as the
specification goes. That is not to say that an enterprise PBX can't or
shouldn't support other URI schemes, only that we are not in a position
to provide guidance for their use.

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

Well, it is true that these fields could look like anything if the
originating Enterprise were not following the outlined conventions for
formatting its 'To:' and 'From:' fields before sending the request to
the SP. However, I think it is reasonable to assume that an endpoint
that is compliant with this profile *should* be following the
conventions so the receiving enterprise would actually be receiving URIs
that are consistent with the guidelines in Section 12.

Of course, there is the question of whether or not the SP should be
checking the contents of the 'From:' field and verifying that the E.164
address and/or display name are valid for the originating enterprise
before forwarding the request. Not verifying the contents would
obviously allow the originating enterprise to spoof the name and/or
number; however, the potential to do this already exists on the PSTN
today so we aren't necessarily doing anything "worse" than the status
quo. Also, if we *did* decide that we should verify the contents for
enterprise-to-enterprise calls it wouldn't be too much of a stretch to
say we should also do it for PSTN-originated (which of course opens up a
whole new can of worms).

Another issue I see is that since we allow the enterprise to use tel:
URIs in the 'To:' field, that would make it necessary for the PBX to
support them (on receipt) as well. I don't think this added requirement
would really be too much of a stretch, however.

Thanks,

--Chris

> -----Original Message-----
> From: Hadriel Kaplan [mailto:HKaplan at acmepacket.com]
> Sent: Sunday, September 10, 2006 10:54 PM
> To: Chris Sibley; 'Paul Kyzivat'; 'SIP Forum Tech WG'
> Subject: RE: [SIPForum-techwg] Question re Application Server
> 
> 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)?
> >
> >
> 



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