[SR-Users] Missing ACK

[Klaus Darilion]

Am 01.07.2010 22:33, schrieb Ole Kaas:
> Hello,
>
> The guy operating the Asterisk at the far end have been inspecting
> the traces I've sent him. Hen notes that the ACK relayed doesn't
> entirely comply to the standard.  The values of "branch"  in the VIA
> header of the relayed ACK response incorrectly have the value "0"
> (also rport in the VIA header added by their Asterisk is modified).
> He suggest setting the syn_branch parameter to get the "branch"
> right. I've found this thread about it:
>
> http://blog.gmane.org/gmane.comp.voip.ser/month=20090701

This some question pops up again and again. The RFC is not 100% clear in 
this aspect. It states that any RFC3261 compatible UA/proxy must add a 
unique branch parameter, starting with the magic cookie. (Thus, Kamailio 
should use a unique branch in ACK).

Further RFC3261 states, that if a user agent receives a SIP request 
where the topmost Via header contains a branch parameter which does not 
start with the magic cookie, the UA has to accept the request and uses 
RFC2543-based transaction matching.

Thus, Kamailio - when used as RFC3261 complient proxy - should use a 
unique branch parameter. On the other hand, RFC3261 compatible clients 
should accept branch=0 too.

I just wonder why this Asterisk-based Gateway does not accept branch=0. 
I have several Asterisk versions in use and never experienced any issue 
with branch=0.

regards
Klaus


> I have put syn_branch=0 in the config and "branch" now have a valid
> value. I don't quite buy it - that the incorrect value of "branch"
> should be the culprit.  But I'll activate tcpdump again and wait to
> see if the dropped calls has vanished.
>
> /Ole
>
> Den 01/07/2010 kl. 09.12 skrev Klaus Darilion:
>
>> Hi!
>>
>> Kamailio behaves correct in this trace and I couldn't spot an
>> abvious error in the trace.
>>
>> Nevertheless there are 2 problems:
>>
>> 1. Asterisk Gateway does not receive/accept the ACK 2. Asterisk PBX
>> does not retransmit ACK
>>
>> reg. 1: ask the gateway operator if he sees the ACK in the Asterisk
>> log, and if yes the error message of Asterisk why this ACK is not
>> accepted. If the ACK is not seen in the Asterisk console then maybe
>> it gets dropped by a buggy firewall.
>>
>> reg 2: login to your Asterisk PBX and verify if Asterisk receives
>> the 200 OK, and maybe spot some log message why it does not trigger
>> ACK retransmissions.
>>
>> regards Klaus
>>
>> Am 30.06.2010 23:33, schrieb Ole Kaas:
>>>
>>> Den 30/06/2010 kl. 01.23 skrev Iñaki Baz Castillo:
>>>
>>>> 2010/6/29 Ole Kaas<obk at tet.dk>:
>>>>> Hi Klaus,
>>>>>
>>>>> I've mailed pcap dump to you directly for further
>>>>> inspection.
>>>>
>>>> Hi, it's much better if you capture a trace with "ngrep
>>>> -Wbyline -t -q port 5060" and paste it in a new mail by
>>>> replacing your public IP's with other values. Then all the
>>>> people here could help you rather than asking for private help
>>>> to a specific member of the maillist.
>>>>
>>>
>>> You are right. But maybe it was something (obvious) that could be
>>> resolved quickly and I could post an update here on the list. The
>>> original log was inadequate - Klaus was a great help, with
>>> suggestions to obtain new log. So here it is attached and
>>> anonymized with all ip addresses (and stuff) converted to private
>>> adresses. The Kamailio server is multi homed and the two networks
>>> are non-routable (I use rtpproxy to bridge media). Our Asterisk
>>> PBX is version 1.4.26.1 and the Asterisk Gateway is 1.6.1 (or
>>> 1.6.0 - cant remember and not under my control). Kamailio is
>>> version 3.0.0.
>>>
>>> Looking at the trace, it seems the problem starts with the ACK
>>> not being received by the Asterisk Gateway which then resends the
>>> OK. The OK is relayed back to the originating Asterisk PBX which
>>> seems to ignore the retransmission. In fact it seems that
>>> Kamailio is routing and relaying the sip packets correctly.
>>> However, it seems that the problem only exists between Asterisk
>>> and Kamailio. I have other pbx'es (3CX) connecting to Kamailio
>>> and I have no evidence that the problem happens with those. I
>>> have another trace where the call comes from one of the Asterisk
>>> Gateways  and is routed back to one of the other Asterisk
>>> Gateways. The result is the same - the OK's are ignored by
>>> Asterisk.
>>>
>>> /Ole
>>>
>