1) I would need the real ACK (yours seems to be changed for privacy reasons?)--I'm a bit surprised to see same IP in rURI and Route; that can't really work; I'm guessing that was a rewriting mistake? 2) I would need the config file (with some disclaimers -- not sure when and how fast I can parse 51k :-))
-jiri
At 22:02 21/02/2008, SIP wrote:
According to the log statement I placed into the loose_route() section, this ACK never hits loose_route at any point.
And yeah... the whole ACK thing is confusing me. Not sure where it's supposed to go in there.
By sending you the whole script, what do you mean? Do you want me to send you the whole config (I have to warn you, it's 51k and rather complex) or the whole log? Or both?
N.
Jiri Kuthan wrote:
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@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@proxy01.sipphone.com:5060;tag=j5j3wijb3t. To: sip:1101301@proxy01.sipphone.com;user=phone;tag=as6c9ca1f6. Call-ID: 3c26d1cab239-obtsvl9px3gg@snom190. CSeq: 1 ACK. Max-Forwards: 16. Contact: sip:17471111111@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@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@proxy01.sipphone.com:5060;tag=j5j3wijb3t. To: sip:1101301@proxy01.sipphone.com;user=phone;tag=as6c9ca1f6. Call-ID: 3c26d1cab239-obtsvl9px3gg@snom190. CSeq: 1 ACK. Max-Forwards: 2. Contact: sip:17471111111@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/