[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] NOTIFY establishes a dialog
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: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Robert
Sparks
Sent: Wednesday, March 19, 2003 11:55 PM
To: Ganesh Sivaraman; hisham.khartabil@nokia.com
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/00456
9.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