[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] NOTIFY establishes a dialog
On Wed, 2003-03-19 at 22:19, hisham.khartabil@nokia.com wrote:
> 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.
> 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:rsparks@dynamicsoft.com]
> > Sent: Thursday, March 20, 2003 7:55 AM
> > To: Ganesh Sivaraman; Khartabil Hisham (NMP/Helsinki)
> > Cc: sip@ietf.org
> > 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, hisham.khartabil@nokia.com 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 hisham.khartabil@nokia.com
> > > > > [mailto:hisham.khartabil@nokia.com]
> > > > > Sent: Wednesday, March 12, 2003 5:37 PM
> > > > > To: sip@ietf.org
> > > > > 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 sip-implementors@cs.columbia.edu for questions on
> > current sip
> > > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
> > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip