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