[SR-Users] Negative ACK issue

Michael Broughton mbroughton at advanis.net
Mon Jan 13 22:41:33 CET 2020

Just to provide some closure to this, the problem did end up being with the
Via headers and our firewall ALG.

In the top Via header of the INVITE requests the ALG was transforming the
internal proxy address to our external address and adding port 5060. In
subsequent negative ACK and CANCEL requests, the ALG was transforming the
internal proxy address to our external address with no port number. Thus
the Via's did not exactly match, and this prevented our telco from matching
the existing transaction.

I was able to fix the issue by modifying our Kam config with the advertise

listen = 10.x.y.z advertise 10.x.y.z:5060

With this setting in place the ALG is forced to behave itself.

On Thu, Jan 9, 2020 at 9:27 AM Michael Broughton <mbroughton at advanis.net>

> I'm using 5.3.1+stretch from deb.kamailio.org for our new setup. Our old
> setup was using 4.4.4+wheezy.
> On Thu, Jan 9, 2020 at 9:16 AM Daniel-Constantin Mierla <miconda at gmail.com>
> wrote:
>> Is it a recent version of kamailio, or an older one?
>> Cheers,
>> Daniel
>> On 09.01.20 16:55, Michael Broughton wrote:
>> Thank you, this was a helpful sanity check.
>> We have been capturing SIP traces to try and debug this. I normally just
>> look at the traffic on our Kam box because it is convenient to do so, but I
>> have also taken traces on our firewall to check the ALG behaviour. The
>> provider techs are also tracing these calls on their network as well. The
>> ALG is new equipment in our setup, but as far as I can tell it is behaving
>> correctly.
>> The one rather annoying discovery that I made is that when I call
>> directly out from the source (Freeswitch in this case) and bypass Kamailio,
>> the negative ACK's seem to work. I do not see any retransmissions of their
>> final response. And of course the only significant difference in the SIP
>> traces is the Via headers.
>> Anyway, thanks again for your input.
>> On Thu, Jan 9, 2020 at 4:04 AM Lợi Đặng <loi.dangthanh at gmail.com> wrote:
>>> Hi,
>>> You're not going to have the Via header from your `source` sent to your
>>> `telco provider` in the negative ACK when the call is not answered, because
>>> the ACK in the right hand side of the call is created by the kamailio
>>> itself, not a forwarding one by the `source`.
>>> Yes, you've guessed it, ACK for an answered call is a forwarding one
>>> which contains all the Via headers. It's the SIP spec, not kamailio, you
>>> may want to dive into rfc3261 for more details.
>>> In this case, your telco's expectation is not correct, my best guess is
>>> something went wrong with either your SIP ALG or Telco Provider. SIP
>>> capturing may help.
>>> rgds,
>>> Loi Dang Thanh
>>> Phone : +84. 774.735.448
>>> Email : loi.dangthanh at gmail.com
>>> On Thu, Jan 9, 2020 at 2:42 AM Michael Broughton <mbroughton at advanis.net>
>>> wrote:
>>>> Hello,
>>>> Long time Kam/Ser user, first time poster.
>>>> I'm running into a problem with one of our telco providers when we make
>>>> a call that ends up being not in service or some other error. In this case
>>>> our ACK's are not working and the phone line stays open for a period
>>>> of time until something times out on their end.
>>>> They claim the issue is that our negative ACK message is dropping one
>>>> of the Via headers. This is the only case I can find in our setup where
>>>> Kamailio does this. But it does drop the first Via, which is the first hop
>>>> in our internal network.
>>>> I don't understand why this is a problem for them, and I'm still trying
>>>> to get a reasonable explanation out of them. Technically, I don't see why
>>>> it would be a problem. This behaviour is not an issue with our other telco
>>>> providers. Strangely enough, it is also not an issue for this provider when
>>>> we make the calls over their MPLS network (we are switching to the
>>>> internet).
>>>> My question is, can this behaviour be changed in Kamailio somehow? Is
>>>> there a way for it to keep all the Via headers for negative ACK's?
>>>> Or, do I just need to poke them harder to fix their issues?
>>>> My setup:
>>>> Source -> Kamailio -> Firewall (NAT, SIP ALG) -> Telco Provider
>>>> I hope I have provided enough information.
>>>> Thanks!
>>>> Michael
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users at lists.kamailio.org
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> _______________________________________________
>> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> --
>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
>> Kamailio World Conference - April 27-29, 2020, in Berlin -- www.kamailioworld.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200113/b8ab6192/attachment.html>

More information about the sr-users mailing list