Subject: RE: [Sip] concerns on draft-elwell-sip-tispan-connected-identity- 01

From: "Elwell, John" <[email-masked]>
Date: Mon, 10 Jul 2006 03:25:36 +0100

Jonathan,

Thanks for reading this and commenting. I will leave the TISPAN guys to
reply on the TISPAN reasons for needing two identities (although this was
discussed at length on an old thread) and their rationale for using PAI for
one / Identity for the other. 

All I can say is that the document lays down a concern that some TISPAN
people have about the connected-identity draft and possible ways to overcome
that concern. One solution, of course, would be to do nothing - leave the
connected-identity draft as it is. But in taking that course we will need to
show that TISPAN requirements can be met by some other means.

John

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 07 July 2006 20:50
> To: IETF SIP List
> Subject: [Sip] concerns on 
> draft-elwell-sip-tispan-connected-identity-01
> 
> I wasn't able to find any disucssion on this draft so far in the 
> archives; my apologies if I missed it.
> 
> This draft concerns me greatly.
> 
> The first thing that worries me is the general idea that 3gpp 
> or tispan 
> get to 'choose' which SIP header field contains what type of 
> identity. 
> They get to do no such thing. These header fields have 
> defined meanings. 
> Having either organization decide to specify their own interpretation 
> for the type of identity that goes in there is a guarnateed 
> receipe for 
> huge, massive, and unending interoperability failures.
> 
> On the technical front, I strongly disagree that the From and 
> P-Asserted-Identity represent different types of identity in any way. 
> They both have always identified the user that is the sender of the 
> request. In cases where you had an enterprise user Joe making a SIP 
> call, the From would contain sip:[email-masked] and this would be 
> authenticated by the proxy in the enterprise, followed by 
> insertion of a 
> P-Asserted-ID which says the same thing. The From, in this use case, 
> should not be sip:enterprise.com.
> 
> Next, I am puzzled by the requirement to deliver separate 
> identities to 
> the calling party for these two things. I understand the concept of a 
> billing identity being separate from the identity of the caller. I do 
> not, however, understand why the billing ID is of any interest to the 
> called party whatsoever. It seems that this would, at best, be of 
> interest only within the domain of the calling party. Since its also 
> directly inferrable from the identity of the caller (presumably the 
> database contains a linkage between the two), I also don't see why it 
> would need to be carried in the sip message itself. Is there 
> a use case 
> where there is not a provisioned relationship between the user making 
> the call and the billing entity? Certainly there is a clear direct 
> relationship in the enterprise example in the draft.
> 
> Finally, even if I buy the idea that there are two identities 
> and that 
> they both need to be conveyed, I strongly disagree with the 
> notion that 
> one of them can be conveyed with SIP-identity, while P-A-ID is OK for 
> the other. There are certain well-known technical limitations with 
> P-A-ID which sip-identity addresses. There is nothing about 
> the nature 
> of the identity which invalidates any of those issues.
> 
> Thanks,
> Jonathan R.
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [email-masked]                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

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

---

From: "Jesske, R" <[email-masked]>
Date: Wed, 12 Jul 2006 13:14:23 +0200

The use of From and P-Asserted Identity for TISPAN Services is discussed within IETF since nearly one year.
Discussion at the Paris and Vancouver Meeting and within the SIPPING and SIPPING-TISPAN mail list.

The use of the From and P-Asserted header for our OIP-OIR (Originating Identification Presentation/Restriction) is inline with the use as defined in RFC3261. The From header is used as a not screened identity directly send from the user where as the P-Asserted-Identity is send by a network entity that can verify the identity of the user. In many cases the sent identity is the same.
But also in some cases the user can have more than one identity. A public (Asserted) and a private (Not asserted) one but both are pointing to the same user. The user could have more than one private identity pointing to his UA or several UAs.
Now in the PSTN world we have PBX using also Public and private identities (one main line e.G. a Company with many extensions e.G. all people working within the company) so we have the same construct as I described for the P-Asserted-Identity and From header.
The PBX is sender and receiver of the Requests and Responses so also originator of the From header and a P-Preferred-Identity that will be verified by a Network element of the trusted Domain. But behind an PBX there could be many private identities of users that could be addressed directly by the private identity and over the asserted identity (switchboard).   

So now for the forward direction the use of From and P-Asserted-Identity for presenting the originating user is clear. In backward direction we can also use the P-Asserted-Identity but a equivalent of the Private identity is missing. So the draft-elwell-sip-tispan-connected-identity- 01 looks fore some possibilities to fulfil this requirements.
These requirements are also documented within draft-jesske-sipping-tispan-requirements-03. 

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Elwell, John [mailto:[email-masked]] 
> Gesendet: Montag, 10. Juli 2006 04:26
> An: Jonathan Rosenberg; IETF SIP List
> Betreff: RE: [Sip] concerns on 
> draft-elwell-sip-tispan-connected-identity- 01
> 
> 
> Jonathan,
>