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(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of reticent
Sent: Sunday, 1 May 2005 1:48 PM
To: serusers(a)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.
--