From: [EMAIL PROTECTED]
From: "Jeroen van Bemmel" <[EMAIL PROTECTED]>
> 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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
