<div dir="ltr">Nice, be ware of the ALG, sometimes it's an unpredictable foe.<div><br></div><div>rgds,<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div>Loi Dang Thanh</div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 14, 2020 at 4:42 AM Michael Broughton <<a href="mailto:mbroughton@advanis.net">mbroughton@advanis.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Just to provide some closure to this, the problem did end up being with the Via headers and our firewall ALG.<div><br></div><div><div>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.</div><div><br></div><div>I was able to fix the issue by modifying our Kam config with the advertise parameter:</div></div><div><br></div><div>listen = 10.x.y.z advertise 10.x.y.z:5060<br></div><div><br></div><div>With this setting in place the ALG is forced to behave itself.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 9, 2020 at 9:27 AM Michael Broughton <<a href="mailto:mbroughton@advanis.net" target="_blank">mbroughton@advanis.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I'm using 5.3.1+stretch from <a href="http://deb.kamailio.org" target="_blank">deb.kamailio.org</a> for our new setup. Our old setup was using 4.4.4+wheezy.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 9, 2020 at 9:16 AM Daniel-Constantin Mierla <<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Is it a recent version of kamailio, or an older one?</p>
<p>Cheers,<br>
Daniel<br>
</p>
<div>On 09.01.20 16:55, Michael Broughton
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Thank you, this was a helpful sanity check.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Anyway, thanks again for your input.</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Jan 9, 2020 at 4:04 AM
Lợi Đặng <<a href="mailto:loi.dangthanh@gmail.com" target="_blank">loi.dangthanh@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>Hi, </div>
<div>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`.</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>rgds,</div>
<div>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div>Loi Dang Thanh<br>
</div>
Phone : +84. 774.735.448<br>
</div>
Email : <a href="mailto:loi.dangthanh@gmail.com" target="_blank">loi.dangthanh@gmail.com</a><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Jan 9, 2020 at
2:42 AM Michael Broughton <<a href="mailto:mbroughton@advanis.net" target="_blank">mbroughton@advanis.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Hello,
<div><br>
</div>
<div>Long time Kam/Ser user, first time poster.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>Or, do I just need to poke them harder to fix their
issues?</div>
<div><br>
</div>
<div>My setup:</div>
<div><br>
</div>
<div>Source -> Kamailio -> Firewall (NAT, SIP ALG)
-> Telco Provider</div>
<div><br>
</div>
<div>I hope I have provided enough information.</div>
<div><br>
</div>
<div>Thanks!</div>
<div>Michael</div>
<div><br>
</div>
<div><br>
</div>
</div>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote>
</div>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Kamailio (SER) - Users Mailing List
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<pre cols="72">--
Daniel-Constantin Mierla -- <a href="http://www.asipto.com" target="_blank">www.asipto.com</a>
<a href="http://www.twitter.com/miconda" target="_blank">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" target="_blank">www.linkedin.com/in/miconda</a>
Kamailio World Conference - April 27-29, 2020, in Berlin -- <a href="http://www.kamailioworld.com" target="_blank">www.kamailioworld.com</a></pre>
</div>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div>