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

SIP sip at arcdiv.com
Thu Feb 21 20:40:50 CET 2008


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.



More information about the sr-users mailing list