16 Aug
2012
16 Aug
'12
5:47 p.m.
16 aug 2012 kl. 16:41 skrev Iñaki Baz Castillo:
2012/8/16 Peter Dunkley
<peter.dunkley(a)crocodile-rcs.com>
If the notify state in the first NOTIFY is terminated there will be no new dialog.
Right?
/O
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.