[SIPForum-techwg] Question re Application Server

[Chris Sibley]

Hi Paul,

Inline..

Thanks,

--Chris

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: Monday, September 11, 2006 2:28 PM
> To: Chris Sibley
> Cc: Hadriel Kaplan; SIP Forum Tech WG
> Subject: Re: [SIPForum-techwg] Question re Application Server
> 
> 
> 
> Chris Sibley wrote:
> > 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.
> 
> Once you start talking about proxying between enterprises on the same
> SP, the way the UAC constructs the To address becomes ill defined.
Does
> each UAC assume that all numbers not belonging to it belong to the SP,
> and so use the domain of the SP? Or is the originator supposed to
figure
> out that a particular number belongs to a different enterprise and put
> in the correct domain name for that?
> 
> I presume it should use the domain of the SP.
> 

Yes, I agree - it should be the domain of the SP. The SP is providing a
PSTN origination/termination service, thus it *should* be able to reach
any PSTN destination.

> This would be more straightforward with more use of TEL. Then it isn't
> necessary to say what domain owns a number - you can just pass the hot
> potato to the enterprise without making any judgment about that.
> 

I'd personally prefer to use SIP URIs with the understanding that the
user portion will contain an E.164 address. It's been my experience that
support for tel: URIs is not as universally supported in network gear as
it probably should be..

> > 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;
> 
> It certainly does.
> 
> > however, the potential to do this already exists on the PSTN
> > today so we aren't necessarily doing anything "worse" than the
status
> > quo.
> 
> I am not well informed about this, but it is my understanding that in
> SS7 (and I expect ISDN as well) there is an indicator of whether the
> number is trusted. If I had any say in it, I would want the numbers
> displayed to be to either indicate trusted or not, or else to only
> display when trusted. I *hope* that in most cases the numbers are in
> fact trusted, because the came from a trusted source, or in the case
of
> a PBX, that the originating SP verified that the claimed number was
one
> of those assigned to the PBX.
> 
> If in fact most numbers aren't trusted, and are displayed without any
> indication that they are not trusted, then I guess things are so
wedged
> that we could also just display anything and be no worse.
> 

Per my comments on the other thread, I do they think things are that
wedged. :)

> (But, even in that dispicable situation, I think maybe the bar is
higher
> for being able to lie about your identity than it is in sip. So it may
> be more acceptable to display an unverified identity on the pstn but
not
> be ok to do so with a call from a sip source.)
> 

I'm cool with having the SP verify the 'From:' field
enterprise<->enterprise calls, but I'm not aware of any way to do that
for PSTN-originated calls.

> > 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).
> 
> How would you do it for PSTN calls?
> 

Don't know...

> > 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.
> 
> I think the jury may still be out on that one. I don't know the status
> for my own company.
> 
> 	Paul
> 
> > 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
> >
**********************************************************************
> >


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