One of the topics that got bantered about during SIPit 21 was re-
discovering that if a SUBSCRIBE forks and proxies don't record-route
the NOTIFYs (which are mid-dialog requests), the subscriber doesn't
end up with the right route-set for the NOTIFYs from dialogs other
than the one matching the 200 OK to the SUBSCRIBE.
3261 says proxies SHOULD record-route mid-dialog requests, but it
doesn't provide enough motivation (I think it was originally
motivated by the
notion of allowing rebooting UAs to reconstitute dialog state rather
than anticipating the problem we have with HERFP here).
By and large, proxies ignore that SHOULD since endpoints are required
to ignore any attempt to change the route-set mid-dialog.
This is a real problem, and it will eventually cause failure in the
deployment of any SIP Event application where the SUBSCRIBE might fork.
Now, is actually record-routing all mid-dialog requests really the
right thing to do? It really is a waste of bits in any message that
isn't going to create a dialog.
Would it make more sense to work on an extension that would allow an
endpoint to indicate "this request is going to establish a dialog -
you better record-route it" instead?
RjS
p.s. (I've thought all along that we should allow mid-dialog requests
to modify the route-set, and that would require all requests, mid-
dialog or not to be record-routed, but that's not how the consensus
landed).
_______________________________________________
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
