[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Sip] NOTIFY establishes a dialog

To: Arunachalam Venkatraman <arunvenk@cisco.com>
Subject: RE: [Sip] NOTIFY establishes a dialog
From: Robert Sparks <rsparks@dynamicsoft.com>
Date: 20 Mar 2003 08:42:10 -0800
Cc: sip@ietf.org
In-reply-to: <GFEJJOMGHDNDPFCCCIGNCEKKCOAA.arunvenk@cisco.com>
List-help: <mailto:sip-request@ietf.org?subject=help>
List-id: Session Initiation Protocol <sip.ietf.org>
List-post: <mailto:sip@ietf.org>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,<mailto:sip-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,<mailto:sip-request@ietf.org?subject=unsubscribe>
References: <GFEJJOMGHDNDPFCCCIGNCEKKCOAA.arunvenk@cisco.com>
Sender: sip-admin@ietf.org

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

On Thu, 2003-03-20 at 07:54, Arunachalam Venkatraman wrote:
> 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

Follow-Ups:
- RE: [Sip] NOTIFY establishes a dialog
  - From: Juha Heinanen

References:
- RE: [Sip] NOTIFY establishes a dialog
  - From: Arunachalam Venkatraman

Prev by Date: RE: [Sip] NOTIFY establishes a dialog
Next by Date: RE: [Sip] NOTIFY establishes a dialog
Previous by thread: RE: [Sip] NOTIFY establishes a dialog
Next by thread: RE: [Sip] NOTIFY establishes a dialog
Index(es):
- Date
- Thread