[SR-Users] Negative ACK issue

Wed Jan 15 17:47:35 CET 2020

Best "workaround" is most likely disabling SIP ALG entirely. Fortinets
along with Sonicwalls are notorious in this regard.

On Tue, Jan 14, 2020 at 10:54 AM Michael Broughton <mbroughton at advanis.net>
wrote:

> FortiGate 200E, OS 6.0.6.
>
> I opened a support ticket, but they didn't seem to worry about it once I
> found a workaround.
>
> On Tue, Jan 14, 2020 at 2:21 AM Daniel-Constantin Mierla <
> miconda at gmail.com> wrote:
>
>> Curious about the ALG vendor/model/version, if it is some
>> carrier/enterprise grade firewall, just to be aware when meeting it ... of
>> course, if you can and want to share such details...
>>
>> Cheers,
>> Daniel
>> On 14.01.20 08:42, Lợi Đặng wrote:
>>
>> Nice, be ware of the ALG, sometimes it's an unpredictable foe.
>>
>> rgds,
>> Loi Dang Thanh
>>
>>
>> On Tue, Jan 14, 2020 at 4:42 AM Michael Broughton <mbroughton at advanis.net>
>> wrote:
>>
>>> 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 parameter:
>>>
>>> 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>
>>> wrote:
>>>
>>>> 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
>>>>>
>>>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200115/aa0574cb/attachment.html>