Subject: RE: [Sip] NOTIFY establishes a dialog

From: [email-masked]
Date: Thu, 20 Mar 2003 00:47:33 +0200

I have a few related questions/comments:

- A 180 response to a request (like INVITE) establishes a dialog. This 180 response carries record-route headers and therefore sets the route-set. The 200 response to the request might also carry record-route headers. The dialog transitions to confirmed state, but I assume the route-set does not get updated using the record-route headers in the 200 response since the dialog is established already. Is this a correct assumption? should the UAS send record-route headers at all in the 200 if it sent a 1xx already?

Should there be a mandate that 1xx and 2xx response carry the same record-route headers? You would assume that this happens naturally at the UAS, but proxies may play around with the record-route headers.

- In the NOTIFY problem below, the NOTIFY establishes the dialog, but does not carry record-route headers. If the same assumption is made as above, the record-route headers appearing in the 200 response to the SUBSCRIBE are ignored since the dialog is in established state. Isn't this a problem? the route-set is lost.

I appreciate some clarifications.

Regards,
Hisham

> -----Original Message-----
> From: ext [email-masked] 
> [mailto:[email-masked]]
> Sent: Wednesday, March 12, 2003 5:37 PM
> To: [email-masked]
> Subject: [Sip] NOTIFY establishes a dialog
> 
> 
> In RFC3265, it is mentioned that NOTIFY can certainly 
> establish a dialog if it arrives before the 200 of a 
> SUBSCRIBE. What happens when the 200 for the SUBSCRIBE now 
> arrives with record-route headers? Does the route-set get 
> updated? (keeping in mind that the dialog is now in the 
> established state).
> 
> Regards,
> Hisham
> _______________________________________________
> 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: "Arunachalam Venkatraman" <[email-masked]>
Date: Wed, 19 Mar 2003 19:47:09 -0600

Hisham
The reason the Record_Route headers must be sent on the 200 is that the 1xx
is not guaranteed to be delivered, unless they are sent reliably.

I think in the context of the Notify crossing the 200, the arrival of the
200 will establish the Route set for future requests. Each transaction
completes independently.

I am copying in a old message on this subject from the sip list below that
you may find useful - (I think it would have been useful to state this in
the RFC3261).

------------------ Start Of Old Message --------------------------

> From: 	Arunachalam Venkatraman [mailto:[email-masked]]
> Sent:	Friday, March 23, 2001 3:39 PM
> To:	[email-masked]
> Cc:	Jonathan Rosenberg
> Subject:	Replace Contact in Route set ?
>
> As per the protocol, the Contact header is added to the end of the Route
header.
>
> Suppose a Record-Route was first received in a message with a Contact C1.
> The UA has built a route set with the Contact C1 at the bottom of the
Route.
>
> If the next request to the UA has a new Contact C2, should C1 in the Route
Set be replaced
> with C2?

Yes. And if there was no Contact, don't change anything.

Note that if the next request has new record-routes, those do NOT update the
existing route sets.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---------------------------------End of Old Message ----------------------

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Wednesday, March 19, 2003 4:48 PM
To: [email-masked]
Subject: RE: [Sip] NOTIFY establishes a dialog

- A 180 response to a request (like INVITE) establishes a dialog. This 180
response carries record-route headers and therefore sets the route-set. The
200 response to the request might also carry record-route headers. The
dialog transitions to confirmed state, but I assume the route-set does not
get updated using the record-route headers in the 200 response since the
dialog is established already. Is this a correct assumption? should the UAS
send record-route headers at all in the 200 if it sent a 1xx already?

Should there be a mandate that 1xx and 2xx response carry the same
record-route headers? You would assume that this happens naturally at the
UAS, but proxies may play around with the record-route headers.

- In the NOTIFY problem below, the NOTIFY establishes the dialog, but does
not carry record-route headers. If the same assumption is made as above, the
record-route headers appearing in the 200 response to the SUBSCRIBE are
ignored since the dialog is in established state. Isn't this a problem? the
route-set is lost.

Regards,
Hisham

---

From: Ganesh Sivaraman <[email-masked]>
Date: 20 Mar 2003 10:25:37 +0530

Hi Hisham,
 I'd posted the same question about setting dialog-state (route-set
etc.) and I got the following response:
<http://lists.cs.columbia.edu/pipermail/sip-implementors/2003-February/004569.html>

It says:
"RFC 3265 augments 3261, in that the dialog in this case can be created
either by a response to SUBSCRIBE or by NOTIFY".

So that would mean that the route-set could be constructed with
Route-headers (present in NOTIFY) also. Is this a correct assumption?

A word from the authors of the RFC on this would help bring more
clarity.

Regards
Ganesh

---

From: Robert Sparks <[email-masked]>
Date: 19 Mar 2003 21:55:22 -0800

response to one of the questions inline:

>From rfc3261 page 82:

   If the dialog identifier in the 2xx response matches the dialog
   identifier of an existing dialog, the dialog MUST be transitioned to
   the "confirmed" state, and the route set for the dialog MUST be
   recomputed based on the 2xx response using the procedures of Section
   12.2.1.2.  Otherwise, a new dialog in the "confirmed" state MUST be
   constructed using the procedures of Section 12.1.2.

In context, you'll see the "existing dialog" above is an "early dialog".

---

From: "Arunachalam Venkatraman" <[email-masked]>
Date: Thu, 20 Mar 2003 09:54:28 -0600

Robert
Can you explain the reasoning behind the section from RFC3261 that you have
quoted below?
I would think the Record-Route headers on the 1xx and 200 will be identical
since the responses would traverse (backwards) the same path that the INVITE
took, using the same VIA set.
Why should one recompute the Route Set? The only thing that may change is
the Contact, isn't it?
Venkat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Robert
Sparks
Sent: Wednesday, March 19, 2003 11:55 PM
To: Ganesh Sivaraman; [email-masked]
Cc: [email-masked]
Subject: RE: [Sip] NOTIFY establishes a dialog

> etc.) and I got the following response:
<http://lists.cs.columbia.edu/pipermail/sip-implementors/2003-February/00456
9.html>
> > - A 180 response to a request (like INVITE) establishes a dialog. This
180 response carries record-route headers and therefore sets the route-set.
The 200 response to the request might also carry record-route headers. The
dialog transitions to confirmed state, but I assume the route-set does not
get updated using the record-route headers in the 200 response since the
dialog is established already. Is this a correct assumption? should the UAS
send record-route headers at all in the 200 if it sent a 1xx already?

> >
> > - In the NOTIFY problem below, the NOTIFY establishes the dialog, but
does not carry record-route headers. If the same assumption is made as
above, the record-route headers appearing in the 200 response to the
SUBSCRIBE are ignored since the dialog is in established state. Isn't this a
problem? the route-set is lost.

---

From: Robert Sparks <[email-masked]>
Date: 20 Mar 2003 08:42:10 -0800

The only think I can think of this morning (IETF weeks are always
brutal) is that as the text is currently written, the proxies can
rewrite the record-route header field values as the responses
propogate back (to deal with things like multiple interfaces or
transport protocol changes that can't be dealt with via SRV).

Its possible for a proxy to provide a URI with
different parameters on the provisional and final response (to
indicate to itself whether its dealing with an early or confirmed
dialog perhaps). 

Now, subsequent conversations indicate that we probably want to
discourage this rewriting in favor of the double-record-route
solution so that the RR header field in a response can be signed
by the responding endpoint. The quoted text below would become
irrelevant if we made it illegal for proxies to rewrite RR header
field values.

RjS

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 20 Mar 2003 19:24:31 +0200

> irrelevant if we made it illegal for proxies to rewrite RR header

at least proxys should be allowed to add parameters to record
route/route headers.

by the way, i think it is a big mistake that the current sip rfc doesn't
allow a re-invite to include a new record route.  consider the case
where a call originates in a mobile network and then roams to wlan, for
example.  it would be really stupid if the subsequent messages of the
dialog would need to go via the proxies of the mobile network.

-- juha

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Mar 2003 07:49:29 +0200

Hi Robert,

> In context, you'll see the "existing dialog" above is an "early dialog".

Chapter 4 in RFC3262 says:

"The UAC MAY acknowledge reliable provisional responses received after
the final response or MAY discard them."

Now, IF the UAC chooses to acknowledge reliable provisional responses after the final response is received, which route set should it use for the PRACK? The route set it used for the other PRACKs in the "early state", or the possible new route set is has for the "confirmed state"?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Robert Sparks <[email-masked]>
Date: 20 Mar 2003 22:09:38 -0800

Nice question.

>From a constructionist view, the PRACK is clearly associated with the
early dialog and should use the early dialog route set. From a practical
point of view, using either the early or confirmed route set gets the
PRACK to the place that needs it, so what does it matter? (Can you
construct a case where a proxy would care?)

I think, though, that the idea that the early and established route
sets can be different is just an artifact of the way we defined
record-route rewriting instead of a feature we really intended to
engineer. (If someone knows differently, please speak up). The
double-record-route solution for those cases where rewriting
is necessary would allow the RR field in a response to be signed.
That would _prevent_ the early and confirmed route sets from being
different. I suspect that's a more desired behavior.

So to answer your question more succinctly:
 - I don't think it matters which you use
 - The potential difference should go away anyhow

RjS

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 22 Mar 2003 21:53:23 +0200

Hi Robert,

> construct a case where a proxy would care?)

First, if we use connection protocols, with or without security (TCP, TLS etc), nodes may have to establish two connections (if the next hop is different in the early- and confirmed route sets). This affects, of course, both UAs and proxies.

Second, since we are not allowed to change the route once the dialog has been "confirmed", there may be proxies which checks the route for incoming request. And, those proxies may not know the semantics of PRACK, so they may think the request is for the confirmed dialog, and reject it
because it tries to use another route.

Third, this MAY also affect other early dialog requests (UPDATE, INFO), which due to race conditions are sent after the dialog has been confirmed. >From a proxy point of view, however, I guess this is not different from the PRACK case.

Fourth, but this I haven't thought so much about yet, could this somehow affect the work on connection reuse?

> engineer.

Personally I don't see any reason why it should be allowed in the first place. Because, we are NOT allowed to change the Contact header in 18x and 200 responses, are we? So, why should we be allowed to change Record-Route?

Of course, IF someone has reasons why proxies should be involved only in the early state, or in the confirmed state, that is another issue, but in the case the question is if we should have a generic way of changing the route set - also after the dialog has been confirmed (Juha
mentioned cases where such functionality could be useful).

Regards,

Christer Holmberg
Ericsson Finland

> (If someone knows differently, please speak up). The