2012/8/16 Iñaki Baz Castillo ibc@aliax.net:

Sorry, I mean "doing record_route() for in-dialog NOTIFY's".

More rationale:

The problem is that, according to the new RFC 6665 (which obsoletes RFC 3265), the UAC creates the dialog and gets the route set when the first NOTIFY arrives (instead of taking it from the 200 to the initial SUBSCRIBE):

RFC 6665:

------------ Section 4.4.1 has been updated to specify that dialogs should be created when the NOTIFY arrives. Previously, the dialog was established by the SUBSCRIBE 200... -----------

Therefore, an UAC compliant with RFC 6665 will ignore the Record-Route headers in the SUBSCRIBE 200 and will wait for the first NOTIFY to get the Record-Route headers and set them as the route set of the dialog. If such a NOTIFY does not contain RR then the UAC will fail to create the route set and the next re-SUBSCRIBE will miss them.

So in short: every proxy in the path of a subscription MUST add RR to in-dialog NOTIFY requests, and thus Kamailio default script file should perform record_route() for in-dialog NOTIFY requests.

Regards.

2012/8/17 Juha Heinanen jh@tutpro.com:

Iñaki Baz Castillo writes:

...

Therefore, an UAC compliant with RFC 6665 will ignore the Record-Route headers in the SUBSCRIBE 200 and will wait for the first NOTIFY to get the Record-Route headers and set them as the route set of the dialog. If such a NOTIFY does not contain RR then the UAC will fail to create the route set and the next re-SUBSCRIBE will miss them.

So in short: every proxy in the path of a subscription MUST add RR to in-dialog NOTIFY requests, and thus Kamailio default script file should perform record_route() for in-dialog NOTIFY requests.

inaki,

your summary is not correct. it is enough to add rr header to the FIRST notify after dialog creating subscribe.

Sure but, how to distinguish the *first* in-dialog NOTIFY and any other later? No way.

would it be difficult for kamailio presence server to somehow (in a header) indicate that the notify is the first one?

So it would just work with Kamailio as presence server and via a custom header/param in a NOTIFY request? that's really ugly. And what about if I use another presence server? or what about if my Kamailio is just an outbound proxy and knows nothing about what kind of servers are behind it?

BTW SER default config files perform record_route() for *all* the requests (initial and in-dialog), which is a bit "exagerate" and useless in many cases, but in fact is not a problem.

And BTW, RFC 3265 (obsoleted by 6665) suggests adding RR to *all* the NOTIFY requests:

http://tools.ietf.org/html/rfc6665#section-4.3

4.3. Proxy Behavior

If a proxy wishes to see all of the SUBSCRIBE and NOTIFY requests for a given dialog, it MUST add a "Record-Route" header field to the initial SUBSCRIBE request and all NOTIFY requests. It MAY choose to include "Record-Route" in subsequent SUBSCRIBE requests; however, these requests cannot cause the dialog's route set to be modified.

2012/8/17 Juha Heinanen jh@tutpro.com:

Iñaki Baz Castillo writes:

...

So it would just work with Kamailio as presence server and via a custom header/param in a NOTIFY request? that's really ugly. And what about if I use another presence server? or what about if my Kamailio is just an outbound proxy and knows nothing about what kind of servers are behind it?

there could a module param in presence server that tells if this extra header or param is added or not. i don't see anything ugly about it. i'm sure many kamailio users are adding all kind of proprietary headers when message spirals through their proxys.

And what about the rest of objections in my previous mail?

2012/8/17 Juha Heinanen jh@tutpro.com:

regarding this:

...

Sure but, how to distinguish the *first* in-dialog NOTIFY and any other later? No way.

i would imagine that presence server does know when subscription is created and first notify is sent.

Sure.

and of course one would use this feature only when sip proxy and presence server are both based on kamailio run by the same service provider.

So you suggest the presence module to insert a custom header/param in the first NOTIFY of a subscription just to avoid the intermediary proxi(es) to do record-routing, but at the same time all the default script files for SER in sip-router sources call record_route() for *every* requests (initial and in-dialog). And you really want to avoid something that both RFC 3265 and 6665 suggest (adding RR for *every* NOTIFY).

Honestly, I think adding the "feature" you propose is a waste of time and a not needed complexity. The custom header check could be, probably, more expensive than just adding RR to every NOTIFY.

regarding obsoleted rfc, i don't see a big need to support it. if rr missing from notifys would be a big problem, kamailio users would already have noticed it.

The problem takes place when a RFC 6665 strict compliant UAC expects to create the dialog with the Record-Route headers retrieved from the first NOTIFY. Taking into acount that this requirement appears in RFC 6665 which has been published in July 2012, I expect that no one existing UAC will suffer it (but maybe new devices do). So Kamailio users cannot noticed this problem (yet).

Regards.

2012/8/16 Klaus Darilion klaus.mailinglists@pernau.at:

Why don't providing a patch?

Klaus

PS: Don't you have git write privileges?

I will do :)

I just wanted to discuss first the issue :)

2012/8/16 Peter Dunkley peter.dunkley@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.

-- Iñaki Baz Castillo ibc@aliax.net

2012/8/16 Olle E. Johansson oej@edvina.net:

If the notify state in the first NOTIFY is terminated there will be no new dialog. Right?

Right, the UAC should release resources for that dialog.

2012/8/16 Olle E. Johansson oej@edvina.net:

...

2012/8/16 Olle E. Johansson oej@edvina.net:

...

If the notify state in the first NOTIFY is terminated there will be no new dialog. Right?

Right, the UAC should release resources for that dialog.

Which dialog :-) The one that never existed?

XDDD right

Do we now have "early dialogs" in subscribe/notify?

It would be really cool. Let's document a spec for it xD

Am 16.08.2012 21:44, schrieb Iñaki Baz Castillo:

2012/8/16 Klaus Darilion klaus.mailinglists@pernau.at:

...

Am 16.08.2012 13:15, schrieb Iñaki Baz Castillo:

...

Hi, the new RFC 6665 mandates that the subscription dialog is made *after* the first NOTIFY from the UAS (rather than after the 200 to the initial SUBSCRIBE). This means that the UAC MUST take the route set from the *first* received NOTIFY (instead of taking it from the 200 to the initial SUBSCRIBE).

How about the NOTIFYer? Which route set should the NOTIFYer use? The one learned from the intial SUBSCRIBE or then one from the 2xx response to the first NOTIFY?

The 200 it replied to the initial SUBSCRIBE.

Just re-reading this old thread I wonder how the first NOTIFY should be sent? The NOTIFY needs some route headers to sned the first notify.

Thus, I suspect that the notifier should use an "early route set" to send the first NOTIFY (learnt from the RR headers in the SUBSCRIBE) and further NOTIFYs should use the route set learnt from the RR headers in the response to the first NOTIFY.

Is this correct?

thanks Klaus