If you are operating in an environment where a more specialized
standard/profile holds (such as 3gpp/IMS) then you should look there for
guidance on what to do.
If not, then you will need to make up your own policies.
Thanks,
Paul
On 4/3/12 9:07 PM, Romel Khan wrote:
> ITU standards, such as, Q.1912.5, imply From header is used for caller id
> display.
>
> On Tue, Apr 3, 2012 at 3:46 PM, Brett Tate<[email protected]> wrote:
>
>>> But this section 8 is written so generically (eg "However,
>>> any specific behavior is specific to implementations or
>>> services") that it is pretty much saying nothing on
>>> the usage of From header vs P-Asserted-ID.
>>
>> 8. User Agent Server Behavior
>>
>> Typically, a user agent renders the value of a P-Asserted-Identity
>> header field that it receives to its user. It may consider the
>> identity provided by a Trust Domain to be privileged, or
>> intrinsically more trustworthy than the From header field of a
>> request. However, any specific behavior is specific to
>> implementations or services. This document also does not mandate any
>> user agent handling for multiple P-Asserted-Identity header field
>> values that happen to appear in a message (such as a SIP URI
>> alongside a tel URL).
>>
>> However, if a User Agent Server receives a message from a previous
>> element that it does not trust, it MUST NOT use the P-Asserted-
>> Identity header field in any way.
>>
>> If a UA is part of the Trust Domain from which it received a message
>> containing a P-Asserted-Identity header field, then it can use the
>> value freely but it MUST ensure that it does not forward the
>> information to any element that is not part of the Trust Domain, if
>> the user has requested that asserted identity information be kept
>> private.
>>
>> If a UA is not part of the Trust Domain from which it received a
>> message containing a P-Asserted-Identity header field, then it can
>> assume this information does not need to be kept private.
>>
>>
>>> On a feature as simple as which header to use for caller
>>> ID display, so one carrier can try to enforce the From
>>> header while another could use the P-Asserted-ID?
>>
>> It is all about trust. The trust issues were one of the reasons why RFC
>> 5876 is categorized as "Informational" instead of "Standards Track".
>>
>>
>>> Is there no standard pertaining to SIP in IETF and ITU
>>> which clarifies the proper usage?
>>
>> Concerning IETF, see Abstract. 3gpp may be more specific concerning the
>> topic.
>>
>> Abstract
>>
>> This document describes private extensions to the Session Initiation
>> Protocol (SIP) that enable a network of trusted SIP servers to assert
>> the identity of authenticated users, and the application of existing
>> privacy mechanisms to the identity problem. The use of these
>> extensions is only applicable inside an administrative domain with
>> previously agreed-upon policies for generation, transport and usage
>> of such information. This document does NOT offer a general privacy
>> or identity model suitable for use between different trust domains,
>> or use in the Internet at large.
>>
>>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
