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 <mbrough...@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 < > mico...@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 <mbrough...@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 <mbrough...@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 < >>>> mico...@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.dangth...@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.dangth...@gmail.com >>>>>> >>>>>> >>>>>> On Thu, Jan 9, 2020 at 2:42 AM Michael Broughton < >>>>>> mbrough...@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@lists.kamailio.org >>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>>>> >>>>>> _______________________________________________ >>>>>> Kamailio (SER) - Users Mailing List >>>>>> sr-users@lists.kamailio.org >>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Kamailio (SER) - Users Mailing >>>>> Listsr-users@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@lists.kamailio.org >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing >> Listsr-users@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@lists.kamailio.org >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > _______________________________________________ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users