[SIPForum-techwg] Question re Application Server

[Paul Kyzivat]

Chris Sibley wrote:

>> 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?
>>
> 
> Not any more or less so than the caller-ID information delivered from
> the PSTN (over a TDM connection) today... 

>> 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.
>>
> 
> Since the SP can't 100% verify the CID information received from the
> PSTN then I don't think that it could warrant to an enterprise that the
> contents of the 'From:' field will be valid in any case.

I think that is not so clear.

Please correct me if I am wrong, but I think the SPs have a contractual 
transitive trust relationship with one another. And they have a way to 
indicate that a number they are reporting is not trusted. When 
connecting a PBX, I think the SP is obligated to either:
- have a contractual transitive trust relation with the PBX operator
- check that the number reported by the PBX is one it is authorized
   to use
- mark the number provided by the PBX as untrusted.

If the above is true, then either the received number is marked 
untrusted, or else it is trusted based on a chain of transitive trust 
backed up with legally enforceable contracts.

That is stronger than taking a SIP From header on blind faith.

(I should check my Vonage subscriber agreement to see if I am legally 
prevented from causing my UA to lie about its identity.)

It would be interesting to see some lawsuits over forged caller id.

>> 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?
>>
> 
> Well, I guess the SP could verify that the domain in the 'From:' field
> is valid for the originating enterprise but this would still not prevent
> the enterprise from asserting an E.164 address in the user portion of
> the URI that didn't belong to it (on the PSTN).

Technically there is nothing wrong with this because the user part of a 
URI is only interpreted within the scope of the domain name. So

- sip:+19785551234 at atlanta.com;user=phone
- sip:+19785551234 at biloxi.com;user=phone

are both valid URIs belonging to their respective domains. However only 
one of them is equivalent to:

- tel:+19785551234

and there is no way to tell which by inspection. This is why it is 
dangerous in general to take a sip uri and display only the numeric 
portion. Doing so assumes it is equivalent to the tel form.

IMO the preferred approach is to only use the P-Asserted-ID header as 
the source for callerid info, and to use tel in that when a phone number 
is to be displayed. Or at worst, use the number from a sip uri in P-A-ID 
only when the the contractual arrangement says it is ok to do that.

> I think this would also be the case even if the identity headers are
> used. When identity is used, I believe that the responsibility for
> inserting the 'Identity:' and 'Indentity-Info:' headers would be on the
> originating enterprise's proxy server, not the SP's. 

It doesn't matter who inserts the identity header. It is the cert 
authority for the identity that matters.

But yes, unless some special kind of cert is defined for this, you could 
get an identity cert for both the atlanta.com and biloxy.com URIs with 
the same number in them. Jon Peterson has avoided having SIP Identity 
treat tel URIs, because it is hard. So we won't find a solution there.

So if this is to be solved at all (in order to give *any* validity to 
sip callerid of phone numbers), then I think it must for now be a 
transitive trust solution, probably with the SP with the responsibility 
for either preventing improper usage of numbers, or else refusing to 
assert identity for them.

>> 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.
>>
> 
> Since this is just a profile of SIP, I don't think it is unreasonable to
> say that all players must be using the conventions as defined. That
> said, the PBX needs some way of determining when to apply the
> rules/conventions associated with the profile. Perhaps we should add
> some guidelines around checking the 'Via:' header to make sure the
> request came from the SP's proxy vs. some other proxy (that doesn't
> implement the profile.)

The solution I prefer is to base it on P-Asserted-ID. The SP should not 
assert an identity unless it can verify that it is valid. Unfortunately, 
you guys have chosen to preempt P-A-ID for a different purpose.

My alternative is for the SP to verify the From, and reject requests 
where it cannot be verified. However that has a serious downside - I 
think it means that all calls from the PSTN must be rejected if the 
caller's identity cannot be verified.

>> 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.
>>
> 
> I'm not sure that using a tel: URI in the 'From:' field is a good idea
> if we want to start using the identity headers in the future. 

Well, there is that.

Better I guess to rely on P-Asserted-ID, which can be used in 
conjunction with SIP Identity. Using a TEL in a P-A-ID isn't a problem. 
Using a sip with a clear understanding that the number in it will be 
valid is also not too much of a problem.

	Paul

> <snip from RFC 4474>
> 
> .
> Implementations that intend to send their requests through an
> authentication service SHOULD put telephone numbers in the From header
> field into SIP or SIPS URIs whenever possible.
> .
> 
> </snip>
> 
>> 	Paul
> 
> 
> **********************************************************************
> 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 
> **********************************************************************
>