Subject: Re: [Sip] INFO, Mime-multipart, and Content Negotiation (oh, my!)

From: [email-masked]
Date: Thu, 2 Aug 2007 16:59:10 -0400

From: [email-masked]

      From: "Jeroen van Bemmel" <[email-masked]>

      > I see no problem with proliferating methods, as that is no worse than
      > proliferating Content-Dispositions.

      Well, for one it could cause existing proxies to Record-Route such
      requests as they would not know the method and would therefore be
      forced to assume it to be dialog creating. So there is some
      overhead, compared to C-D as extension point

   IIRC, there's a set of rules that avoid Record-Routing except in the
   first request or two of a dialog.  Scott Lawrence once explained them
   to me, and I checked them, and they're method-independent (as one
   would expect).

The rules for Record-Route:

When a proxy forwards a request that has no to-tag, and the proxy
wishes to remain in the signaling path, it adds a Record-Route header.
(In special cases such as REGISTER, the proxy can know from the
semantics of the request that it will not be dialog-forming and so the
proxy never needs to remain in the signaling path, but in general, the
proxy must Record-Route all such requests if it wants to be in the
signaling path of a dialog.)

When a UA receives a request with Record-Route headers, it returns
them in its response (and saves them as the route set).

When a UA sends a request that has a to-tag, but is potentially
dialog-forming, it must add the route set elements to the request in
Record-Route headers (in addition to adding them in Route headers).
(This ensures that the server will know the route set even if it has
not yet received a response from the original request.)
A request that has a to-tag is potentially dialog-forming if the
sender:
- has received the dialog-forming request (without a to-tag)
- has not received a request with a to-tag (including ACK)
- has not received a response from any request it has sent

The last item became necessary when we created SUBSCRIBE, which can
fork and create dialogs.  We really should get this written into 3261
so people get it right.

Dale

_______________________________________________
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