Subject: [Sip] comments on sip-connected-identity

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 Mar 2006 09:46:00 -0500

John,

Firstly, this draft generally looks very good.

Secondly, on the issue of UPDATE without offers, I believe it is fine to 
do this. Though not in RFC3311, this was part of the original conceived 
use of UPDATE (see 
http://www.jdrosen.net/papers/draft-rosenberg-sip-unify-00.txt). We 
decided towards the end of the development to focus on the session 
update aspects of this. However, I think its fine to use UPDATE in this 
fashion, as long as the peer in the dialog indicates support for this 
usage of UPDATE (through the dialogURIChange tag).

Minor comment - option tags are actually case insensitive, so its 
inappropriate to define them using camel case. I'd also suggest a 
shorter tag - id-change.

Reading the document, it occurred to me that there is another possible 
solution for connected identity in the response to the invite. The draft 
says this:

>       The Contact header field provides a contact URI, which may not
>       reveal the identity (Address of Record) of the user on whose
>       behalf the response is sent.

actually, if the UAS supports GRUU, it will in fact reveal the identity 
of the user. The GRUU is normally constructed as:

sip:aor@domain;gruu;opaque=blob

the GRUU spec says that stripping opaque yields the AOR of the user 
corresponding to the gruu. This form isn't used when the gruu is 
anonymous, but of course in such cases you can't get identity from it 
anyway.

Usage of the gruu for identity conveyance has an interesting security 
property. Unlike To/From, its actually used for request routing. If an 
invalid value is placed in the request, any mid-dialog signaling will be 
misrouted and rejected. Thus, there are (some) safeguards against 
falsifying it.

I need to noodle some more on how this fits in, but it is something we 
should consider.

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

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 21 Mar 2006 12:11:01 -0600

> Secondly, on the issue of UPDATE without offers, I believe it is 
> fine to do this. Though not in RFC3311, this was part of the 
> original conceived use of UPDATE 
> (see http://www.jdrosen.net/papers/draft-rosenberg-sip-unify-00.txt). 
> We decided towards the end of the development to focus on the 
> session update aspects of this. However, I think its fine to 
> use UPDATE in this fashion, as long as the peer in the dialog 
> indicates support for this usage of UPDATE (through 
> the dialogURIChange tag).

Jonathan,

I was surprised to hear you indicating that RFC3311 doesn't allow update
without sdp.  Where is it indicated within RFC3311 that update must contain
an offer? 

RFC3311 section 5.1 implies that update can be sent without an offer by
clearly indicating that it can't contain an offer within some situations.
And section 5.2 implies the same thing by discussing receiving an update
containing an offer.

And if bodies are mandatory for update, why does table 1 indicate * instead
of m for content-type?

When update without sdp was discussed for usage within RFC4028, requiring
uas to support timer was never suggested or mentioned.  And such a
requirement is not mentioned within RFC4028.

Thanks,
Brett