Subject: [Sip] SIPit 21: Forking Notifys and record-routing mid-dialog requests

From: Robert Sparks <[email-masked]>
Date: Mon, 19 Nov 2007 15:25:15 -0600

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip