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

Iñaki Baz Castillo ibc at aliax.net
Fri Aug 17 12:28:24 CEST 2012


2012/8/17 Juha Heinanen <jh at 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.


-- 
Iñaki Baz Castillo
<ibc at aliax.net>



More information about the sr-dev mailing list