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 List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users