[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] NOTIFY establishes a dialog
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: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