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 <mailto: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 <mailto:mbrough...@advanis.net>> wrote: > > I'm using 5.3.1+stretch from deb.kamailio.org > <http://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 <mailto: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 >> <mailto: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 >> <mailto:loi.dangth...@gmail.com> >> >> >> On Thu, Jan 9, 2020 at 2:42 AM Michael Broughton >> <mbrough...@advanis.net >> <mailto: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 >> <mailto: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 >> <mailto: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 <mailto:sr-users@lists.kamailio.org> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > -- > Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> > www.twitter.com/miconda <http://www.twitter.com/miconda> -- > www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> > Kamailio World Conference - April 27-29, 2020, in Berlin -- > www.kamailioworld.com <http://www.kamailioworld.com> > > _______________________________________________ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org <mailto: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 -- Daniel-Constantin Mierla -- www.asipto.com www.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