[Serusers] Re: [Serdev] Strange Looping Problem with ACK's and BYE's in CertainScenarios

reticent tavis.lists at galaxytelecom.net
Mon Apr 25 23:07:13 CEST 2005


The thing is the ACK being returned from the UAC contains a route header
that does not match when passing loose_route() (the route header holds
the contents of the Contact header in the 200 OK), so eventually the ACK
hits a t_relay() in which case SER forwards the message to the RURI,
which is itself (lather, rinse, repeat).

I believe that this is due to the use of Strict Routing on the part of
the UAC and i need to treat it accordingly on SER, however the
"strict_route()" function seems to have dissappeared from rr.so so i'm
currently searching for a way to replace the URI with the URI from the
Route HF in the event that a UAC does strict routing

Samuel Osorio Calvo wrote:

>Hi all,
>
>We face some "strange" behaviour when several "SIP programs" run on the
>same machine as SER does that may be realted whith your scenario. I'll
>try to explain and hope my memory is not totally corrupted after some
>free days...
>
>Whenever you set an alias configuration parameter, usually you omit the
>port number and place just an IP or hostname, which matches the host
>values. This configures SER to see all SIP messages targeted to the host
>values as directed to himself NO MATTER which port is present in the
>routing URIs.
>
>This behaviour entails that the loose_route() will not work as you may
>expect because the SER instance will think that the request targeted to
>the application running in the same machine is INSTEAD directed to SER
>(that explains the stateless behaviour and the 0 parameter in the
>branch). That is why your colocated asterisk instance never sees the ACK
>and SER instead forwards statelessly itself the request until the hop
>counter reaches 10 (or whatever value you had set).
>
>The solution is to add the port number in the alias parameter of SER
>config file whenever SER has to route SIP request to programs running in
>the same host.
>
>Hope this helps,
>
>Samuel.
>




More information about the sr-users mailing list