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

From: "Elwell, John" <[email-masked]>
Date: Tue, 28 Mar 2006 17:24:05 +0100

Brett,

OK, I understand. For this particular usage the dialogURIChange tag solves
the problem anyway, regardless of whether it is allowed in more general
circumstances.

John 

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]] 
> Sent: 28 March 2006 17:12
> To: Elwell, John; 'Jonathan Rosenberg'; 'IETF SIP List'
> Subject: RE: [Sip] comments on sip-connected-identity
> 
> > I am getting confused by this thread. In my opinion Jonathan 
> > clearly stated that UPDATE without SDP offer is allowed.
> 
> Yes; he mentioned that it is allowed.  However it wasn't 
> clear to me and
> some others if Jonathan was indicating that UPDATE without 
> SDP is valid per
> rfc3311 or if the dialogURIChange tag is what allows it to be 
> valid.  And
> since this is a common UPDATE interoperability problem, I was 
> just seeking
> clarity concerning his comment.
> 
> The following is the snippet from
> http://www1.ietf.org/mail-archive/web/sip/current/msg13586.html.
> 
> 
> "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)."
> 
> 
> 

_______________________________________________
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: "Francois Audet" <[email-masked]>
Date: Tue, 28 Mar 2006 19:12:57 -0600

RFC4028 (http://www.ietf.org/rfc/rfc4028.txt) describes the 
use of UPDATEs without Offers (in this case it is for keep-alive).

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Monday, March 27, 2006 22:47
> To: Brett Tate; 'Christer Holmberg'; 'Jonathan Rosenberg'; 
> 'IETF SIP List'

---

From: "Jesske, R" <[email-masked]>
Date: Wed, 29 Mar 2006 10:02:39 +0200

Sorry for bringing this again, why we have to use the UPDATE to get the connected identities with the changed From and to header? This is increasing SIP message flow for only sending a identity.

There could be also other possibilities.

Why not change the from in the 200 OK

or

define a new final Response like a 20X that is sent instead of the 200 OK --> Problem are the existing implementations. Sending a 20x before a 200 (20x no provisional response)

or

define a new provisional response that is only used to send the regarding connected information (change of from header).

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Francois Audet [mailto:[email-masked]] 
> Gesendet: Mittwoch, 29. März 2006 03:14
> An: Elwell, John; Brett Tate; Christer Holmberg; Jonathan 
> Rosenberg; IETF SIP List
> Betreff: RE: [Sip] comments on sip-connected-identity
> 
> 
> I should have said "session refresh" instead of "keep-alive".
> 
> > From: Audet, Francois [SC100:3055:EXCH] 
> > Sent: Tuesday, March 28, 2006 17:13
> > To: 'Elwell, John'; 'Brett Tate'; 'Christer Holmberg'; 
> > 'Jonathan Rosenberg'; 'IETF SIP List'

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 29 Mar 2006 12:49:52 +0100

Roland,

Changing the From (or the To) URI in a response would undermine the rules
for transactions in SIP. It was stated during the SIP meeting at IETF65 that
we should not do this. So the alternative is to convey information in some
other header or body in the response. Feng Cao addresses this in his
response identity draft, although that received some comments during IETF65
and will need to be reworked. The problem always is whether the UAS can be
authenticated - as I have stated before, this is only if the request has
been delivered over a TLS connection over which the UA has already been
authenticated. I suggest you collaborate with Feng if you want this, but
personally I am not convinced that an adequate solution will be found.

In the meantime we have a simple solution using connected-identity, which in
any case is needed for other situations.

John

> From: Jesske, R [mailto:[email-masked]] 
> Sent: 29 March 2006 09:03
> To: [email-masked]; Elwell, John; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: AW: [Sip] comments on sip-connected-identity
> 
> Sorry for bringing this again, why we have to use the UPDATE 
> to get the connected identities with the changed From and to 
> header? This is increasing SIP message flow for only sending 
> a identity.
> 
> define a new final Response like a 20X that is sent instead 
> of the 200 OK --> Problem are the existing implementations. 
> Sending a 20x before a 200 (20x no provisional response)
> 
> or
> 
> define a new provisional response that is only used to send 
> the regarding connected information (change of from header).
> 
> Best Regards
> 
> Roland
> 
>

---

From: "Feng Cao \(fcao\)" <[email-masked]>
Date: Wed, 29 Mar 2006 09:53:14 -0800

The alternatives you brought up still need one mechanism to protect the integrity of the connected-id. UPDATE leverages the identity work from Jon and Cullen. That is the reason that this connected-id issue can be easily covered by the identity work.

Why not just insert response identity into response? This is more generic and requires no additional response code ...  

-----Original Message-----
From: Jesske, R [mailto:[email-masked]] 
Sent: Wednesday, March 29, 2006 12:03 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Jonathan Rosenberg (jdrosen); [email-masked]
Subject: AW: [Sip] comments on sip-connected-identity

or

or

Best Regards

Roland

> An: Elwell, John; Brett Tate; Christer Holmberg; Jonathan Rosenberg; 
> IETF SIP List
> > To: 'Elwell, John'; 'Brett Tate'; 'Christer Holmberg'; 'Jonathan 
> > Rosenberg'; 'IETF SIP List'
> > RFC4028 (http://www.ietf.org/rfc/rfc4028.txt) describes the use of 
> > UPDATEs without Offers (in this case it is for keep-alive).
> > 
> > > To: Brett Tate; 'Christer Holmberg'; 'Jonathan Rosenberg'; 'IETF 
> > > SIP List'
> 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: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 31 Mar 2006 14:05:43 +0200

Hi,
 
The To header affects the transaction rules only in RFC2543 - in RFC3261 it is not used - so if a client supporting dialogUriChange would have to be RFC3216 compliant I see no problem with changing the header in the response.

Now, one can say that intermediate proxies may still be RFC2542 compliant, but in that case you could have problems (with stateful proxies) even if you change the URI in another request within the dialog. The draft does not cover that.

So, the question is really: how many proxies are there out there who still use the To header URI from transaction identification?

Also, a problem with UPDATE is that there is always a risk for race conditions. For example, the UAC may send an UPDATE (e.g. to change codecs and/or mode) itself when receving 200 OK, so if it RECEIVES an UPDATE at the same time it will have to reject (491) that (I assume you can not have two UPDATE transactons, even if one does not contain SDP).

Regards,

Christer

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 29. maaliskuuta 2006 14:50
To: Jesske, R; [email-masked]; [email-masked]; Christer Holmberg (JO/LMF); [email-masked]; [email-masked]
Subject: RE: [Sip] comments on sip-connected-identity

Roland,

Changing the From (or the To) URI in a response would undermine the rules for transactions in SIP. It was stated during the SIP meeting at IETF65 that we should not do this. So the alternative is to convey information in some other header or body in the response. Feng Cao addresses this in his response identity draft, although that received some comments during IETF65 and will need to be reworked. The problem always is whether the UAS can be authenticated - as I have stated before, this is only if the request has been delivered over a TLS connection over which the UA has already been authenticated. I suggest you collaborate with Feng if you want this, but personally I am not convinced that an adequate solution will be found.

In the meantime we have a simple solution using connected-identity, which in any case is needed for other situations.

John

> Sorry for bringing this again, why we have to use the UPDATE to get 
> the connected identities with the changed From and to header? This is 
> increasing SIP message flow for only sending a identity.
> 
> define a new final Response like a 20X that is sent instead of the 200 
> OK --> Problem are the existing implementations.
> define a new provisional response that is only used to send the 
> regarding connected information (change of from header).
> 
> Best Regards
> 
> Roland
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 31 Mar 2006 14:24:19 +0100

Christer,

See below.

John 

> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: 31 March 2006 13:06
> To: Elwell, John; Jesske, R; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; Drage, 
> Keith (Keith)
> The To header affects the transaction rules only in RFC2543 - 
> in RFC3261 it is not used - so if a client supporting 
> dialogUriChange would have to be RFC3216 compliant I see no 
> problem with changing the header in the response.
[JRE] You are correct. But some objection was raised at the meeting to
changing the To header in a response compared to that in the request. Does
anyone remember?

> 
> Now, one can say that intermediate proxies may still be 
> RFC2542 compliant, but in that case you could have problems 
> (with stateful proxies) even if you change the URI in another 
> request within the dialog. The draft does not cover that.
[JRE] This was recognised in Vancouver. I will investigate whether more
words are needed in the next draft.

> 
> So, the question is really: how many proxies are there out 
> there who still use the To header URI from transaction identification?
[JRE] If we don't change the To header URI in a response, transaction
identification is not an issue.

> 
> Also, a problem with UPDATE is that there is always a risk 
> for race conditions. For example, the UAC may send an UPDATE 
> (e.g. to change codecs and/or mode) itself when receving 200 
> OK, so if it RECEIVES an UPDATE at the same time it will have 
> to reject (491) that (I assume you can not have two UPDATE 
> transactons, even if one does not contain SDP).
[JRE] The question of race conditions was touched on at the meeting and was
not thought to be a problem. If there is any impact of changing the To
header field on race conditions, I will cover it in the next draft.

> To: Jesske, R; [email-masked]; [email-masked]; 
> Christer Holmberg (JO/LMF); [email-masked]; [email-masked]
> Changing the From (or the To) URI in a response would 
> undermine the rules for transactions in SIP. It was stated 
> during the SIP meeting at IETF65 that we should not do this. 
> So the alternative is to convey information in some other 
> header or body in the response. Feng Cao addresses this in 
> his response identity draft, although that received some 
> comments during IETF65 and will need to be reworked. The 
> problem always is whether the UAS can be authenticated - as I 
> have stated before, this is only if the request has been 
> delivered over a TLS connection over which the UA has already 
> been authenticated. I suggest you collaborate with Feng if 
> you want this, but personally I am not convinced that an 
> adequate solution will be found.
> 
> In the meantime we have a simple solution using 
> connected-identity, which in any case is needed for other situations.
> 
> John
> 
> of the 200 
> Rosenberg;

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 31 Mar 2006 15:32:05 +0200

Hi John, 

>The To header affects the transaction rules only in RFC2543 - in 
>RFC3261 it is not used - so if a client supporting dialogUriChange 
>would have to be RFC3216 compliant I see no problem with changing the 
>header in the response.
[JRE] You are correct. But some objection was raised at the meeting to changing the To header in a response compared to that in the request. Does anyone remember?
>RFC2542 compliant, but in that case you could have problems (with 
>stateful proxies) even if you change the URI in another request within 
>the dialog. The draft does not cover that.

[JRE] This was recognised in Vancouver. I will investigate whether more words are needed in the next draft.

[CHH] I do think we need to describe the proxy impacts. Because, as I said, even if you don't change the To header URI per transaction, chaning it within a dialog may cause problem in RFC2543 compliant stateful proxies. And, again, if those proxies are "out of the scope" (because we assume there are no such deployed), I see no reason why we can't require the UAs supporting this extension being 3261 compliant and change the To header URI within a transaction...

>So, the question is really: how many proxies are there out there who 
>still use the To header URI from transaction identification?
[JRE] If we don't change the To header URI in a response, transaction identification is not an issue.

[CHH] No, but dialog identification may still be.

>Also, a problem with UPDATE is that there is always a risk for race 
>conditions. For example, the UAC may send an UPDATE (e.g. to change 
>codecs and/or mode) itself when receving 200 OK, so if it RECEIVES an 
>UPDATE at the same time it will have to reject (491) that (I assume 
>you can not have two UPDATE transactons, even if one does not contain 
>SDP).

[JRE] The question of race conditions was touched on at the meeting and was not thought to be a problem. If there is any impact of changing the To header field on race conditions, I will cover it in the next draft.

[CHH] I strongly disagree that race condition is not a problem. I could present some IMS use-cases, but then I will just get a lots of we-don't-care-about-your-walled-garden type of comments again. However, I DO belive that even in the free and open internet world there could be cases there UPDATE is sent after 200 OK. Also, I don't believe that the chaning of To header itself is the race-condition problem, but the fact that you have an UPDATE transaction race-condition.

Regards,

Christer

> To: Jesske, R; [email-masked]; [email-masked]; Christer 
> Holmberg (JO/LMF); [email-masked]; [email-masked]
> Changing the From (or the To) URI in a response would undermine the 
> rules for transactions in SIP. It was stated during the SIP meeting at 
> IETF65 that we should not do this.
> So the alternative is to convey information in some other header or 
> body in the response. Feng Cao addresses this in his response identity 
> draft, although that received some comments during IETF65 and will 
> need to be reworked. The problem always is whether the UAS can be 
> authenticated - as I have stated before, this is only if the request 
> has been delivered over a TLS connection over which the UA has already 
> been authenticated. I suggest you collaborate with Feng if you want 
> this, but personally I am not convinced that an adequate solution will 
> be found.
> 
> In the meantime we have a simple solution using connected-identity, 
> which in any case is needed for other situations.
> 
> John
>