[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