[SIPForum-techwg] Question re Application Server

[Paul Kyzivat]

Chris Sibley wrote:

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

Chris, I think this highlights a real problem regarding callerid 
processing. What algorithm *should* the PBX use to decide what to 
display as the calling identity?

As things stand, it must base this on From. But is the From value to be 
trusted?

I guess if the PBX has a contract with the SP, then the contract could 
state that the SP warrants that the From value is valid, and then the 
PBX could trust it for purpose of generating a callerid display. That 
would work for the gateway case that is covered.

But then what about the inter-enterprise case where the SP is acting as 
a proxy? Does the SP warrant the From value in that case? It *could*, to 
some extent, by rejecting any incoming calls from a PBX where the From 
domain is not consistent with the authentication of the source PBX. I 
guess that is out of scope of this document, and could be added later as 
a compatible upgrade. But is it consistent with the expectations of the 
authors?

A related issue is if the UAS is only capable of displaying callerid as 
a number, rather than as a URI. Is it expected to extract the number 
from the From URI whenenver that looks like a number, and/or has 
user=phone, *regardless* of the domain of the URI? In general you are 
not supposed to "interpret" the user part unless it is your own domain, 
even if it has user=phone. I think that can be stretched to allow 
interpreting the user part when one has specific knowledge of the 
conventions used by the domain, which could be assumed when it is the SP 
domain. But I don't think it can be stretched to allow interpretation of 
random other domains, unless part of SIPConnect is a requirement that 
all players have this convention.

I know there is currently no general concensus on exactly how callerid 
should be handled. But I find it very suspect to ever trust using From 
for this unless it is supported by SIP Identity. It would be better if 
 From was always a TEL URI when it is a phone number, and the SP refused 
requests when the From wasn't a phone number assigned to the source. It 
would also be better if P-Asserted-ID was passed to the target PBX, and 
was considered the only trustworthy source of caller identity.

	Paul