[Serusers] Re: [Serdev] Problem with Via Branch/Strange Looping Problem with ACK's

Zeus Ng zeus.ng at isquare.com.au
Tue May 3 07:20:10 CEST 2005


Can you try this and report the result. Change the parameter enable_full_lr
to no. That is:
  modparam("rr", "enable_full_lr", no)

I've seen as least two other UA/GW that treat SER as a strict router when
SER is inserting ";lr=on" in the record route header. Modifying the above
parameter revert SER to RFC recommended syntax for loose route.


> -----Original Message-----
> From: serusers-bounces at lists.iptel.org 
> [mailto:serusers-bounces at lists.iptel.org] On Behalf Of reticent
> Sent: Sunday, 1 May 2005 1:48 PM
> To: serusers at lists.iptel.org
> Subject: [Serusers] Re: [Serdev] Problem with Via 
> Branch/Strange Looping Problem with ACK's
> 
> 
> For reference:
> The "Cisco_7960" traces exhibit strict_routing, and shows the 
> SER looping problem
> 
> The "Ambit_vg20" traces show the proper (RFC3261, Reference 
> #1 at the bottom of the email) behaviour and works perfectly.
> 
> 
> *SER_SIP_PROXY*:15061 is SER
> *SER_SIP_PROXY*:5080 is Asterisk
> Both SER and Asterisk are on the same server
> 
> *SIP_UAC* is the client device
> 
> There are two traces for each session, one taken from the 
> external interface (ETH0) and one from loopback (LO)
> 
> In the "Cisco_7960" traces, the Cisco 7960 responds to the 
> session initiating "200 OK" with an ACK that seems to follow 
> Strict Routing behaviour.
> 
> The issue is that the ACK does NOT match the loose_route() 
> statement in the SER config and eventually hits a t_relay, 
> however the RURI is that of the SER proxy itself so it routes 
> to itself over and over again.
> 
> What i expect is that it should hit loose_route() (or perhaps
> strict_route() ), which should replace the RURI with the 
> information in the "Route:" header which would allow it to be 
> properly routed to its destination.
> 
> This same problem seems to happen with BYE messages as well 
> (same situation and results)
> 
> 
> 
> -----------------------
> 
> Reference #1:
> 
> Section 12.1.2 of RFC3261 states:
> --
> The route set MUST be set to the list of URIs in the Record-Route
>    header field from the response, taken in reverse order and 
> preserving
>    all URI parameters.  If no Record-Route header field is present in
>    the response, the route set MUST be set to the empty set.  
> This route
>    set, even if empty, overrides any pre-existing route set for future
>    requests in this dialog.  The remote target MUST be set to the URI
>    from the Contact header field of the response.
> --
> 
> 
> 




More information about the sr-users mailing list