Subject: RE: [Sipping] Comments on sipping-calling-party-category-01

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 8 Nov 2005 15:31:28 -0500

Paul,

Would this be solely a tel:URI or could it be a sip:URI ?

Mike

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat (pkyzivat)
> Sent: Tuesday, November 08, 2005 1:32 PM
> To: Rocky Wang
> Cc: James Polk (jmpolk); [email-masked]
> Subject: Re: [Sipping] Comments on sipping-calling-party-category-01
> 
> 
> 
> Rocky Wang wrote:
> > Hi, James,
> > 	The conception is derived from PSTN but it is still 
> very useful in 
> > SIP network. Let's suppose a call from a policeman station, 
> it should 
> > still have the rights and opportunity to override the called user's 
> > barring service.
> 
> That is debatable. (*I* don't think the police have the right 
> to override my desire not to talk to them. And in practice 
> they can't force me to pick up the phone, so what is the point?)
> 
> In practice, this is just an example of the use of Roles. It 
> is indeed useful to have callers categorizable by Role, so 
> that authorization may be done by Role rather than simply by 
> specific identity. I may choose to authorize those with the 
> role of "Family of pkyzivat" and not authorize those with the 
> Role "Police".
> 
> The PSTN has chosen to utilize a limited form of role based 
> authentication and authorization, with just a small number of 
> roles. The particular set of roles chosen seem somewhat 
> arbitrary. Supporting exactly that set in SIP is an 
> accomodation to the PSTN. That isn't a bad thing as long as 
> it makes sense. But I think CPC suffers from having some 
> categories that aren't reasonably understood as roles.
> 
> > 	To interworking with PSTN, I think it is better define 
> a new header 
> > to take this information, and also help for the supplementary 
> > services' implementation in the SIP network.
> 
> I hate to define one header for this small set of roles, and 
> then later have to use an entirely different mechanism for 
> roles in general. But it appears a general notion of role 
> will probably take quite awhile to complete.
> 
> This sounds a bit like the dicotomy between the use of 
> P-Asserted-ID and SIP Identity. There, the P-Asserted-ID is a 
> P- header precisely because it was viewed as being applicable 
> in a limited scope. Using a P-CPC header is a similar approach.
> 
> The place where I have concerns is where the P-CPC may 
> overlap with other mechanisms already in SIP. I posted a note 
> on this some time ago, but there was no response to it. (Copy 
> attached.)
> 
> Given the similarities, it strikes me that CPC perhaps would 
> be better as a parameter on the P-Asserted-ID header than as 
> a new header, as in:
> 
> 	P-Asserted-Identity: <tel:+12125551234>;cpc="police"
> 
> This seems consistent with the view that these are indeed 
> properties of the calling identity.
> 
> 	Paul
> 
> > Best Regards,
> > Rocky Wang
> > 
> > 
> > -----Original Message-----
> > Sender: [email-masked] 
> [mailto:[email-masked]] On 
> > behalf James M. Polk Sent time: 2005年11月4日 11:40
> > Receiver: [email-masked]
> > Subject: [Sipping] Comments on sipping-calling-party-category-01
> > 
> > This ID makes the claim that CPC in the PSTN carries 
> important state 
> > information of the caller to enable it to do special things, to be 
> > continued into SIP signaling as if from the initiator of a 
> dialog (if 
> > it
> > 
> > actually started in the PSTN, and is coming through a GW) or to be 
> > used by a UA going to the PSTN, and defines a header to carry this 
> > information.
> > 
> > Where this is from and goes to the PSTN (over a bridged IP 
> network), 
> > shouldn't RFC3372 define this already?
> > 
> > Where this is starting at a UA, shouldn't this be an assertion in a 
> > more
> > 
> > secure, perhaps even signed, message body?
> > 
> > cheers,
> > James
> > 
> >                                  *******************
> >                  Truth is not to be argued... it is to be presented.
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> > 
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> > 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 11 Nov 2005 08:32:50 +0100

Correction inline

> inline
>
>> inline
>>
>> Jeroen van Bemmel wrote:
>>>
>>>>
>>>>
>>>> Paul Kyzivat wrote:
>>>>
>>>>> Given the similarities, it strikes me that CPC perhaps would be better
>>>>> as a parameter on the P-Asserted-ID header than as a new header, as 
>>>>> in:
>>>>>
>>>>> This seems consistent with the view that these are indeed properties 
>>>>> of
>>>>> the calling identity.
>>>>
>>>>
>>>> Unfortunately, as defined in RFC 3325 PAID cannot have parameters.
>>>
>>>
>>> In that case, you could do
>>> P-Asserted-Identity: <tel:+12125551234;cpc="police">
>>> instead
>>>
>>> As it is a property of the calling entity (like 'lr' is a property of 
>>> the entity performing the routing)
>>
>> This approach presents a number of problems:
>>
>> - it *only* works with phone numbers. (Or do you plan to add
>>   these as SIP/SIPS URI parameters too? If you did that, then
>>   there would be multiple ways to encode this, such as:
>>   <sip:+12125551234;cpc="police"@example.com;cpc="operator">;user=phone
>>
>
> Yes, it would have to be defined as a valid parameters for various URI 
> schemes.
>
>> - addresses with/without the parameter don't compare equal, so
>>     <tel:+12125551234>
>>   isn't equal to
>>     <tel:+12125551234;cpc="police">
>>
>
> That's actually not true:  RFC3261 section 19.1.4 says
> -  All other uri-parameters appearing in only one URI are
>            ignored when comparing the URIs.
>

The above would be true for sip: URIs but not for tel: (RFC3966), so Paul's 
right here

>> I'm dubious of putting all these parameters into tel. They may be of some 
>> value as part of routing translations, but they are especially dubious as 
>> identity assertions. These are attributes of an identity, not part of the 
>> identity. The name can stay the same while the attributes change. (The 
>> police station shuts down, and later on the same number is reassigned to 
>> a porn shop.)
>
> Since the URI is inserted by / asserted by a proxy, the cpc parameter 
> should get updated upon reassignment. Distinguishing porn shops from the 
> police would be the responsibility of the operator.
> It is not uncommon for URI parameters to change: user=phone can become 
> user=ip and vice versa; it's only a temporary property of the identity.
>
> However, there is some inconsistency in using URI parameters versus header 
> parameters. "isfocus" for example is also a temporary property and appears 
> as a header parameter. So "cpc" could be one too, except that PAID 
> apparently does not allow parameters...
>
>
>>
>> Paul
>>
>> Paul
>