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.