[sr-dev] default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665

[Olle E. Johansson]

16 aug 2012 kl. 16:41 skrev Iñaki Baz Castillo:

> 2012/8/16 Peter Dunkley <peter.dunkley at crocodile-rcs.com>
>> 
>> 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