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