[SR-Users] re-SUBSCRIBE and Record-Route

marius zbihlei marius.zbihlei at 1and1.ro
Fri Mar 4 16:05:55 CET 2011


On 03/04/2011 04:56 PM, Klaus Darilion wrote:
> Not so easy .....
>
> 16.4 Route Information Preprocessing
>
>
>     The proxy MUST inspect the Request-URI of the request.  If the
>     Request-URI of the request contains a value this proxy previously
>     placed into a Record-Route header field (see Section 16.6 item 4),
>     the proxy MUST replace the Request-URI in the request with the last
>     value from the Route header field, and remove that value from the
>     Route header field.  The proxy MUST then proceed as if it received
>     this modified request.
>
>        This will only happen when the element sending the request to the
>        proxy (which may have been an endpoint) is a strict router.  This
>        rewrite on receive is necessary to enable backwards compatibility
>        with those elements.  It also allows elements following this
>        specification to preserve the Request-URI through strict-routing
>        proxies (see Section 12.2.1.1).
>
>
> Thus, Kamailio should somehow detect if the URI is inserted by himself
> or not. This may only happen if the previous hop is a strict-router. As
> Kamailio is a loose-router and always adds the ;lr parameter, the check
> could be extended to check if the RURI also cotains lr parameter. If the
> lr parameter is not present, this means for sure that the RURI was not
> generated by Kamailio.
>
>    

Hello,

I was thinking of maybe adding a new configurable RR param. A strict 
router would copy this header into the RURI. But a.t.m. loose_route does 
not perform any checking on tags. Maybe an exclude_uri_tag module param 
that can work like this:

modparam("rr", "exclude_uri_tag", "mark=on");

Then, when the initial SUBSCRIBE (dialog setting message) comes

add_rr_param(";mark=on");

In the loose_route processing, if exclude_uri_tag is set and  !(RURI =~ 
exclude_uri_tag), then perform loose routing on that request (the 
request isn't coming from a strict router)

What do you think?

Marius
> Of course this would require code changes.
>
> A dirty hack would be to manipulate the Route headers manually and set $du.
>
>
> regards
> Klaus
>
>
>
> Am 04.03.2011 15:25, schrieb marius zbihlei:
>    
>> Hello list,
>>
>> An UAC sends a resubscribe in the form
>>
>> SUBSCRIBE sip:Alice at example.com SIP/2.0
>> Route:<sip:sip.example.com;lr=on>
>> Route:<sip:sip.next-hop.example.com;lr=on>
>> ....
>>
>> The request has a to tag, from tag... Basic resubscribe(R-URI is the
>> same as original SUBSCRIBE) The proxy that handles it is a Kamailio (1.5
>> but this refers to 3.1 as well). The problem is that loose_route()
>> treats this request as coming from a strict routing router, not from the
>> UAC, so it applies the strict-to-loose rules and rewrites the request as:
>>
>> SUBSCRIBE sip:sip.next-hop.example.com;lr=on SIP/2.0
>> Route:<sip:sip.example.com;lr=on>
>> ....
>>
>> The segment that handles this is pretty standard:
>>
>> if (loose_route()) {
>>                  # sequential request withing a dialog should take the path
>>                  # determined by record-routing
>>                  if(has_totag()) {
>>                          forward();
>>                          exit;
>> }
>>
>> It sees that message has Route set, it finds the to tag (so the routes
>> were not a preset), and then , the important thing, sees that the domain
>> from the RURI matches itself (kamailio has aliases configured for
>> example.com), thus considering the request as coming from a strict
>> router. Then it takes the bottom Route header and overwrites the RURI.
>>
>> What is the best way to ensure that loose routing is applied to the
>> resubscribe as described above?
>>
>> Cheers,
>> Marius
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>      
>    




More information about the sr-users mailing list