[SIPForum-techwg] Question re Application Server

[Paul Kyzivat]

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.

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.

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

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

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

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