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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 < >>> [email protected]> 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 <[email protected]> >>>> 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 : [email protected] >>>>> >>>>> >>>>> On Thu, Jan 9, 2020 at 2:42 AM Michael Broughton < >>>>> [email protected]> 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 >>>>>> [email protected] >>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>>> >>>>> _______________________________________________ >>>>> Kamailio (SER) - Users Mailing List >>>>> [email protected] >>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>> >>>> >>>> _______________________________________________ >>>> Kamailio (SER) - Users Mailing >>>> [email protected]https://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 >> [email protected] >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > > _______________________________________________ > Kamailio (SER) - Users Mailing > [email protected]https://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 > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
