[Serusers] UAs not respecting Record Route

Samy Touati samy at tunix.com
Sun Feb 15 22:11:57 CET 2004


Yes UA1 does send an ACK to ser, but the request URI contains the address of
UA3 and the route heard contains the address of ser. With this scenario, ser
routes the request to the initial called UA (UA2) instead of going to UA3.
The second ACK message still coming from UA1 (but a different UA, ATA186 in
this case) does generate an ACK  but in the request URI it's the ser proxy
address, and in the route header it's the address of UA3, and in this case
ser route the ACK to UA3.

In both cases the ACK is generated from UA1 (but they are different brands)
and they go to ser.

Included are two ethereal files, one is redirect-fail which contain the
redirection to a host @ port 5071 (UA3) while the second one redirect-ok
still contain the same redirect but this time it's working.

Phoenix.tunix.com:5071 is the address of UA3 (asterisk).



-----Original Message-----
From: Jiri Kuthan [mailto:jiri at iptel.org] 
Sent: Sunday, February 15, 2004 3:42 PM
To: Samy Touati; serusers at lists.iptel.org
Subject: Re: [Serusers] UAs not respecting Record Route

At 08:46 PM 2/15/2004, Samy Touati wrote:
>I do have the following situation:
>UA1 calls UA2 going through ser 0.8.12. All signaling is Recourd Routed and
go through ser.
>UA2 doesnt answer and I do have a t_on_failure to go to UA3.
>UA3 receives INVITES from ser, and answer with a 200/OK with sdp, this
messages goes through ser which forward it to UA1.
>UA1 sends an ACK to ser having this in message:
>Session Initiation Protocol
>    Request line: ACK sip:ua3 at SIP/2.0
>        Method: ACK
>    Message Header
>        Via: SIP/2.0/UDP;branch=z9hG4bk-7f415771
>        From: test1 <sip:ua1 at vocal.ipsound.net>;tag=eb646133bf338b12
>        To: <sip:ua2 at vocal.ipsound.net>;tag=as47221fa0
>        Call-ID: a66804e6-5ac924fd at
>        CSeq: 102 ACK
>        Max-Forwards: 70
>        Route: <sip:sip-proxy at ser-domain.com;ftag=eb646133bf338b12;lr=on>
>        Proxy-Authorization: Digest username="        
>        Contact: ua1 <sip:ua1 at>
>        User-Agent: Sipura/SPA2000-1.0.10
>        Content-Length: 0
>Ser is supposed to follow the route, and ends up looking into the location
table and re-forwards the request to UA2 again (even if it already timed out

Interesting -- it looks like properly generated ACK, except the URI in Route
has some strange value -- I mean SER generates the URI as 
How did these values appear there?

Are you sure your script does include the initial if (loose_route) {
t_relay();break; }
sequence? That should forward the request to address in request URI.

>Now I do have another UA which in this same scenario sends the correct ACK:
>Session Initiation Protocol
>    Request line: ACK sip:sip-proxy at ser-domain.com SIP/2.0
>        Method: ACK
>    Message Header
>        Route: <sip:ua3 at>
>        Via: SIP/2.0/UDP
>        From: ua1 <sip:ua1 at ser-domain.com;user=phone>;tag=3551608275
>        To: <sip:ua2 at ser-domain.com;user=phone>;tag=as112d04ea
>        Call-ID: 2653016335 at
>        CSeq: 2 ACK
>        User-Agent: Cisco ATA 186  v3.0.0 atasip (031210A)
>        Proxy-Authorization: Digest username
>        Content-Length: 0
>In this case ser follow the route header, and ends up sending the ACK to
>Snom phone with 2.03o firmware as well as sipura with 1.0.10 and 1.0.29b
firmware have the same wrong behaviour.
>What is the right way of having this ?

The problem with snom may be the phone uses some preloaded Routes
which are incompatible with some record-routing workaround for a Cisco
gateway problem in SER. I remember it was reported on the archive --
you perhaps find more there.

>My understanding is that in record route situation, ser looks into the
route header, and sends the message based on it. 


>Here I do have User Agents which seem to create an ACK message ignoring it
should go to a sip proxy .

You told above UA1 does send to proxy, did not you? It would be better to
send a complete message dump and config file.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: redirect-failure
Type: application/octet-stream
Size: 253496 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20040215/1bf6ab4c/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: redirect-ok
Type: application/octet-stream
Size: 144782 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20040215/1bf6ab4c/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ser.cfg-run
Type: application/octet-stream
Size: 13718 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20040215/1bf6ab4c/attachment-0002.obj>

More information about the sr-users mailing list