16 aug 2012 kl. 16:41 skrev Iñaki Baz Castillo: > 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. >
If the notify state in the first NOTIFY is terminated there will be no new dialog. Right? /O _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
