2012/8/17 Juha Heinanen <jh(a)tutpro.com>om>:
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.
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
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.
Iñaki Baz Castillo