[Serusers] Still having problems with these ACKs (and BYEs).
Jiri Kuthan
jiri at iptel.org
Thu Feb 21 22:29:18 CET 2008
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 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/
>>
>
>_______________________________________________
>Serusers mailing list
>Serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
More information about the sr-users
mailing list