2012/8/16 Peter Dunkley <[email protected]> > > The PUA module will need to be updated too. At the moment this caches the > RRs from the 2XX response to the SUBSCRIBE. To support the new RFC it will > need to process and reverse the RRs from the NOTIFY and store that instead. > > Probably needs to be under control of a modparam so that the old behaviour is > still available for use with older network configurations. > > There may well be other changes to Presence, PUA, and RLS to make them > conform to this new RFC.
Hi Peter, let me explain it a bit more the issue (which is not so "new" in RFC 6665 but also in 3265 obsoleted now by 6665): 1) An UAC sends an initial SUBSCRIBE and the proxy forks it to 2 servers/UAS. 2) Both servers reply 200 but the proxy absorbs the last one (as per RFC 3261). 3) The UAC just receives the first 200 from server-1, retrieves the Record-Route headers and To-tag and creates the route set of the dialog. 4) UAC receives the first instant NOTIFY from server-1. Its dialog is already formed so no need to inspect the Record-Route headers in the NOTIFY. 5) And then UAC receives the first NOTIFY from server-2. The UAC must then create a *second* subscription dialog having as remote-tag the From-tag of the NOTIFY and as route set the Record-Route values of the NOTIFY (so the proxy MUST add Record-Route). 6) So the UAC manages two dialogs, but just received a 200 for the first one. Note about step 3 above: The UAC could receive the NOTIFY from server-1 *before* the SUBSCRIBE 200 from server-1, and if so, UAC should create the dialog with the data retrieved from the NOTIFY and then "ignore" the 200 arriving later. So RFC 3265 *already* mandates that the proxy MUST add Record-Route to SUBSCRIBE and in-dialog NOTIFY requests: http://tools.ietf.org/html/rfc3265#section-3.1.5 The *only* difference in RFC 6665 is that the UAC MUST generate the dialog upon the receipt of the NOTIFY (of each NOTIFY with different From-tag I mean), rather than creating it if the SUBSCRIBE 200 arrives first. Since I expect that PUA module will never send a SUBSCRIBE for which parallel forking would take place, creating the dialog with the data retrieved from the SUBSCRIBE 200 is good enough IMHO. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
