Subject: RE: [Sip] NOTIFY establishes a dialog

From: [email-masked]
Date: Thu, 20 Mar 2003 08:19:50 +0200

This sounds like a solution to the first problem. I guess I couldn't find the text because it was in the wrong section. May I suggest a bug report specifying moving the text to section 12.

The other problem with NOTIFY can be solved by specifying that a NOTIFY establishes an early dialog. Is that ok? bug report?

Regards,
Hisham

> -----Original Message-----
> From: ext Robert Sparks [mailto:[email-masked]]
> Sent: Thursday, March 20, 2003 7:55 AM
> To: Ganesh Sivaraman; Khartabil Hisham (NMP/Helsinki)
> Cc: [email-masked]
> Subject: RE: [Sip] NOTIFY establishes a dialog
> 
> 
> response to one of the questions inline:
> 
> On Wed, 2003-03-19 at 20:55, Ganesh Sivaraman wrote:
> > 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
> > 
> > On Thu, 2003-03-20 at 04:17, [email-masked] wrote:
> > > 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?
> 
> >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".
> 
> > > 
> > > 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
> > 
> > _______________________________________________
> > 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: Robert Sparks <[email-masked]>
Date: 19 Mar 2003 22:43:29 -0800

A NOTIFY that beats a 200 OK establishes a full-blown established
dialog, not an early one.

If the 200 dialog identifiers match the NOTIFY, the route set will not
be updated. If the 200 identifies some other dialog, then the dialog
established by the NOTIFY continues to exist - state unchanged.

This is covered in 3.3.4 of 3265 - the first of a NOTIFY or a 200
with a fully qualified dialog identifier establishes a dialog (and
the corresponding route set). Please read that section again - if
you still think it's not clear, propose text.

RjS

---

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

> This sounds like a solution to the first problem. I guess I couldn't find the text because it was in the wrong section. May I suggest a bug report specifying moving the text to section 12.

Added as bug 703.