[Serusers] Still having problems with these ACKs (and BYEs).

[Jiri Kuthan]

It is not clear to me if the ACK in your script hits loose_route()....
It would be ideal if you could send the whole script.
Also the request-URI has the same IP address as the Route header field -- where
else shall the request go than to a loop? 

-jiri

At 20:40 21/02/2008, SIP wrote:
>While it all works fine for our locally-registered users (and for some 
>of our peers), I'm still having problems from some peers dialing numbers 
>on our service.  What happens is that we get an ACK (all our ACKs are 
>set to simply relay), and that ACK bounces around inside our server for 
>a while, then times out without ever replying -- which, after a short 
>period of time, cancels the connection for the peer, since they don't 
>see any ACK replies.
>
>We start with a normal ACK sent from the remote peer (198.65.166.131) to 
>our server (22.33.44.55):
>
>U 198.65.166.131:5060 -> 22.33.44.55:5060
>ACK sip:301 at 22.33.44.55:5060 SIP/2.0.
>Record-Route: <sip:198.65.166.131;ftag=j5j3wijb3t;lr>.
>Via: SIP/2.0/UDP 198.65.166.131;branch=0.
>Via: SIP/2.0/UDP 
>192.168.1.51:2051;received=63.95.254.25;branch=z9hG4bK-wv3vqqoh
>qdm9;rport=2051.
>Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>.
>From: "User One" <sip:17471111111 at proxy01.sipphone.com:5060>;tag=j5j3wijb3t.
>To: <sip:1101301 at proxy01.sipphone.com;user=phone>;tag=as6c9ca1f6.
>Call-ID: 3c26d1cab239-obtsvl9px3gg at snom190.
>CSeq: 1 ACK.
>Max-Forwards: 16.
>Contact: <sip:17471111111 at 192.168.1.51:2051;line=ir1tukx9;nat=yes>.
>Content-Length: 0.
>P-hint: rr-enforced.
>P-NATed-URI: YES (1).
>P-RTP-Proxy: YES (1).
>
>We end up getting things that look like this:
>
>U 22.33.44.55:5060 -> 22.33.44.55:5060
>ACK sip:301 at 22.33.44.55:5060 SIP/2.0.
>Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>.
>Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>.
>Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>.
>Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>.
>Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>.
>Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>.
>Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>.
>Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>.
>Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>.
>Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>.
>Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>.
>Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>.
>Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>.
>Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>.
>Record-Route: <sip:198.65.166.131;ftag=j5j3wijb3t;lr>.
>Via: SIP/2.0/UDP 22.33.44.55;branch=0.
>Via: SIP/2.0/UDP 22.33.44.55;branch=0.
>Via: SIP/2.0/UDP 22.33.44.55;branch=0.
>Via: SIP/2.0/UDP 22.33.44.55;branch=0.
>Via: SIP/2.0/UDP 22.33.44.55;branch=0.
>Via: SIP/2.0/UDP 22.33.44.55;branch=0.
>Via: SIP/2.0/UDP 22.33.44.55;branch=0.
>Via: SIP/2.0/UDP 22.33.44.55;branch=0.
>Via: SIP/2.0/UDP 22.33.44.55;branch=0.
>Via: SIP/2.0/UDP 22.33.44.55;branch=0.
>Via: SIP/2.0/UDP 22.33.44.55;branch=0.
>Via: SIP/2.0/UDP 22.33.44.55;branch=0.
>Via: SIP/2.0/UDP 22.33.44.55;branch=0.
>Via: SIP/2.0/UDP 22.33.44.55;branch=0.
>Via: SIP/2.0/UDP 198.65.166.131;branch=0.
>Via: SIP/2.0/UDP 
>192.168.1.51:2051;received=63.95.254.25;branch=z9hG4bK-wv3vqqoh
>qdm9;rport=2051.
>From: "User One" <sip:17471111111 at proxy01.sipphone.com:5060>;tag=j5j3wijb3t.
>To: <sip:1101301 at proxy01.sipphone.com;user=phone>;tag=as6c9ca1f6.
>Call-ID: 3c26d1cab239-obtsvl9px3gg at snom190.
>CSeq: 1 ACK.
>Max-Forwards:  2.
>Contact: <sip:17471111111 at 192.168.1.51:2051;line=ir1tukx9;nat=yes>.
>Content-Length: 0.
>P-hint: rr-enforced.
>P-NATed-URI: YES (1).
>P-RTP-Proxy: YES (1).
>
>
>
>The top of that message shows that this is a message sent from our 
>server to our server, and it just tacks on a Record-Route and a Via line 
>one after another until it times out.
>
>Again, my ACK handler is simply:
>
>    if(method=="ACK")
>    {
>        route(1);
>        break;
>    }
>
>
>The record route is the very basic:
>
>    if(method!="REGISTER")
>    {
>        record_route();
>    };
>
>
>And route[1] is just:
>
>route[1]
>{
> 
>    if (!t_relay())
>    {
>        sl_reply_error();
>    };
>
>}
>
>
>
>
>All very basic stuff (and straight from the getting started pages I 
>think), and it mostly all works. Local users have no issues. Some peers 
>are okay.
>
>But several of them are NOT, and I've tried everything I can think of 
>and can't get ACKs to behave. Can someone give me a bit of a clue as to 
>what to look at?
>
>I don't understand the reason for tacking on another RR param each time 
>(nor do I REALLY understand why the lr=on is tacked on when this is 
>clearly not loose-routed). Some days, I feel like I really have a handle 
>on SER. Other days, I feel like I'm stumbling blindly. I never seem to 
>get to a level of comfort.
>
>N.
>_______________________________________________
>Serusers mailing list
>Serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers



--
Jiri Kuthan            http://iptel.org/~jiri/