8 Jan
2020
8 Jan
'20
8:41 p.m.
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
9 Jan
9 Jan
11:59 a.m.
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
4:55 p.m.
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
5:16 p.m.
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
<mailto:loi.dangthanh@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 <mailto:loi.dangthanh@gmail.com>
On Thu, Jan 9, 2020 at 2:42 AM Michael Broughton
<mbroughton(a)advanis.net <mailto:mbroughton@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 <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)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(a)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
5:27 p.m.
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 <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:
_______________________________________________
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
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
13 Jan
13 Jan
10:41 p.m.
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 <mbroughton(a)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 <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
>
>
14 Jan
14 Jan
8:42 a.m.
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 <mbroughton(a)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 <mbroughton(a)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 <
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
>
> _______________________________________________
Kamailio (SER) - Users Mailing
List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
10:20 a.m.
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
<mbroughton(a)advanis.net <mailto:mbroughton@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
<mbroughton(a)advanis.net <mailto:mbroughton@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
<miconda(a)gmail.com <mailto:miconda@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:
--
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
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
<mailto:loi.dangthanh@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
<mailto:loi.dangthanh@gmail.com>
On Thu, Jan 9, 2020 at 2:42 AM Michael Broughton
<mbroughton(a)advanis.net
<mailto:mbroughton@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
<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)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(a)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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
4:46 p.m.
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 <miconda(a)gmail.com>
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 <mbroughton(a)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 <mbroughton(a)advanis.net>
wrote:
_______________________________________________
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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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 <
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
>
> _______________________________________________
Kamailio (SER) - Users Mailing
List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
15 Jan
15 Jan
5:47 p.m.
Best "workaround" is most likely disabling SIP ALG entirely. Fortinets
along with Sonicwalls are notorious in this regard.
On Tue, Jan 14, 2020 at 10:54 AM Michael Broughton <mbroughton(a)advanis.net>
wrote:
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 <
miconda(a)gmail.com> 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 <mbroughton(a)advanis.net>
wrote:
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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 <mbroughton(a)advanis.net>
wrote:
_______________________________________________
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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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 <
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
>
> _______________________________________________
Kamailio (SER) - Users Mailing
List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
1566
days inactive
1573
days old
9 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Lợi Đặng -
Michael Broughton -
Sergiu Pojoga