[Serusers] UAs not respecting Record Route

Jiri Kuthan jiri at iptel.org
Sun Feb 15 21:42:29 CET 2004


At 08:46 PM 2/15/2004, Samy Touati wrote:
>Hi,
> 
>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 doesn’t 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 22.2.4.193:5071 SIP/2.0
>        Method: ACK
>    Message Header
>        Via: SIP/2.0/UDP 2.20.64.193:5063;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 142.133.80.102
>        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 24.202.64.193:5063>
>        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 once).

Interesting -- it looks like properly generated ACK, except the URI in Route
has some strange value -- I mean SER generates the URI as 
     sip:<username_from_INVITE>@<SER_IP>;ftag=...
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 22.2.4.193:5071>
>        Via: SIP/2.0/UDP 2.20.64.193:5063
>        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 142.133.80.101
>        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 UA3.
> 
>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. 

yes

>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.

-jiri 




More information about the sr-users mailing list