Subject: RE: [Sipping] URIs for Gateways

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 6 Jan 2003 16:21:42 -0500

I agree with this.  I'm confused by those who seem to think that
P-Asserted-Identity is needed when the long term solution is
fully baked.  If the UA knows its identity, which seems
reasonable, then it can "assert" it, and have that assertion
validated by a trusted entity using cryptographic means.
That is the fundamental idea I get out of Jon's proposal.
The only circumstance where that won't work is where the
UA doesn't know its identity.  I don't see that as a problem
on any network I'm aware of, but ...... keep reading.

I do think there is a problem which this whole thread talks about.
The basic reality is that many users of SIP UAs will have two
identities - a SIP URI and a telephone number.  It may be
necessary to assert both identities in one call, because the
originator of the call does not know which identity may be
needed.  There is no current header to do this.  I think that 
it is advantageous to have a proxy be able to assert the phone 
number.  Otherwise EVERY UA will have to be able to understand 
that two identities are possible, know them both by some 
unspecified means, and assert them in every call on every UA.  
This seems unreasonable.  I'm not sure that there is a reason
to have both identities validated, but there could be.

Brian
> -----Original Message-----
> From: Peterson, Jon [mailto:[email-masked]]
> Sent: Monday, January 06, 2003 2:06 PM
> To: 'Drage, Keith (Keith)'; Rosen, Brian; 'Henning Schulzrinne'
> Cc: [email-masked]'
> Subject: RE: [Sipping] URIs for Gateways
> 
> 
> 
> RFC3325 was 'short-term' because it was achievable in the 
> short-term and has
> a more limited (but still useful) applicability. The 
> long-term identity
> solution must be a superset of the functionality of 
> short-term - it must
> address the short-term scope of applicability, but also 
> encompass general
> needs for network assertion (which SIP does have). 
> Accordingly, it takes
> longer to develop. At such a time as there is a workable 
> long-term solution,
> it would be pointless to allow both to be SIP standards 
> except as part of a
> transition plan. So in that sense, I disagree - one is a 
> short-term solution
> of the other.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: Drage, Keith (Keith) [mailto:[email-masked]]
> > Sent: Friday, January 03, 2003 8:20 AM
> > To: Rosen, Brian; 'Henning Schulzrinne'
> > Cc: [email-masked]'
> > Subject: RE: [Sipping] URIs for Gateways
> > 
> > 
> > Network asserted identity (RFC 3325) is the real network 
> > asserted identity. It is a P header not because it is 
> > preliminary, but because the whole idea of network assertion 
> > is not generally applicable to all SIP architectures. For RFC 
> > 3325 a trust domain needs to exist between proxies that use 
> > the P-Asserted-Identity in order to guarantee the privacy, 
> > this does not exist in all SIP networks. In does in 3GPP and 
> > therefore 3GPP are using RFC 3325.
> > 
> > If you want to let the 1et outbound proxy assert identity on 
> > your behalf then use RFC 3325. If you want to let application 
> > servers with whom you have a secure relationship assert your 
> > identity, then use Jon Petersons drafts, when they eventually 
> > become RFCs. 
> > 
> > One is not a short term solution for the other.
> > 
> > Keith
> > 
> > Keith Drage
> > Lucent Technologies
> > Tel: +44 1793 776249
> > Email: [email-masked] 
> > 
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:[email-masked]]
> > > Sent: 02 January 2003 20:49
> > > To: 'Henning Schulzrinne'
> > > Cc: [email-masked]'
> > > Subject: RE: [Sipping] URIs for Gateways
> > > 
> > > 
> > > Yeah, I actually thought of just allowing a display name in the
> > > Request URI and using that, but it seems so foolish to make 
> > a change,
> > > and have that change not be exactly what we needed.
> > > 
> > > We could use NAI.  I suppose we could use a P-Asserted-Identity
> > > with a tel URI:  
> > > P-Asserted-Identity tel:+17247426826
> > > 
> > > What do we do when the "real" NAI happens?
> > > 
> > > Brian
> > > 
> > > > -----Original Message-----
> > > > From: Henning Schulzrinne [mailto:[email-masked]]
> > > > Sent: Thursday, January 02, 2003 3:10 PM
> > > > To: Rosen, Brian
> > > > Cc: [email-masked]'
> > > > Subject: Re: [Sipping] URIs for Gateways
> > > > 
> > > > 
> > > > > I'd like to get a new header for the calling party number on
> > > > > an outbound call.  That way, the translator can be a proxy and
> > > > > add the header.  I'd recommend that gateways allow the number
> > > > > to be in the From.   
> > > > 
> > > > Generalized, you want something like the Request-URI 
> that can be 
> > > > modified or inserted. How about the NAI stuff?
> > > > 
> > > _______________________________________________
> > > 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
> 
_______________________________________________
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: [email-masked]
Date: Tue, 7 Jan 2003 09:47:14 +0200

> to have both identities validated, but there could be.

if your proxy receives a call from sip:[email-masked] who has also been
allocated a phone number +1234567890, why can't is add an asserted
identity header containing sip:[email-masked] to the call in case
the call is bound to pstn?  why would you need yet another header for
that purpose?

-- juha