Re: [asterisk-users] problems with natted phones

[Marek Greško]

Hello,

I already read the scenario you pointed to. It is not really the same.
as you can see in my rules I sent before I have CT in both directions.

Related to configuration error I am 99% sure the configuration is
correct. It was generated by automatic tool and then slightly edited
and reviewed by nftables guru. I just admit the there could be some
configuration error. Maybe some race condition in systemd - wrong
dependencies or something like that. I do not know. But I am sure once
I will find it (or suffer longer).

The reason many people use it and they will notice is invalid. I hit a
bug in PMTU dicovery several moths ago. And no one was complaining at
all. The bug is now fixed, so it is pretty probable it is a bug.

The reasoning that no expliot has been found in rtp for 20 year is
invalid. We are not talking about bugs in rtp. We are talking about
open ports and application local to asterisk server could use. So many
backdoors can be open. Believe me. It is not secure. Maybe it is
acceptable on a dedicated asterisk box, but not on a multi purpose
server.

Marek


2021-09-10 23:28 GMT+02:00, Duncan Turnbull :
>
>
>> On 11/09/2021, at 2:54 AM, Marek Greško  wrote:
>>
>> Hello,
>>
>> thanks you very much for your effort. Without your help I would never
>> realize the problem lies in the firewall.
>>
>> But what do you mean by the doubt that it is bug? You mean it should
>> be configured another way? I do not claim my configuration is correct.
>> I am also new to nftables. But I do not think opening the wide port
>> range is a solution. The nftables runs on the asterisk server itself.
>
> The reason I don’t use sip algs is because they have a have a function that
> isn’t required. And a complexity that messes things up. No exploit has yet
> been found for rtp for 20 years and it has been open to the world. For
> whatever reason you can’t get your head around this being a valid option so
> then you are jumping to a bug when you freely admit your lack of familiarity
>
>
> This may be your scenario
>
> https://unix.stackexchange.com/questions/461320/nf-conntrack-sip-does-not-work-sometimes-restarting-iptables-usually-fixes-it
>
> You are adding a dependency on the firewall that you don’t need using
> configuration you are not sure of. That is never a reliable situation to be
> in.
>
> Why would nftables have a bug? Many people use it around the world and it
> works well. What is the likelihood of a bug in this scenario
>
> The alternative is a misconfiguration, and you are not very familiar with
> the configuration and new to nftables. Which one is more likely?
>
> The above issue sounds like yours but it could be something else
>
> You can research and find the config error, or somehow you can prove a bug
> or you can remove the issue by just allowing rtp through
>
> All of these are your choices. To me the config error is most likely as I
> have very rarely found a bug. It’s almost always config
>
>>
>> Marek
>>
>>
>> 2021-09-10 1:19 GMT+02:00, Duncan Turnbull :
>>>
>>>
> On 10/09/2021, at 4:37 AM, Marek Greško  wrote:

 There are other systems running on the same hardware. It would just
 leave open ports here.

 Do not compare SIP ALG on a closed source device to an opensource
 software with active development. I had no such problems in the past
 when using iptables. The nftables is a pretty new software, so some
 bugs could be present and I accept. I just wanted to be sure I am not
 doing anything wrong. Now I am pretty sure it is a bug.
>>>
>>> I very much doubt it’s a bug, but that’s your choice to pursue that
>>>
>>> You ask for help but perhaps you are not wanting to listen
>>>
>>> If you open your asterisk rtp ports in your firewall then you are
>>> following
>>> pretty much what everyone else does.
>>>
>>> Otherwise you are letting another device interfere with your Sip
>>> transactions and we have already shown that’s a bad idea. Makes no
>>> difference whether it’s open source or not.
>>>
>>> But up to you
>>>

 Thanks

 Marek


 2021-09-09 18:30 GMT+02:00, Administrator :
>
>> Le 09/09/2021 à 18:15, Marek Greško a écrit :
>> There is always some risk. If there is a solution that should work,
>> it
>> is best to use it. We just need the root cause, why it fails
>> sometimes.
>
> Like SIP ALG ? ;) Please explain which risk are existing if there is
> nothing listening on those ports ?
>
>>
>>
>> 2021-09-09 18:01 GMT+02:00, Antony Stone
>> :
>>> On Thursday 09 September 2021 at 17:56:10, Marek Greško wrote:
>>>
 Hello,

 I would not like to open whole range of udp ports for rtp.
>>> Why not?  What is the risk?
>>>
>>> What would possibly be listening on UDP ports 1 - 2 (the
>>> Asterisk
>>> default range) which an external scanner / attacker could make use
>>> of?
>
> --
> Daniel
>
> --

Re: [asterisk-users] problems with natted phones

[Duncan Turnbull]

> On 11/09/2021, at 2:54 AM, Marek Greško  wrote:
> 
> Hello,
> 
> thanks you very much for your effort. Without your help I would never
> realize the problem lies in the firewall.
> 
> But what do you mean by the doubt that it is bug? You mean it should
> be configured another way? I do not claim my configuration is correct.
> I am also new to nftables. But I do not think opening the wide port
> range is a solution. The nftables runs on the asterisk server itself.

The reason I don’t use sip algs is because they have a have a function that 
isn’t required. And a complexity that messes things up. No exploit has yet been 
found for rtp for 20 years and it has been open to the world. For whatever 
reason you can’t get your head around this being a valid option so then you are 
jumping to a bug when you freely admit your lack of familiarity 

This may be your scenario 

https://unix.stackexchange.com/questions/461320/nf-conntrack-sip-does-not-work-sometimes-restarting-iptables-usually-fixes-it

You are adding a dependency on the firewall that you don’t need using 
configuration you are not sure of. That is never a reliable situation to be in. 

Why would nftables have a bug? Many people use it around the world and it works 
well. What is the likelihood of a bug in this scenario 

The alternative is a misconfiguration, and you are not very familiar with the 
configuration and new to nftables. Which one is more likely?

The above issue sounds like yours but it could be something else

You can research and find the config error, or somehow you can prove a bug or 
you can remove the issue by just allowing rtp through

All of these are your choices. To me the config error is most likely as I have 
very rarely found a bug. It’s almost always config 

> 
> Marek
> 
> 
> 2021-09-10 1:19 GMT+02:00, Duncan Turnbull :
>> 
>> 
 On 10/09/2021, at 4:37 AM, Marek Greško  wrote:
>>> 
>>> There are other systems running on the same hardware. It would just
>>> leave open ports here.
>>> 
>>> Do not compare SIP ALG on a closed source device to an opensource
>>> software with active development. I had no such problems in the past
>>> when using iptables. The nftables is a pretty new software, so some
>>> bugs could be present and I accept. I just wanted to be sure I am not
>>> doing anything wrong. Now I am pretty sure it is a bug.
>> 
>> I very much doubt it’s a bug, but that’s your choice to pursue that
>> 
>> You ask for help but perhaps you are not wanting to listen
>> 
>> If you open your asterisk rtp ports in your firewall then you are following
>> pretty much what everyone else does.
>> 
>> Otherwise you are letting another device interfere with your Sip
>> transactions and we have already shown that’s a bad idea. Makes no
>> difference whether it’s open source or not.
>> 
>> But up to you
>> 
>>> 
>>> Thanks
>>> 
>>> Marek
>>> 
>>> 
>>> 2021-09-09 18:30 GMT+02:00, Administrator :
 
> Le 09/09/2021 à 18:15, Marek Greško a écrit :
> There is always some risk. If there is a solution that should work, it
> is best to use it. We just need the root cause, why it fails
> sometimes.
 
 Like SIP ALG ? ;) Please explain which risk are existing if there is
 nothing listening on those ports ?
 
> 
> 
> 2021-09-09 18:01 GMT+02:00, Antony Stone
> :
>> On Thursday 09 September 2021 at 17:56:10, Marek Greško wrote:
>> 
>>> Hello,
>>> 
>>> I would not like to open whole range of udp ports for rtp.
>> Why not?  What is the risk?
>> 
>> What would possibly be listening on UDP ports 1 - 2 (the
>> Asterisk
>> default range) which an external scanner / attacker could make use of?
 
 --
 Daniel
 
 --
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com --
 
 Check out the new Asterisk community forum at:
 https://community.asterisk.org/
 
 New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started
 
 asterisk-users mailing list
 To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users
>>> 
>>> --
>>> _
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>> 
>>> Check out the new Asterisk community forum at:
>>> https://community.asterisk.org/
>>> 
>>> New to Asterisk? Start here:
>>> https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>>> 
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>  http://lists.digium.com/mailman/listinfo/asterisk-users
>> 
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> 
>> Check out the new Asterisk community forum at:
>> 

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Hello,

thanks you very much for your effort. Without your help I would never
realize the problem lies in the firewall.

But what do you mean by the doubt that it is bug? You mean it should
be configured another way? I do not claim my configuration is correct.
I am also new to nftables. But I do not think opening the wide port
range is a solution. The nftables runs on the asterisk server itself.

Marek


2021-09-10 1:19 GMT+02:00, Duncan Turnbull :
>
>
>> On 10/09/2021, at 4:37 AM, Marek Greško  wrote:
>>
>> There are other systems running on the same hardware. It would just
>> leave open ports here.
>>
>> Do not compare SIP ALG on a closed source device to an opensource
>> software with active development. I had no such problems in the past
>> when using iptables. The nftables is a pretty new software, so some
>> bugs could be present and I accept. I just wanted to be sure I am not
>> doing anything wrong. Now I am pretty sure it is a bug.
>
> I very much doubt it’s a bug, but that’s your choice to pursue that
>
> You ask for help but perhaps you are not wanting to listen
>
> If you open your asterisk rtp ports in your firewall then you are following
> pretty much what everyone else does.
>
> Otherwise you are letting another device interfere with your Sip
> transactions and we have already shown that’s a bad idea. Makes no
> difference whether it’s open source or not.
>
> But up to you
>
>>
>> Thanks
>>
>> Marek
>>
>>
>> 2021-09-09 18:30 GMT+02:00, Administrator :
>>>
 Le 09/09/2021 à 18:15, Marek Greško a écrit :
 There is always some risk. If there is a solution that should work, it
 is best to use it. We just need the root cause, why it fails
 sometimes.
>>>
>>> Like SIP ALG ? ;) Please explain which risk are existing if there is
>>> nothing listening on those ports ?
>>>


 2021-09-09 18:01 GMT+02:00, Antony Stone
 :
> On Thursday 09 September 2021 at 17:56:10, Marek Greško wrote:
>
>> Hello,
>>
>> I would not like to open whole range of udp ports for rtp.
> Why not?  What is the risk?
>
> What would possibly be listening on UDP ports 1 - 2 (the
> Asterisk
> default range) which an external scanner / attacker could make use of?
>>>
>>> --
>>> Daniel
>>>
>>> --
>>> _
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> Check out the new Asterisk community forum at:
>>> https://community.asterisk.org/
>>>
>>> New to Asterisk? Start here:
>>>  https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>>>
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> Check out the new Asterisk community forum at:
>> https://community.asterisk.org/
>>
>> New to Asterisk? Start here:
>>  https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Duncan Turnbull]

> On 10/09/2021, at 4:37 AM, Marek Greško  wrote:
> 
> There are other systems running on the same hardware. It would just
> leave open ports here.
> 
> Do not compare SIP ALG on a closed source device to an opensource
> software with active development. I had no such problems in the past
> when using iptables. The nftables is a pretty new software, so some
> bugs could be present and I accept. I just wanted to be sure I am not
> doing anything wrong. Now I am pretty sure it is a bug.

I very much doubt it’s a bug, but that’s your choice to pursue that

You ask for help but perhaps you are not wanting to listen

If you open your asterisk rtp ports in your firewall then you are following 
pretty much what everyone else does. 

Otherwise you are letting another device interfere with your Sip transactions 
and we have already shown that’s a bad idea. Makes no difference whether it’s 
open source or not.  

But up to you

> 
> Thanks
> 
> Marek
> 
> 
> 2021-09-09 18:30 GMT+02:00, Administrator :
>> 
>>> Le 09/09/2021 à 18:15, Marek Greško a écrit :
>>> There is always some risk. If there is a solution that should work, it
>>> is best to use it. We just need the root cause, why it fails
>>> sometimes.
>> 
>> Like SIP ALG ? ;) Please explain which risk are existing if there is
>> nothing listening on those ports ?
>> 
>>> 
>>> 
>>> 2021-09-09 18:01 GMT+02:00, Antony Stone
>>> :
 On Thursday 09 September 2021 at 17:56:10, Marek Greško wrote:
 
> Hello,
> 
> I would not like to open whole range of udp ports for rtp.
 Why not?  What is the risk?
 
 What would possibly be listening on UDP ports 1 - 2 (the Asterisk
 default range) which an external scanner / attacker could make use of?
>> 
>> --
>> Daniel
>> 
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> 
>> Check out the new Asterisk community forum at:
>> https://community.asterisk.org/
>> 
>> New to Asterisk? Start here:
>>  https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>> 
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
> 
> -- 
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> Check out the new Asterisk community forum at: https://community.asterisk.org/
> 
> New to Asterisk? Start here:
>  https://wiki.asterisk.org/wiki/display/AST/Getting+Started
> 
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Administrator]

Le 09/09/2021 à 18:15, Marek Greško a écrit :

There is always some risk. If there is a solution that should work, it
is best to use it. We just need the root cause, why it fails
sometimes.


Like SIP ALG ? ;) Please explain which risk are existing if there is 
nothing listening on those ports ?





2021-09-09 18:01 GMT+02:00, Antony Stone :

On Thursday 09 September 2021 at 17:56:10, Marek Greško wrote:


Hello,

I would not like to open whole range of udp ports for rtp.

Why not?  What is the risk?

What would possibly be listening on UDP ports 1 - 2 (the Asterisk
default range) which an external scanner / attacker could make use of?


--
Daniel

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Marek Greško]

There are other systems running on the same hardware. It would just
leave open ports here.

Do not compare SIP ALG on a closed source device to an opensource
software with active development. I had no such problems in the past
when using iptables. The nftables is a pretty new software, so some
bugs could be present and I accept. I just wanted to be sure I am not
doing anything wrong. Now I am pretty sure it is a bug.

Thanks

Marek


2021-09-09 18:30 GMT+02:00, Administrator :
>
> Le 09/09/2021 à 18:15, Marek Greško a écrit :
>> There is always some risk. If there is a solution that should work, it
>> is best to use it. We just need the root cause, why it fails
>> sometimes.
>
> Like SIP ALG ? ;) Please explain which risk are existing if there is
> nothing listening on those ports ?
>
>>
>>
>> 2021-09-09 18:01 GMT+02:00, Antony Stone
>> :
>>> On Thursday 09 September 2021 at 17:56:10, Marek Greško wrote:
>>>
 Hello,

 I would not like to open whole range of udp ports for rtp.
>>> Why not?  What is the risk?
>>>
>>> What would possibly be listening on UDP ports 1 - 2 (the Asterisk
>>> default range) which an external scanner / attacker could make use of?
>
> --
> Daniel
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Marek Greško]

There is always some risk. If there is a solution that should work, it
is best to use it. We just need the root cause, why it fails
sometimes.

Marek


2021-09-09 18:01 GMT+02:00, Antony Stone :
> On Thursday 09 September 2021 at 17:56:10, Marek Greško wrote:
>
>> Hello,
>>
>> I would not like to open whole range of udp ports for rtp.
>
> Why not?  What is the risk?
>
> What would possibly be listening on UDP ports 1 - 2 (the Asterisk
> default range) which an external scanner / attacker could make use of?
>
>
> Antony.
>
> --
> Too many people spend money they haven't earned
> to buy things they don't want,
> to impress people they don't like.
>
>  - Will Rogers
>
>Please reply to the list;
>  please *don't* CC
> me.
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Antony Stone]

On Thursday 09 September 2021 at 17:56:10, Marek Greško wrote:

> Hello,
> 
> I would not like to open whole range of udp ports for rtp.

Why not?  What is the risk?

What would possibly be listening on UDP ports 1 - 2 (the Asterisk 
default range) which an external scanner / attacker could make use of?


Antony.

-- 
Too many people spend money they haven't earned
to buy things they don't want,
to impress people they don't like.

 - Will Rogers

   Please reply to the list;
 please *don't* CC me.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Hello,

I would not like to open whole range of udp ports for rtp. I use
nf_conntrack_sip module for dynamically opening relevant ports. And
there is probably some bug in it.

Marek


2021-09-08 23:12 GMT+02:00, Administrator :
> Hi. Our rules:
>
> Le 08/09/2021 à 22:43, Marek Greško a écrit :
>> Hello,
>>
>> I did converted from iptables by automatical script and then rewritten
>> myself, because not everything was rewritten successfully.
>>
>> Relevant parts:
>>
>> table ip filter {
>>ct helper sip {
>>  type "sip" protocol udp
>>  l3proto ip
>>}
>>
>>chain PREROUTING {
>>  type filter hook prerouting priority filter; policy accept;
>>  udp port 5060 ct helper set "sip"
>>}
>>
>>chain INPUT {
>>  ...
>>  ct state invalid drop
>>  ct state related accept
>>  ct state established accept
>>  ...
>>  iifname "ppp0" jump i-inet
>>}
>
> set world_udp.eth0 {
>      type inet_service
>      flags interval
>      elements = { iax, sip, sip-tls, 1-3 }
>      }
>
> chain input {
>      type filter hook input priority 0; policy drop;
>      iif "eth0" ip daddr  udp dport
> @world_udp.eth0 counter packets 15394440 bytes 3738156190 accept
>      
>
> As you see we take care on RTP port range defined in rtp,conf
>
>>
>>chain OUTPUT {
>>  type filter hook output priority filter; policy accept;
>>  udp port 5060 ct helper set "sip"
>>  ...
>>}
> chain output {
>      type filter hook output priority 0; policy drop;
>      oif "eth0" ct state established,related,new counter
> packets 17542533 bytes 6033494909 accept
>
> our default policy is to drop so we add new in ct state
>
>>
>>chain i-inet {
>>  ...
>>  udp port 5060 jump r-sip
>>  ...
>>}
>>
>>chain r-sip {
>>  ip saddr 192.0.2.0/24 accept
>>}
>> }
>>
>> table ip mangle {
>>chain PREROUTING {
>>  type filter hook prerouting priority mangle; policy accept;
>>  ...
>>  udp sport 5060 ip dscp set 0x04
>>}
>>
>>chain OUTPUT {
>>  type route hook output priority mangle; policy accept;
>>  ...
>>  udp dport 5060 ip dscp set 0x04
>>  ...
>>}
>> }
>>
>> table ip6 filter {
>>ct helper sip {
>>  type "sip" protocol udp
>>  l3proto ip6
>>}
>>
>>... pretty the same, but I have no ipv6 internet connectivity, so
>> this should not match ...
>>
>> }
>>
>>
>> Is there something incorrect?
>>
>> Thanks
>>
>> Marek
>>
>>
>>
>> 2021-09-08 21:17 GMT+02:00, Duncan Turnbull :
>>>
 On 9/09/2021, at 6:23 AM, Marek Greško  wrote:

 Hello,

 I confirm temporarily allowing all the udp communication from the nat
 ip address solved the problem, so the problem lies in the nftables.
 This is probably not the right forum to continue. Or is it? Does
 anybody have wide experience with nftables and sip?
>>> If you publish your rule set then we could look. Did you write the rules?
>>> What have you checked so far?
>>>
 Thanks

 Marek


 2021-09-07 10:40 GMT+02:00, Antony Stone
 :
> On Monday 06 September 2021 at 23:05:27, Duncan Turnbull wrote:
>
 On 7/09/2021, at 8:30 AM, Marek Greško  wrote:

 Hello,

 it is only local nftables with nf_conntrack_sip on the asterisk
 server. Probably a kernel bug? It did not trigger with previous
 providers since they had working SIP ALG. Now I hear no audio in
 both
 directions because outgoing rtp stream from asterisk goes to private
 address space and incoming stream is blocked. So the outgoing rtp
 could not be learnt to send to nat addess.
>> Maybe a bug but that’s less likely than a config error. Time to debug
>> your
>> nftables.
> Try temporarily simply turning the firewall off - allow all traffic
> through
> (although leave in place any NAT rules).
>
> If you then find that RTP works, you know where the problem lies.
>
>
> Antony.
> Regards
>
> --
> Daniel
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To 

Re: [asterisk-users] problems with natted phones

[Administrator]

Hi. Our rules:

Le 08/09/2021 à 22:43, Marek Greško a écrit :

Hello,

I did converted from iptables by automatical script and then rewritten
myself, because not everything was rewritten successfully.

Relevant parts:

table ip filter {
   ct helper sip {
 type "sip" protocol udp
 l3proto ip
   }

   chain PREROUTING {
 type filter hook prerouting priority filter; policy accept;
 udp port 5060 ct helper set "sip"
   }

   chain INPUT {
 ...
 ct state invalid drop
 ct state related accept
 ct state established accept
 ...
 iifname "ppp0" jump i-inet
   }


set world_udp.eth0 {
    type inet_service
    flags interval
    elements = { iax, sip, sip-tls, 1-3 }
    }

chain input {
    type filter hook input priority 0; policy drop;
    iif "eth0" ip daddr  udp dport 
@world_udp.eth0 counter packets 15394440 bytes 3738156190 accept

    

As you see we take care on RTP port range defined in rtp,conf



   chain OUTPUT {
 type filter hook output priority filter; policy accept;
 udp port 5060 ct helper set "sip"
 ...
   }

chain output {
    type filter hook output priority 0; policy drop;
    oif "eth0" ct state established,related,new counter 
packets 17542533 bytes 6033494909 accept


our default policy is to drop so we add new in ct state



   chain i-inet {
 ...
 udp port 5060 jump r-sip
 ...
   }

   chain r-sip {
 ip saddr 192.0.2.0/24 accept
   }
}

table ip mangle {
   chain PREROUTING {
 type filter hook prerouting priority mangle; policy accept;
 ...
 udp sport 5060 ip dscp set 0x04
   }

   chain OUTPUT {
 type route hook output priority mangle; policy accept;
 ...
 udp dport 5060 ip dscp set 0x04
 ...
   }
}

table ip6 filter {
   ct helper sip {
 type "sip" protocol udp
 l3proto ip6
   }

   ... pretty the same, but I have no ipv6 internet connectivity, so
this should not match ...

}


Is there something incorrect?

Thanks

Marek



2021-09-08 21:17 GMT+02:00, Duncan Turnbull :



On 9/09/2021, at 6:23 AM, Marek Greško  wrote:

Hello,

I confirm temporarily allowing all the udp communication from the nat
ip address solved the problem, so the problem lies in the nftables.
This is probably not the right forum to continue. Or is it? Does
anybody have wide experience with nftables and sip?

If you publish your rule set then we could look. Did you write the rules?
What have you checked so far?


Thanks

Marek


2021-09-07 10:40 GMT+02:00, Antony Stone
:

On Monday 06 September 2021 at 23:05:27, Duncan Turnbull wrote:


On 7/09/2021, at 8:30 AM, Marek Greško  wrote:

Hello,

it is only local nftables with nf_conntrack_sip on the asterisk
server. Probably a kernel bug? It did not trigger with previous
providers since they had working SIP ALG. Now I hear no audio in both
directions because outgoing rtp stream from asterisk goes to private
address space and incoming stream is blocked. So the outgoing rtp
could not be learnt to send to nat addess.

Maybe a bug but that’s less likely than a config error. Time to debug
your
nftables.

Try temporarily simply turning the firewall off - allow all traffic
through
(although leave in place any NAT rules).

If you then find that RTP works, you know where the problem lies.


Antony.

Regards

--
Daniel

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Duncan Turnbull]

> On 9/09/2021, at 8:46 AM, Marek Greško  wrote:
> 
> Sorry did convert, not did converted :)
> 
> 2021-09-08 22:43 GMT+02:00, Marek Greško :
>> Hello,
>> 
>> I did converted from iptables by automatical script and then rewritten
>> myself, because not everything was rewritten successfully.
>> 
>> Relevant parts:
>> 
>> table ip filter {
>>  ct helper sip {
>>type "sip" protocol udp
>>l3proto ip
>>  }
>> 
Where are the rules for rtp? This is an rtp problem. What ports are allowed for 
them? And what other udp rules exist that could be interfering 

On your asterisk what ports do you have assigned for rtp? What are the matching 
firewall rules?

>>  chain PREROUTING {
>>type filter hook prerouting priority filter; policy accept;
>>udp port 5060 ct helper set "sip"
>>  }
>> 
>>  chain INPUT {
>>...
>>ct state invalid drop
>>ct state related accept
>>ct state established accept
>>...
>>iifname "ppp0" jump i-inet
>>  }
>> 
>>  chain OUTPUT {
>>type filter hook output priority filter; policy accept;
>>udp port 5060 ct helper set "sip"
>>...
>>  }
>> 
>>  chain i-inet {
>>...
>>udp port 5060 jump r-sip
>>...
>>  }
>> 
>>  chain r-sip {
>>ip saddr 192.0.2.0/24 accept
>>  }
>> }
>> 
>> table ip mangle {
>>  chain PREROUTING {
>>type filter hook prerouting priority mangle; policy accept;
>>...
>>udp sport 5060 ip dscp set 0x04
>>  }
>> 
>>  chain OUTPUT {
>>type route hook output priority mangle; policy accept;
>>...
>>udp dport 5060 ip dscp set 0x04
>>...
>>  }
>> }
>> 
>> table ip6 filter {
>>  ct helper sip {
>>type "sip" protocol udp
>>l3proto ip6
>>  }
>> 
>>  ... pretty the same, but I have no ipv6 internet connectivity, so
>> this should not match ...
>> 
>> }
>> 
>> 
>> Is there something incorrect?
>> 
>> Thanks
>> 
>> Marek
>> 
>> 
>> 
>> 2021-09-08 21:17 GMT+02:00, Duncan Turnbull :
>>> 
>>> 
> On 9/09/2021, at 6:23 AM, Marek Greško  wrote:
> 
> Hello,
> 
> I confirm temporarily allowing all the udp communication from the nat
> ip address solved the problem, so the problem lies in the nftables.
> This is probably not the right forum to continue. Or is it? Does
> anybody have wide experience with nftables and sip?
>>> If you publish your rule set then we could look. Did you write the rules?
>>> What have you checked so far?
>>> 
 
 Thanks
 
 Marek
 
 
 2021-09-07 10:40 GMT+02:00, Antony Stone
 :
> On Monday 06 September 2021 at 23:05:27, Duncan Turnbull wrote:
> 
 On 7/09/2021, at 8:30 AM, Marek Greško  wrote:
 
 Hello,
 
 it is only local nftables with nf_conntrack_sip on the asterisk
 server. Probably a kernel bug? It did not trigger with previous
 providers since they had working SIP ALG. Now I hear no audio in
 both
 directions because outgoing rtp stream from asterisk goes to private
 address space and incoming stream is blocked. So the outgoing rtp
 could not be learnt to send to nat addess.
>> 
>> Maybe a bug but that’s less likely than a config error. Time to debug
>> your
>> nftables.
> 
> Try temporarily simply turning the firewall off - allow all traffic
> through
> (although leave in place any NAT rules).
> 
> If you then find that RTP works, you know where the problem lies.
> 
> 
> Antony.
> 
> --
> Perfection in design is achieved not when there is nothing left to add,
> but
> rather when there is nothing left to take away.
> 
> - Antoine de Saint-Exupery
> 
>  Please reply to the
> list;
>please *don't*
> CC
> me.
> 
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
> 
> New to Asterisk? Start here:
> https://wiki.asterisk.org/wiki/display/AST/Getting+Started
> 
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>  http://lists.digium.com/mailman/listinfo/asterisk-users
 
 --
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com --
 
 Check out the new Asterisk community forum at:
 https://community.asterisk.org/
 
 New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started
 
 asterisk-users mailing list
 To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users
>>> 
>>> --
>>> _
>>> 

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Sorry did convert, not did converted :)

2021-09-08 22:43 GMT+02:00, Marek Greško :
> Hello,
>
> I did converted from iptables by automatical script and then rewritten
> myself, because not everything was rewritten successfully.
>
> Relevant parts:
>
> table ip filter {
>   ct helper sip {
> type "sip" protocol udp
> l3proto ip
>   }
>
>   chain PREROUTING {
> type filter hook prerouting priority filter; policy accept;
> udp port 5060 ct helper set "sip"
>   }
>
>   chain INPUT {
> ...
> ct state invalid drop
> ct state related accept
> ct state established accept
> ...
> iifname "ppp0" jump i-inet
>   }
>
>   chain OUTPUT {
> type filter hook output priority filter; policy accept;
> udp port 5060 ct helper set "sip"
> ...
>   }
>
>   chain i-inet {
> ...
> udp port 5060 jump r-sip
> ...
>   }
>
>   chain r-sip {
> ip saddr 192.0.2.0/24 accept
>   }
> }
>
> table ip mangle {
>   chain PREROUTING {
> type filter hook prerouting priority mangle; policy accept;
> ...
> udp sport 5060 ip dscp set 0x04
>   }
>
>   chain OUTPUT {
> type route hook output priority mangle; policy accept;
> ...
> udp dport 5060 ip dscp set 0x04
> ...
>   }
> }
>
> table ip6 filter {
>   ct helper sip {
> type "sip" protocol udp
> l3proto ip6
>   }
>
>   ... pretty the same, but I have no ipv6 internet connectivity, so
> this should not match ...
>
> }
>
>
> Is there something incorrect?
>
> Thanks
>
> Marek
>
>
>
> 2021-09-08 21:17 GMT+02:00, Duncan Turnbull :
>>
>>
>>> On 9/09/2021, at 6:23 AM, Marek Greško  wrote:
>>>
>>> Hello,
>>>
>>> I confirm temporarily allowing all the udp communication from the nat
>>> ip address solved the problem, so the problem lies in the nftables.
>>> This is probably not the right forum to continue. Or is it? Does
>>> anybody have wide experience with nftables and sip?
>> If you publish your rule set then we could look. Did you write the rules?
>> What have you checked so far?
>>
>>>
>>> Thanks
>>>
>>> Marek
>>>
>>>
>>> 2021-09-07 10:40 GMT+02:00, Antony Stone
>>> :
 On Monday 06 September 2021 at 23:05:27, Duncan Turnbull wrote:

>>> On 7/09/2021, at 8:30 AM, Marek Greško  wrote:
>>>
>>> Hello,
>>>
>>> it is only local nftables with nf_conntrack_sip on the asterisk
>>> server. Probably a kernel bug? It did not trigger with previous
>>> providers since they had working SIP ALG. Now I hear no audio in
>>> both
>>> directions because outgoing rtp stream from asterisk goes to private
>>> address space and incoming stream is blocked. So the outgoing rtp
>>> could not be learnt to send to nat addess.
>
> Maybe a bug but that’s less likely than a config error. Time to debug
> your
> nftables.

 Try temporarily simply turning the firewall off - allow all traffic
 through
 (although leave in place any NAT rules).

 If you then find that RTP works, you know where the problem lies.


 Antony.

 --
 Perfection in design is achieved not when there is nothing left to add,
 but
 rather when there is nothing left to take away.

 - Antoine de Saint-Exupery

   Please reply to the
 list;
 please *don't*
 CC
 me.

 --
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com --

 Check out the new Asterisk community forum at:
 https://community.asterisk.org/

 New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

 asterisk-users mailing list
 To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users
>>>
>>> --
>>> _
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> Check out the new Asterisk community forum at:
>>> https://community.asterisk.org/
>>>
>>> New to Asterisk? Start here:
>>>  https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>>>
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> Check out the new Asterisk community forum at:
>> https://community.asterisk.org/
>>
>> New to Asterisk? Start here:
>>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>http://lists.digium.com/mailman/listinfo/asterisk-users
>

-- 
_
-- 

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Hello,

I did converted from iptables by automatical script and then rewritten
myself, because not everything was rewritten successfully.

Relevant parts:

table ip filter {
  ct helper sip {
type "sip" protocol udp
l3proto ip
  }

  chain PREROUTING {
type filter hook prerouting priority filter; policy accept;
udp port 5060 ct helper set "sip"
  }

  chain INPUT {
...
ct state invalid drop
ct state related accept
ct state established accept
...
iifname "ppp0" jump i-inet
  }

  chain OUTPUT {
type filter hook output priority filter; policy accept;
udp port 5060 ct helper set "sip"
...
  }

  chain i-inet {
...
udp port 5060 jump r-sip
...
  }

  chain r-sip {
ip saddr 192.0.2.0/24 accept
  }
}

table ip mangle {
  chain PREROUTING {
type filter hook prerouting priority mangle; policy accept;
...
udp sport 5060 ip dscp set 0x04
  }

  chain OUTPUT {
type route hook output priority mangle; policy accept;
...
udp dport 5060 ip dscp set 0x04
...
  }
}

table ip6 filter {
  ct helper sip {
type "sip" protocol udp
l3proto ip6
  }

  ... pretty the same, but I have no ipv6 internet connectivity, so
this should not match ...

}


Is there something incorrect?

Thanks

Marek



2021-09-08 21:17 GMT+02:00, Duncan Turnbull :
>
>
>> On 9/09/2021, at 6:23 AM, Marek Greško  wrote:
>>
>> Hello,
>>
>> I confirm temporarily allowing all the udp communication from the nat
>> ip address solved the problem, so the problem lies in the nftables.
>> This is probably not the right forum to continue. Or is it? Does
>> anybody have wide experience with nftables and sip?
> If you publish your rule set then we could look. Did you write the rules?
> What have you checked so far?
>
>>
>> Thanks
>>
>> Marek
>>
>>
>> 2021-09-07 10:40 GMT+02:00, Antony Stone
>> :
>>> On Monday 06 September 2021 at 23:05:27, Duncan Turnbull wrote:
>>>
>> On 7/09/2021, at 8:30 AM, Marek Greško  wrote:
>>
>> Hello,
>>
>> it is only local nftables with nf_conntrack_sip on the asterisk
>> server. Probably a kernel bug? It did not trigger with previous
>> providers since they had working SIP ALG. Now I hear no audio in both
>> directions because outgoing rtp stream from asterisk goes to private
>> address space and incoming stream is blocked. So the outgoing rtp
>> could not be learnt to send to nat addess.

 Maybe a bug but that’s less likely than a config error. Time to debug
 your
 nftables.
>>>
>>> Try temporarily simply turning the firewall off - allow all traffic
>>> through
>>> (although leave in place any NAT rules).
>>>
>>> If you then find that RTP works, you know where the problem lies.
>>>
>>>
>>> Antony.
>>>
>>> --
>>> Perfection in design is achieved not when there is nothing left to add,
>>> but
>>> rather when there is nothing left to take away.
>>>
>>> - Antoine de Saint-Exupery
>>>
>>>   Please reply to the
>>> list;
>>> please *don't* CC
>>> me.
>>>
>>> --
>>> _
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> Check out the new Asterisk community forum at:
>>> https://community.asterisk.org/
>>>
>>> New to Asterisk? Start here:
>>>  https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>>>
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> Check out the new Asterisk community forum at:
>> https://community.asterisk.org/
>>
>> New to Asterisk? Start here:
>>  https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   

Re: [asterisk-users] problems with natted phones

[Duncan Turnbull]

> On 9/09/2021, at 6:23 AM, Marek Greško  wrote:
> 
> Hello,
> 
> I confirm temporarily allowing all the udp communication from the nat
> ip address solved the problem, so the problem lies in the nftables.
> This is probably not the right forum to continue. Or is it? Does
> anybody have wide experience with nftables and sip?
If you publish your rule set then we could look. Did you write the rules? What 
have you checked so far? 

> 
> Thanks
> 
> Marek
> 
> 
> 2021-09-07 10:40 GMT+02:00, Antony Stone 
> :
>> On Monday 06 September 2021 at 23:05:27, Duncan Turnbull wrote:
>> 
> On 7/09/2021, at 8:30 AM, Marek Greško  wrote:
> 
> Hello,
> 
> it is only local nftables with nf_conntrack_sip on the asterisk
> server. Probably a kernel bug? It did not trigger with previous
> providers since they had working SIP ALG. Now I hear no audio in both
> directions because outgoing rtp stream from asterisk goes to private
> address space and incoming stream is blocked. So the outgoing rtp
> could not be learnt to send to nat addess.
>>> 
>>> Maybe a bug but that’s less likely than a config error. Time to debug your
>>> nftables.
>> 
>> Try temporarily simply turning the firewall off - allow all traffic through
>> (although leave in place any NAT rules).
>> 
>> If you then find that RTP works, you know where the problem lies.
>> 
>> 
>> Antony.
>> 
>> --
>> Perfection in design is achieved not when there is nothing left to add, but
>> rather when there is nothing left to take away.
>> 
>> - Antoine de Saint-Exupery
>> 
>>   Please reply to the list;
>> please *don't* CC
>> me.
>> 
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> 
>> Check out the new Asterisk community forum at:
>> https://community.asterisk.org/
>> 
>> New to Asterisk? Start here:
>>  https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>> 
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
> 
> -- 
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> Check out the new Asterisk community forum at: https://community.asterisk.org/
> 
> New to Asterisk? Start here:
>  https://wiki.asterisk.org/wiki/display/AST/Getting+Started
> 
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Hello,

I confirm temporarily allowing all the udp communication from the nat
ip address solved the problem, so the problem lies in the nftables.
This is probably not the right forum to continue. Or is it? Does
anybody have wide experience with nftables and sip?

Thanks

Marek


2021-09-07 10:40 GMT+02:00, Antony Stone :
> On Monday 06 September 2021 at 23:05:27, Duncan Turnbull wrote:
>
>> > On 7/09/2021, at 8:30 AM, Marek Greško  wrote:
>> >
>> > Hello,
>> >
>> > it is only local nftables with nf_conntrack_sip on the asterisk
>> > server. Probably a kernel bug? It did not trigger with previous
>> > providers since they had working SIP ALG. Now I hear no audio in both
>> > directions because outgoing rtp stream from asterisk goes to private
>> > address space and incoming stream is blocked. So the outgoing rtp
>> > could not be learnt to send to nat addess.
>>
>> Maybe a bug but that’s less likely than a config error. Time to debug your
>> nftables.
>
> Try temporarily simply turning the firewall off - allow all traffic through
> (although leave in place any NAT rules).
>
> If you then find that RTP works, you know where the problem lies.
>
>
> Antony.
>
> --
> Perfection in design is achieved not when there is nothing left to add, but
> rather when there is nothing left to take away.
>
>  - Antoine de Saint-Exupery
>
>Please reply to the list;
>  please *don't* CC
> me.
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Antony Stone]

On Monday 06 September 2021 at 23:05:27, Duncan Turnbull wrote:

> > On 7/09/2021, at 8:30 AM, Marek Greško  wrote:
> > 
> > Hello,
> > 
> > it is only local nftables with nf_conntrack_sip on the asterisk
> > server. Probably a kernel bug? It did not trigger with previous
> > providers since they had working SIP ALG. Now I hear no audio in both
> > directions because outgoing rtp stream from asterisk goes to private
> > address space and incoming stream is blocked. So the outgoing rtp
> > could not be learnt to send to nat addess.
> 
> Maybe a bug but that’s less likely than a config error. Time to debug your
> nftables.

Try temporarily simply turning the firewall off - allow all traffic through 
(although leave in place any NAT rules).

If you then find that RTP works, you know where the problem lies.


Antony.

-- 
Perfection in design is achieved not when there is nothing left to add, but 
rather when there is nothing left to take away.

 - Antoine de Saint-Exupery

   Please reply to the list;
 please *don't* CC me.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Duncan Turnbull]

> On 7/09/2021, at 8:30 AM, Marek Greško  wrote:
> 
> Hello,
> 
> it is only local nftables with nf_conntrack_sip on the asterisk
> server. Probably a kernel bug? It did not trigger with previous
> providers since they had working SIP ALG. Now I hear no audio in both
> directions because outgoing rtp stream from asterisk goes to private
> address space and incoming stream is blocked. So the outgoing rtp
> could not be learnt to send to nat addess.
> 
Maybe a bug but that’s less likely than a config error. Time to debug your 
nftables.

> Marek
> 
> 
> 2021-09-06 22:17 GMT+02:00, Duncan Turnbull :
>> 
>> 
 On 7/09/2021, at 3:08 AM, Marek Greško  wrote:
>>> 
>>> Hello,
>>> 
>>> so when debugging RTP in asterisk there was no rtp income from the
>>> remote site. I did check remote nat ip address and it was same as the
>>> one in the pjsip show aors. So it is not due to ip address change. It
>>> seems the local firewall sip module does not allow rtp stream to get
>>> into. It was working previously with the other provider because of
>>> working SIP ALG on their gateways. But now with this provider and
>>> disabled SIP ALG it is not allowed. As I remeber in the past these
>>> setups did work. What are your experiences on this?
>>> 
>> You would need to provide a lot more explanation here. What is your
>> firewall? I am assuming you configure it so find the configuration that’s
>> blocking the ports and change it.
>> 
>> My experience as before was that something is blocking rtp, now you know
>> what that something is and it’s under your control so you need to check it’s
>> configuration and fix it. I don’t use a sip firewall. If I have external sip
>> clients I use a proxy.
>> 
>>> Thanks
>>> 
>>> Marek
>>> 
>>> 
>>> 2021-09-06 11:50 GMT+02:00, Marek Greško :
 Sorry rtp set debug on showed something. So let try for the problem to
 arise again.
 
 Marek
 
 
 2021-09-06 11:48 GMT+02:00, Marek Greško :
> Hello,
> 
>>> I would expect that when asterisk is aware of nat, it does not send
>>> the rtp until it receives rtp from other side to learn the port, but
>>> OK, no problem to accept the behavior.
>>> 
>> That’s not how things work. You should google how sip rtp and Nat work
>> as
>> it
>> will help you
> 
> no problem if it is intended.
> 
>>> 
 The question is why your asterisk didn't learn the external address
 and
 port from the received rtp packet
 
 You can look at your logs with debug to see what decisions its
 making.
 You
 can see if different rtp ports have different results.
 Your phone provider has rtp on 5010 unsuccessfully and 5016
 successfully.
 Your asterisk uses rtp 13786 successfully and fails when using 18892.
 Is
 it
 possible your firewall is blocking port 18892 and so asterisk never
 sees
 the returned packet and can't learn from it?
>>> 
>>> It is very unprobable. I see no reason for blocking the port. The
>>> problem is asterisk never learns the correct port, so there is nothing
>>> to block.
>> It wasn’t what is probable, look at the asterisk logs and see what it’s
>> actually doing. If asterisk never sees the reply then you will know
>> something is blocking or stealing the port for some other service
> 
> If it is stolen port for rtp, the next call would solve it, since it
> will use different one, and it does not solve it.
> 
>>> 
 
 In any event you should put your debug on and look at your logs in
 asterisk
 to see what it sees and why it doesn't react to the rtp packet, if it
 gets
 it
>>> 
>>> Could you point me how the debug should be conducted?
>> 
>> Using the asterisk cli turn on debug for the peer and rtp and see what
>> happens. Match it with the asterisk processes. You have to do this, you
>> can
>> look at cli or the log files, follow it through to see the rtp packet
>> being
>> received. Lots of debug advice on google.
> 
> Asterisk cli did not show anything interesting. I tried pjsip set
> logger verbose on, but no logs showed anywhere. What am I doing wrong?
> 
> Marek
> 
> 
>>> 
>>> Is my suspection that the problem could be caused by nat ip addres
>>> changing reasonable? How should asterisk handle the situation?
>> I can’t see anything to support that. Everything is looking normal
>> except
>> asterisk doesn’t appear to beseeing the rtp packet
>>> 
>>> Thanks
>>> 
>>> Marek
>>> 
>>> 
 
 Have fun, its all good learning.
 
 
> On Sun, Sep 5, 2021 at 6:27 PM Marek Greško 
> wrote:
> 
> Hello,
> 
> regarding the ipv6, you see nothing about that it should be some
> 

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Hello,

it is only local nftables with nf_conntrack_sip on the asterisk
server. Probably a kernel bug? It did not trigger with previous
providers since they had working SIP ALG. Now I hear no audio in both
directions because outgoing rtp stream from asterisk goes to private
address space and incoming stream is blocked. So the outgoing rtp
could not be learnt to send to nat addess.

Marek


2021-09-06 22:17 GMT+02:00, Duncan Turnbull :
>
>
>> On 7/09/2021, at 3:08 AM, Marek Greško  wrote:
>>
>> Hello,
>>
>> so when debugging RTP in asterisk there was no rtp income from the
>> remote site. I did check remote nat ip address and it was same as the
>> one in the pjsip show aors. So it is not due to ip address change. It
>> seems the local firewall sip module does not allow rtp stream to get
>> into. It was working previously with the other provider because of
>> working SIP ALG on their gateways. But now with this provider and
>> disabled SIP ALG it is not allowed. As I remeber in the past these
>> setups did work. What are your experiences on this?
>>
> You would need to provide a lot more explanation here. What is your
> firewall? I am assuming you configure it so find the configuration that’s
> blocking the ports and change it.
>
> My experience as before was that something is blocking rtp, now you know
> what that something is and it’s under your control so you need to check it’s
> configuration and fix it. I don’t use a sip firewall. If I have external sip
> clients I use a proxy.
>
>> Thanks
>>
>> Marek
>>
>>
>> 2021-09-06 11:50 GMT+02:00, Marek Greško :
>>> Sorry rtp set debug on showed something. So let try for the problem to
>>> arise again.
>>>
>>> Marek
>>>
>>>
>>> 2021-09-06 11:48 GMT+02:00, Marek Greško :
 Hello,

>> I would expect that when asterisk is aware of nat, it does not send
>> the rtp until it receives rtp from other side to learn the port, but
>> OK, no problem to accept the behavior.
>>
> That’s not how things work. You should google how sip rtp and Nat work
> as
> it
> will help you

 no problem if it is intended.

>>
>>> The question is why your asterisk didn't learn the external address
>>> and
>>> port from the received rtp packet
>>>
>>> You can look at your logs with debug to see what decisions its
>>> making.
>>> You
>>> can see if different rtp ports have different results.
>>> Your phone provider has rtp on 5010 unsuccessfully and 5016
>>> successfully.
>>> Your asterisk uses rtp 13786 successfully and fails when using 18892.
>>> Is
>>> it
>>> possible your firewall is blocking port 18892 and so asterisk never
>>> sees
>>> the returned packet and can't learn from it?
>>
>> It is very unprobable. I see no reason for blocking the port. The
>> problem is asterisk never learns the correct port, so there is nothing
>> to block.
> It wasn’t what is probable, look at the asterisk logs and see what it’s
> actually doing. If asterisk never sees the reply then you will know
> something is blocking or stealing the port for some other service

 If it is stolen port for rtp, the next call would solve it, since it
 will use different one, and it does not solve it.

>>
>>>
>>> In any event you should put your debug on and look at your logs in
>>> asterisk
>>> to see what it sees and why it doesn't react to the rtp packet, if it
>>> gets
>>> it
>>
>> Could you point me how the debug should be conducted?
>
> Using the asterisk cli turn on debug for the peer and rtp and see what
> happens. Match it with the asterisk processes. You have to do this, you
> can
> look at cli or the log files, follow it through to see the rtp packet
> being
> received. Lots of debug advice on google.

 Asterisk cli did not show anything interesting. I tried pjsip set
 logger verbose on, but no logs showed anywhere. What am I doing wrong?

 Marek


>>
>> Is my suspection that the problem could be caused by nat ip addres
>> changing reasonable? How should asterisk handle the situation?
> I can’t see anything to support that. Everything is looking normal
> except
> asterisk doesn’t appear to beseeing the rtp packet
>>
>> Thanks
>>
>> Marek
>>
>>
>>>
>>> Have fun, its all good learning.
>>>
>>>
 On Sun, Sep 5, 2021 at 6:27 PM Marek Greško 
 wrote:

 Hello,

 regarding the ipv6, you see nothing about that it should be some
 type
 of ipv6 tunnelling, because also MTU is lower than expected. You
 should not see any ipv6 related communication in the sniff. Phone is
 not aware of it.

 The asterisk's static public ip address is 198.51.100.1.
 The remote provider's dynamic nat pool is 192.0.2.0/24. By 

Re: [asterisk-users] problems with natted phones

[Duncan Turnbull]

> On 7/09/2021, at 3:08 AM, Marek Greško  wrote:
> 
> Hello,
> 
> so when debugging RTP in asterisk there was no rtp income from the
> remote site. I did check remote nat ip address and it was same as the
> one in the pjsip show aors. So it is not due to ip address change. It
> seems the local firewall sip module does not allow rtp stream to get
> into. It was working previously with the other provider because of
> working SIP ALG on their gateways. But now with this provider and
> disabled SIP ALG it is not allowed. As I remeber in the past these
> setups did work. What are your experiences on this?
> 
You would need to provide a lot more explanation here. What is your firewall? I 
am assuming you configure it so find the configuration that’s blocking the 
ports and change it. 

My experience as before was that something is blocking rtp, now you know what 
that something is and it’s under your control so you need to check it’s 
configuration and fix it. I don’t use a sip firewall. If I have external sip 
clients I use a proxy.

> Thanks
> 
> Marek
> 
> 
> 2021-09-06 11:50 GMT+02:00, Marek Greško :
>> Sorry rtp set debug on showed something. So let try for the problem to
>> arise again.
>> 
>> Marek
>> 
>> 
>> 2021-09-06 11:48 GMT+02:00, Marek Greško :
>>> Hello,
>>> 
> I would expect that when asterisk is aware of nat, it does not send
> the rtp until it receives rtp from other side to learn the port, but
> OK, no problem to accept the behavior.
> 
 That’s not how things work. You should google how sip rtp and Nat work
 as
 it
 will help you
>>> 
>>> no problem if it is intended.
>>> 
> 
>> The question is why your asterisk didn't learn the external address
>> and
>> port from the received rtp packet
>> 
>> You can look at your logs with debug to see what decisions its making.
>> You
>> can see if different rtp ports have different results.
>> Your phone provider has rtp on 5010 unsuccessfully and 5016
>> successfully.
>> Your asterisk uses rtp 13786 successfully and fails when using 18892.
>> Is
>> it
>> possible your firewall is blocking port 18892 and so asterisk never
>> sees
>> the returned packet and can't learn from it?
> 
> It is very unprobable. I see no reason for blocking the port. The
> problem is asterisk never learns the correct port, so there is nothing
> to block.
 It wasn’t what is probable, look at the asterisk logs and see what it’s
 actually doing. If asterisk never sees the reply then you will know
 something is blocking or stealing the port for some other service
>>> 
>>> If it is stolen port for rtp, the next call would solve it, since it
>>> will use different one, and it does not solve it.
>>> 
> 
>> 
>> In any event you should put your debug on and look at your logs in
>> asterisk
>> to see what it sees and why it doesn't react to the rtp packet, if it
>> gets
>> it
> 
> Could you point me how the debug should be conducted?
 
 Using the asterisk cli turn on debug for the peer and rtp and see what
 happens. Match it with the asterisk processes. You have to do this, you
 can
 look at cli or the log files, follow it through to see the rtp packet
 being
 received. Lots of debug advice on google.
>>> 
>>> Asterisk cli did not show anything interesting. I tried pjsip set
>>> logger verbose on, but no logs showed anywhere. What am I doing wrong?
>>> 
>>> Marek
>>> 
>>> 
> 
> Is my suspection that the problem could be caused by nat ip addres
> changing reasonable? How should asterisk handle the situation?
 I can’t see anything to support that. Everything is looking normal
 except
 asterisk doesn’t appear to beseeing the rtp packet
> 
> Thanks
> 
> Marek
> 
> 
>> 
>> Have fun, its all good learning.
>> 
>> 
>>> On Sun, Sep 5, 2021 at 6:27 PM Marek Greško 
>>> wrote:
>>> 
>>> Hello,
>>> 
>>> regarding the ipv6, you see nothing about that it should be some type
>>> of ipv6 tunnelling, because also MTU is lower than expected. You
>>> should not see any ipv6 related communication in the sniff. Phone is
>>> not aware of it.
>>> 
>>> The asterisk's static public ip address is 198.51.100.1.
>>> The remote provider's dynamic nat pool is 192.0.2.0/24. By provider
>>> we
>>> mean internet provider the remote phones are behind. We are not
>>> complaining about voip provider, we have no problem with that. Only
>>> communication between asterisk and remote phones behind some internet
>>> provider. This is the only conversation to look at.
>>> The phone private address is 192.168.100.235.
>>> 
>>> Thanks
>>> 
>>> Marek
>>> 
>>> 
>>> 2021-09-05 1:11 GMT+02:00, Duncan Turnbull :
 
 
> On 5/09/2021, at 10:21 AM, Marek Greško  wrote:

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Hello,

so when debugging RTP in asterisk there was no rtp income from the
remote site. I did check remote nat ip address and it was same as the
one in the pjsip show aors. So it is not due to ip address change. It
seems the local firewall sip module does not allow rtp stream to get
into. It was working previously with the other provider because of
working SIP ALG on their gateways. But now with this provider and
disabled SIP ALG it is not allowed. As I remeber in the past these
setups did work. What are your experiences on this?

Thanks

Marek


2021-09-06 11:50 GMT+02:00, Marek Greško :
> Sorry rtp set debug on showed something. So let try for the problem to
> arise again.
>
> Marek
>
>
> 2021-09-06 11:48 GMT+02:00, Marek Greško :
>> Hello,
>>
 I would expect that when asterisk is aware of nat, it does not send
 the rtp until it receives rtp from other side to learn the port, but
 OK, no problem to accept the behavior.

>>> That’s not how things work. You should google how sip rtp and Nat work
>>> as
>>> it
>>> will help you
>>
>> no problem if it is intended.
>>

> The question is why your asterisk didn't learn the external address
> and
> port from the received rtp packet
>
> You can look at your logs with debug to see what decisions its making.
> You
> can see if different rtp ports have different results.
> Your phone provider has rtp on 5010 unsuccessfully and 5016
> successfully.
> Your asterisk uses rtp 13786 successfully and fails when using 18892.
> Is
> it
> possible your firewall is blocking port 18892 and so asterisk never
> sees
> the returned packet and can't learn from it?

 It is very unprobable. I see no reason for blocking the port. The
 problem is asterisk never learns the correct port, so there is nothing
 to block.
>>> It wasn’t what is probable, look at the asterisk logs and see what it’s
>>> actually doing. If asterisk never sees the reply then you will know
>>> something is blocking or stealing the port for some other service
>>
>> If it is stolen port for rtp, the next call would solve it, since it
>> will use different one, and it does not solve it.
>>

>
> In any event you should put your debug on and look at your logs in
> asterisk
> to see what it sees and why it doesn't react to the rtp packet, if it
> gets
> it

 Could you point me how the debug should be conducted?
>>>
>>> Using the asterisk cli turn on debug for the peer and rtp and see what
>>> happens. Match it with the asterisk processes. You have to do this, you
>>> can
>>> look at cli or the log files, follow it through to see the rtp packet
>>> being
>>> received. Lots of debug advice on google.
>>
>> Asterisk cli did not show anything interesting. I tried pjsip set
>> logger verbose on, but no logs showed anywhere. What am I doing wrong?
>>
>> Marek
>>
>>

 Is my suspection that the problem could be caused by nat ip addres
 changing reasonable? How should asterisk handle the situation?
>>> I can’t see anything to support that. Everything is looking normal
>>> except
>>> asterisk doesn’t appear to beseeing the rtp packet

 Thanks

 Marek


>
> Have fun, its all good learning.
>
>
>> On Sun, Sep 5, 2021 at 6:27 PM Marek Greško 
>> wrote:
>>
>> Hello,
>>
>> regarding the ipv6, you see nothing about that it should be some type
>> of ipv6 tunnelling, because also MTU is lower than expected. You
>> should not see any ipv6 related communication in the sniff. Phone is
>> not aware of it.
>>
>> The asterisk's static public ip address is 198.51.100.1.
>> The remote provider's dynamic nat pool is 192.0.2.0/24. By provider
>> we
>> mean internet provider the remote phones are behind. We are not
>> complaining about voip provider, we have no problem with that. Only
>> communication between asterisk and remote phones behind some internet
>> provider. This is the only conversation to look at.
>> The phone private address is 192.168.100.235.
>>
>> Thanks
>>
>> Marek
>>
>>
>> 2021-09-05 1:11 GMT+02:00, Duncan Turnbull :
>>>
>>>
 On 5/09/2021, at 10:21 AM, Marek Greško  wrote:

 Hello,

 could you please answer my previous question about anonymizing
 several
 parameters? I have the data ready, but will post after answer. I
 have
 no clue whether I could disclose some important data not deleting
 them.

 Regarding sdp, the address will be the internal one, since the
 phone
 is behind nat and it is not aware of the nat. The provider's nat
 device is configured as dump nat, no application tweaking is done.
 So
 the asterisk will see the lan address in the sip.

>>> There are two conversations to look 

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Sorry rtp set debug on showed something. So let try for the problem to
arise again.

Marek


2021-09-06 11:48 GMT+02:00, Marek Greško :
> Hello,
>
>>> I would expect that when asterisk is aware of nat, it does not send
>>> the rtp until it receives rtp from other side to learn the port, but
>>> OK, no problem to accept the behavior.
>>>
>> That’s not how things work. You should google how sip rtp and Nat work as
>> it
>> will help you
>
> no problem if it is intended.
>
>>>
 The question is why your asterisk didn't learn the external address and
 port from the received rtp packet

 You can look at your logs with debug to see what decisions its making.
 You
 can see if different rtp ports have different results.
 Your phone provider has rtp on 5010 unsuccessfully and 5016
 successfully.
 Your asterisk uses rtp 13786 successfully and fails when using 18892.
 Is
 it
 possible your firewall is blocking port 18892 and so asterisk never
 sees
 the returned packet and can't learn from it?
>>>
>>> It is very unprobable. I see no reason for blocking the port. The
>>> problem is asterisk never learns the correct port, so there is nothing
>>> to block.
>> It wasn’t what is probable, look at the asterisk logs and see what it’s
>> actually doing. If asterisk never sees the reply then you will know
>> something is blocking or stealing the port for some other service
>
> If it is stolen port for rtp, the next call would solve it, since it
> will use different one, and it does not solve it.
>
>>>

 In any event you should put your debug on and look at your logs in
 asterisk
 to see what it sees and why it doesn't react to the rtp packet, if it
 gets
 it
>>>
>>> Could you point me how the debug should be conducted?
>>
>> Using the asterisk cli turn on debug for the peer and rtp and see what
>> happens. Match it with the asterisk processes. You have to do this, you
>> can
>> look at cli or the log files, follow it through to see the rtp packet
>> being
>> received. Lots of debug advice on google.
>
> Asterisk cli did not show anything interesting. I tried pjsip set
> logger verbose on, but no logs showed anywhere. What am I doing wrong?
>
> Marek
>
>
>>>
>>> Is my suspection that the problem could be caused by nat ip addres
>>> changing reasonable? How should asterisk handle the situation?
>> I can’t see anything to support that. Everything is looking normal except
>> asterisk doesn’t appear to beseeing the rtp packet
>>>
>>> Thanks
>>>
>>> Marek
>>>
>>>

 Have fun, its all good learning.


> On Sun, Sep 5, 2021 at 6:27 PM Marek Greško 
> wrote:
>
> Hello,
>
> regarding the ipv6, you see nothing about that it should be some type
> of ipv6 tunnelling, because also MTU is lower than expected. You
> should not see any ipv6 related communication in the sniff. Phone is
> not aware of it.
>
> The asterisk's static public ip address is 198.51.100.1.
> The remote provider's dynamic nat pool is 192.0.2.0/24. By provider we
> mean internet provider the remote phones are behind. We are not
> complaining about voip provider, we have no problem with that. Only
> communication between asterisk and remote phones behind some internet
> provider. This is the only conversation to look at.
> The phone private address is 192.168.100.235.
>
> Thanks
>
> Marek
>
>
> 2021-09-05 1:11 GMT+02:00, Duncan Turnbull :
>>
>>
>>> On 5/09/2021, at 10:21 AM, Marek Greško  wrote:
>>>
>>> Hello,
>>>
>>> could you please answer my previous question about anonymizing
>>> several
>>> parameters? I have the data ready, but will post after answer. I
>>> have
>>> no clue whether I could disclose some important data not deleting
>>> them.
>>>
>>> Regarding sdp, the address will be the internal one, since the phone
>>> is behind nat and it is not aware of the nat. The provider's nat
>>> device is configured as dump nat, no application tweaking is done.
>>> So
>>> the asterisk will see the lan address in the sip.
>>>
>> There are two conversations to look at
>> Provider to Asterisk
>> Asterisk to Phone
>> You need the packet captures of both.
>>
>> Your statements are mixing them up
>>
>> I don’t know what you mean by LAN address, that’s an ambiguous term.
>> The
> ip
>> your asterisk receives from the provider should be the providers
> external ip
>> or in the sdp the external address of the media server which may or
>> may
> not
>> be the same device
>>
>>> In the working scenario it is sending rtp packets to the internal
>>> address which is wrong, but after receiving cca 5 rtp packets from
>>> the
>>> phone it somehow discovers correct nat ip/port and switches to it.
>>> In
>>> non-working scenario it never 

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Hello,

>> I would expect that when asterisk is aware of nat, it does not send
>> the rtp until it receives rtp from other side to learn the port, but
>> OK, no problem to accept the behavior.
>>
> That’s not how things work. You should google how sip rtp and Nat work as it
> will help you

no problem if it is intended.

>>
>>> The question is why your asterisk didn't learn the external address and
>>> port from the received rtp packet
>>>
>>> You can look at your logs with debug to see what decisions its making.
>>> You
>>> can see if different rtp ports have different results.
>>> Your phone provider has rtp on 5010 unsuccessfully and 5016 successfully.
>>> Your asterisk uses rtp 13786 successfully and fails when using 18892. Is
>>> it
>>> possible your firewall is blocking port 18892 and so asterisk never sees
>>> the returned packet and can't learn from it?
>>
>> It is very unprobable. I see no reason for blocking the port. The
>> problem is asterisk never learns the correct port, so there is nothing
>> to block.
> It wasn’t what is probable, look at the asterisk logs and see what it’s
> actually doing. If asterisk never sees the reply then you will know
> something is blocking or stealing the port for some other service

If it is stolen port for rtp, the next call would solve it, since it
will use different one, and it does not solve it.

>>
>>>
>>> In any event you should put your debug on and look at your logs in
>>> asterisk
>>> to see what it sees and why it doesn't react to the rtp packet, if it
>>> gets
>>> it
>>
>> Could you point me how the debug should be conducted?
>
> Using the asterisk cli turn on debug for the peer and rtp and see what
> happens. Match it with the asterisk processes. You have to do this, you can
> look at cli or the log files, follow it through to see the rtp packet being
> received. Lots of debug advice on google.

Asterisk cli did not show anything interesting. I tried pjsip set
logger verbose on, but no logs showed anywhere. What am I doing wrong?

Marek


>>
>> Is my suspection that the problem could be caused by nat ip addres
>> changing reasonable? How should asterisk handle the situation?
> I can’t see anything to support that. Everything is looking normal except
> asterisk doesn’t appear to beseeing the rtp packet
>>
>> Thanks
>>
>> Marek
>>
>>
>>>
>>> Have fun, its all good learning.
>>>
>>>
 On Sun, Sep 5, 2021 at 6:27 PM Marek Greško  wrote:

 Hello,

 regarding the ipv6, you see nothing about that it should be some type
 of ipv6 tunnelling, because also MTU is lower than expected. You
 should not see any ipv6 related communication in the sniff. Phone is
 not aware of it.

 The asterisk's static public ip address is 198.51.100.1.
 The remote provider's dynamic nat pool is 192.0.2.0/24. By provider we
 mean internet provider the remote phones are behind. We are not
 complaining about voip provider, we have no problem with that. Only
 communication between asterisk and remote phones behind some internet
 provider. This is the only conversation to look at.
 The phone private address is 192.168.100.235.

 Thanks

 Marek


 2021-09-05 1:11 GMT+02:00, Duncan Turnbull :
>
>
>> On 5/09/2021, at 10:21 AM, Marek Greško  wrote:
>>
>> Hello,
>>
>> could you please answer my previous question about anonymizing several
>> parameters? I have the data ready, but will post after answer. I have
>> no clue whether I could disclose some important data not deleting
>> them.
>>
>> Regarding sdp, the address will be the internal one, since the phone
>> is behind nat and it is not aware of the nat. The provider's nat
>> device is configured as dump nat, no application tweaking is done. So
>> the asterisk will see the lan address in the sip.
>>
> There are two conversations to look at
> Provider to Asterisk
> Asterisk to Phone
> You need the packet captures of both.
>
> Your statements are mixing them up
>
> I don’t know what you mean by LAN address, that’s an ambiguous term.
> The
 ip
> your asterisk receives from the provider should be the providers
 external ip
> or in the sdp the external address of the media server which may or may
 not
> be the same device
>
>> In the working scenario it is sending rtp packets to the internal
>> address which is wrong, but after receiving cca 5 rtp packets from the
>> phone it somehow discovers correct nat ip/port and switches to it. In
>> non-working scenario it never switches and still sends to the lan
>> address. Strange there is no audio, even one direction. Another
>> strange thing is there are 2 phones (different vendors) behind the
>> same nat and the problem appearance on them is independent, sometimes
>> the first has problem, sometimes the second and sometimes both.
>>
>> The 

Re: [asterisk-users] problems with natted phones

[Duncan Turnbull]

> On 6/09/2021, at 7:10 PM, Marek Greško  wrote:
> 
> Hello,
> 
> 
> 
> 2021-09-06 2:51 GMT+02:00, Duncan Turnbull :
>> Hi Marek
>> 
>> I didn't understand your setup originally.
>> 
>> Can you confirm this is correct:
>> 
>> You provide asterisk for a number of remote phones. I assume they register
>> to the asterisk
>> 
>> Asterisk ( 198.51.100.1)  <==> Phone Provider ( 192.0.2.0/24 ) <==> Phone (
>> 192.168.100.235 )
>> 
>> Your call that fail is coming from asterisk to the phone offering G711A,
>> G729, iLBC, GSM, G723 and rtp on port 18892
> 
> Exactly correct.
> 
>> 
>> Its unclear to me still whether the remote provider has a SIP device in
>> front of the phones or just a firewall. The user agent for the reply is
> 
> It is just a firewall. I disabled SIP ALG on it. The nat is performed
> probably somewhere in the provider's network. I see only ipv6 tunnel
> to the provider's netwrork.
> 
>> A540 which I am not familiar with
> 
> The second phone is Cisco SPA502G. Same problems.
> 
>> 
>> The call that works shows the Asterisk sending to the internal ip until it
>> receives rtp from the remote phone from which it learns its address and
>> port and redirects the rtp to. This is fairly standard
> 
> I would expect that when asterisk is aware of nat, it does not send
> the rtp until it receives rtp from other side to learn the port, but
> OK, no problem to accept the behavior.
> 
That’s not how things work. You should google how sip rtp and Nat work as it 
will help you
> 
>> 
>> For the case of the call that doesn't work, your asterisk receives the rtp
>> with the external address but doesn't learn from it.
> 
> Yes exactly, but I do not undestand why. And why the reboot of the
> provider's router helps to solve the problem for several days?
> 
Focus on problem, once you know what’s happening to rtp you will get the other 
answers
>> 
>> You haven't provided the full call data  including the close down of the
>> call and the registrations would have been helpful too but no matter.
>> 
>> The question is why your asterisk didn't learn the external address and
>> port from the received rtp packet
>> 
>> You can look at your logs with debug to see what decisions its making. You
>> can see if different rtp ports have different results.
>> Your phone provider has rtp on 5010 unsuccessfully and 5016 successfully.
>> Your asterisk uses rtp 13786 successfully and fails when using 18892. Is it
>> possible your firewall is blocking port 18892 and so asterisk never sees
>> the returned packet and can't learn from it?
> 
> It is very unprobable. I see no reason for blocking the port. The
> problem is asterisk never learns the correct port, so there is nothing
> to block.
It wasn’t what is probable, look at the asterisk logs and see what it’s 
actually doing. If asterisk never sees the reply then you will know something 
is blocking or stealing the port for some other service
> 
>> 
>> In any event you should put your debug on and look at your logs in asterisk
>> to see what it sees and why it doesn't react to the rtp packet, if it gets
>> it
> 
> Could you point me how the debug should be conducted?

Using the asterisk cli turn on debug for the peer and rtp and see what happens. 
Match it with the asterisk processes. You have to do this, you can look at cli 
or the log files, follow it through to see the rtp packet being received. Lots 
of debug advice on google. 
> 
> Is my suspection that the problem could be caused by nat ip addres
> changing reasonable? How should asterisk handle the situation?
I can’t see anything to support that. Everything is looking normal except 
asterisk doesn’t appear to beseeing the rtp packet
> 
> Thanks
> 
> Marek
> 
> 
>> 
>> Have fun, its all good learning.
>> 
>> 
>>> On Sun, Sep 5, 2021 at 6:27 PM Marek Greško  wrote:
>>> 
>>> Hello,
>>> 
>>> regarding the ipv6, you see nothing about that it should be some type
>>> of ipv6 tunnelling, because also MTU is lower than expected. You
>>> should not see any ipv6 related communication in the sniff. Phone is
>>> not aware of it.
>>> 
>>> The asterisk's static public ip address is 198.51.100.1.
>>> The remote provider's dynamic nat pool is 192.0.2.0/24. By provider we
>>> mean internet provider the remote phones are behind. We are not
>>> complaining about voip provider, we have no problem with that. Only
>>> communication between asterisk and remote phones behind some internet
>>> provider. This is the only conversation to look at.
>>> The phone private address is 192.168.100.235.
>>> 
>>> Thanks
>>> 
>>> Marek
>>> 
>>> 
>>> 2021-09-05 1:11 GMT+02:00, Duncan Turnbull :
 
 
> On 5/09/2021, at 10:21 AM, Marek Greško  wrote:
> 
> Hello,
> 
> could you please answer my previous question about anonymizing several
> parameters? I have the data ready, but will post after answer. I have
> no clue whether I could disclose some important data not deleting
> them.
> 
> Regarding sdp, the address 

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Hello,



2021-09-06 2:51 GMT+02:00, Duncan Turnbull :
> Hi Marek
>
> I didn't understand your setup originally.
>
> Can you confirm this is correct:
>
> You provide asterisk for a number of remote phones. I assume they register
> to the asterisk
>
> Asterisk ( 198.51.100.1)  <==> Phone Provider ( 192.0.2.0/24 ) <==> Phone (
> 192.168.100.235 )
>
> Your call that fail is coming from asterisk to the phone offering G711A,
> G729, iLBC, GSM, G723 and rtp on port 18892

Exactly correct.

>
> Its unclear to me still whether the remote provider has a SIP device in
> front of the phones or just a firewall. The user agent for the reply is

It is just a firewall. I disabled SIP ALG on it. The nat is performed
probably somewhere in the provider's network. I see only ipv6 tunnel
to the provider's netwrork.

> A540 which I am not familiar with

The second phone is Cisco SPA502G. Same problems.

>
> The call that works shows the Asterisk sending to the internal ip until it
> receives rtp from the remote phone from which it learns its address and
> port and redirects the rtp to. This is fairly standard

I would expect that when asterisk is aware of nat, it does not send
the rtp until it receives rtp from other side to learn the port, but
OK, no problem to accept the behavior.


>
> For the case of the call that doesn't work, your asterisk receives the rtp
> with the external address but doesn't learn from it.

Yes exactly, but I do not undestand why. And why the reboot of the
provider's router helps to solve the problem for several days?

>
> You haven't provided the full call data  including the close down of the
> call and the registrations would have been helpful too but no matter.
>
> The question is why your asterisk didn't learn the external address and
> port from the received rtp packet
>
> You can look at your logs with debug to see what decisions its making. You
> can see if different rtp ports have different results.
> Your phone provider has rtp on 5010 unsuccessfully and 5016 successfully.
> Your asterisk uses rtp 13786 successfully and fails when using 18892. Is it
> possible your firewall is blocking port 18892 and so asterisk never sees
> the returned packet and can't learn from it?

It is very unprobable. I see no reason for blocking the port. The
problem is asterisk never learns the correct port, so there is nothing
to block.

>
> In any event you should put your debug on and look at your logs in asterisk
> to see what it sees and why it doesn't react to the rtp packet, if it gets
> it

Could you point me how the debug should be conducted?

Is my suspection that the problem could be caused by nat ip addres
changing reasonable? How should asterisk handle the situation?

Thanks

Marek


>
> Have fun, its all good learning.
>
>
> On Sun, Sep 5, 2021 at 6:27 PM Marek Greško  wrote:
>
>> Hello,
>>
>> regarding the ipv6, you see nothing about that it should be some type
>> of ipv6 tunnelling, because also MTU is lower than expected. You
>> should not see any ipv6 related communication in the sniff. Phone is
>> not aware of it.
>>
>> The asterisk's static public ip address is 198.51.100.1.
>> The remote provider's dynamic nat pool is 192.0.2.0/24. By provider we
>> mean internet provider the remote phones are behind. We are not
>> complaining about voip provider, we have no problem with that. Only
>> communication between asterisk and remote phones behind some internet
>> provider. This is the only conversation to look at.
>> The phone private address is 192.168.100.235.
>>
>> Thanks
>>
>> Marek
>>
>>
>> 2021-09-05 1:11 GMT+02:00, Duncan Turnbull :
>> >
>> >
>> >> On 5/09/2021, at 10:21 AM, Marek Greško  wrote:
>> >>
>> >> Hello,
>> >>
>> >> could you please answer my previous question about anonymizing several
>> >> parameters? I have the data ready, but will post after answer. I have
>> >> no clue whether I could disclose some important data not deleting
>> >> them.
>> >>
>> >> Regarding sdp, the address will be the internal one, since the phone
>> >> is behind nat and it is not aware of the nat. The provider's nat
>> >> device is configured as dump nat, no application tweaking is done. So
>> >> the asterisk will see the lan address in the sip.
>> >>
>> > There are two conversations to look at
>> > Provider to Asterisk
>> > Asterisk to Phone
>> > You need the packet captures of both.
>> >
>> > Your statements are mixing them up
>> >
>> > I don’t know what you mean by LAN address, that’s an ambiguous term.
>> > The
>> ip
>> > your asterisk receives from the provider should be the providers
>> external ip
>> > or in the sdp the external address of the media server which may or may
>> not
>> > be the same device
>> >
>> >> In the working scenario it is sending rtp packets to the internal
>> >> address which is wrong, but after receiving cca 5 rtp packets from the
>> >> phone it somehow discovers correct nat ip/port and switches to it. In
>> >> non-working scenario it never switches and still sends to the lan

Re: [asterisk-users] problems with natted phones

[Duncan Turnbull]

Hi Marek

I didn't understand your setup originally.

Can you confirm this is correct:

You provide asterisk for a number of remote phones. I assume they register
to the asterisk

Asterisk ( 198.51.100.1)  <==> Phone Provider ( 192.0.2.0/24 ) <==> Phone (
192.168.100.235 )

Your call that fail is coming from asterisk to the phone offering G711A,
G729, iLBC, GSM, G723 and rtp on port 18892

Its unclear to me still whether the remote provider has a SIP device in
front of the phones or just a firewall. The user agent for the reply is
A540 which I am not familiar with

The call that works shows the Asterisk sending to the internal ip until it
receives rtp from the remote phone from which it learns its address and
port and redirects the rtp to. This is fairly standard

For the case of the call that doesn't work, your asterisk receives the rtp
with the external address but doesn't learn from it.

You haven't provided the full call data  including the close down of the
call and the registrations would have been helpful too but no matter.

The question is why your asterisk didn't learn the external address and
port from the received rtp packet

You can look at your logs with debug to see what decisions its making. You
can see if different rtp ports have different results.
Your phone provider has rtp on 5010 unsuccessfully and 5016 successfully.
Your asterisk uses rtp 13786 successfully and fails when using 18892. Is it
possible your firewall is blocking port 18892 and so asterisk never sees
the returned packet and can't learn from it?

In any event you should put your debug on and look at your logs in asterisk
to see what it sees and why it doesn't react to the rtp packet, if it gets
it

Have fun, its all good learning.


On Sun, Sep 5, 2021 at 6:27 PM Marek Greško  wrote:

> Hello,
>
> regarding the ipv6, you see nothing about that it should be some type
> of ipv6 tunnelling, because also MTU is lower than expected. You
> should not see any ipv6 related communication in the sniff. Phone is
> not aware of it.
>
> The asterisk's static public ip address is 198.51.100.1.
> The remote provider's dynamic nat pool is 192.0.2.0/24. By provider we
> mean internet provider the remote phones are behind. We are not
> complaining about voip provider, we have no problem with that. Only
> communication between asterisk and remote phones behind some internet
> provider. This is the only conversation to look at.
> The phone private address is 192.168.100.235.
>
> Thanks
>
> Marek
>
>
> 2021-09-05 1:11 GMT+02:00, Duncan Turnbull :
> >
> >
> >> On 5/09/2021, at 10:21 AM, Marek Greško  wrote:
> >>
> >> Hello,
> >>
> >> could you please answer my previous question about anonymizing several
> >> parameters? I have the data ready, but will post after answer. I have
> >> no clue whether I could disclose some important data not deleting
> >> them.
> >>
> >> Regarding sdp, the address will be the internal one, since the phone
> >> is behind nat and it is not aware of the nat. The provider's nat
> >> device is configured as dump nat, no application tweaking is done. So
> >> the asterisk will see the lan address in the sip.
> >>
> > There are two conversations to look at
> > Provider to Asterisk
> > Asterisk to Phone
> > You need the packet captures of both.
> >
> > Your statements are mixing them up
> >
> > I don’t know what you mean by LAN address, that’s an ambiguous term. The
> ip
> > your asterisk receives from the provider should be the providers
> external ip
> > or in the sdp the external address of the media server which may or may
> not
> > be the same device
> >
> >> In the working scenario it is sending rtp packets to the internal
> >> address which is wrong, but after receiving cca 5 rtp packets from the
> >> phone it somehow discovers correct nat ip/port and switches to it. In
> >> non-working scenario it never switches and still sends to the lan
> >> address. Strange there is no audio, even one direction. Another
> >> strange thing is there are 2 phones (different vendors) behind the
> >> same nat and the problem appearance on them is independent, sometimes
> >> the first has problem, sometimes the second and sometimes both.
> >>
> >> The tcpdumps are made on the asterisk side. I have currently no means
> >> of capturing on phone side.
> >>
> >> Marek
> >>
> >> 2021-09-04 23:56 GMT+02:00, Antony Stone
> >> :
>  On Saturday 04 September 2021 at 22:13:32, Marek Greško wrote:
> 
>  Hello,
> 
>  I agree my knowledge of SIP itself is poor, but I have quite well
>  general tcp/ip understanding. What sip parameters should be
>  anonymized? How about tag, branch, call-id, cseq values?
> >>>
> >>> Show us your packet captures with meaningful addresses (not necessarily
> >>> accurate ones, but at least unambiguous - see my previous suggestion re
> >>> RFC5737) and we can help you to understand them and what they mean.
> >>>
> >>>
> >>> Antony.
> >>>
> >>> --
> >>> Heisenberg, Gödel, and Chomsky walk in to 

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Hello,

regarding the ipv6, you see nothing about that it should be some type
of ipv6 tunnelling, because also MTU is lower than expected. You
should not see any ipv6 related communication in the sniff. Phone is
not aware of it.

The asterisk's static public ip address is 198.51.100.1.
The remote provider's dynamic nat pool is 192.0.2.0/24. By provider we
mean internet provider the remote phones are behind. We are not
complaining about voip provider, we have no problem with that. Only
communication between asterisk and remote phones behind some internet
provider. This is the only conversation to look at.
The phone private address is 192.168.100.235.

Thanks

Marek


2021-09-05 1:11 GMT+02:00, Duncan Turnbull :
>
>
>> On 5/09/2021, at 10:21 AM, Marek Greško  wrote:
>>
>> Hello,
>>
>> could you please answer my previous question about anonymizing several
>> parameters? I have the data ready, but will post after answer. I have
>> no clue whether I could disclose some important data not deleting
>> them.
>>
>> Regarding sdp, the address will be the internal one, since the phone
>> is behind nat and it is not aware of the nat. The provider's nat
>> device is configured as dump nat, no application tweaking is done. So
>> the asterisk will see the lan address in the sip.
>>
> There are two conversations to look at
> Provider to Asterisk
> Asterisk to Phone
> You need the packet captures of both.
>
> Your statements are mixing them up
>
> I don’t know what you mean by LAN address, that’s an ambiguous term. The ip
> your asterisk receives from the provider should be the providers external ip
> or in the sdp the external address of the media server which may or may not
> be the same device
>
>> In the working scenario it is sending rtp packets to the internal
>> address which is wrong, but after receiving cca 5 rtp packets from the
>> phone it somehow discovers correct nat ip/port and switches to it. In
>> non-working scenario it never switches and still sends to the lan
>> address. Strange there is no audio, even one direction. Another
>> strange thing is there are 2 phones (different vendors) behind the
>> same nat and the problem appearance on them is independent, sometimes
>> the first has problem, sometimes the second and sometimes both.
>>
>> The tcpdumps are made on the asterisk side. I have currently no means
>> of capturing on phone side.
>>
>> Marek
>>
>> 2021-09-04 23:56 GMT+02:00, Antony Stone
>> :
 On Saturday 04 September 2021 at 22:13:32, Marek Greško wrote:

 Hello,

 I agree my knowledge of SIP itself is poor, but I have quite well
 general tcp/ip understanding. What sip parameters should be
 anonymized? How about tag, branch, call-id, cseq values?
>>>
>>> Show us your packet captures with meaningful addresses (not necessarily
>>> accurate ones, but at least unambiguous - see my previous suggestion re
>>> RFC5737) and we can help you to understand them and what they mean.
>>>
>>>
>>> Antony.
>>>
>>> --
>>> Heisenberg, Gödel, and Chomsky walk in to a bar.
>>> Heisenberg says, "Clearly this is a joke, but how can we work out if it's
>>> funny or not?"
>>> Gödel replies, "We can't know that because we're inside the joke."
>>> Chomsky says, "Of course it's funny. You're just saying it wrong."
>>>
>>>   Please reply to the
>>> list;
>>> please *don't* CC
>>> me.
>>>
>>> --
>>> _
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> Check out the new Asterisk community forum at:
>>> https://community.asterisk.org/
>>>
>>> New to Asterisk? Start here:
>>>  https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>>>
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> Check out the new Asterisk community forum at:
>> https://community.asterisk.org/
>>
>> New to Asterisk? Start here:
>>  https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users

-- 
_
-- Bandwidth 

Re: [asterisk-users] problems with natted phones

[Duncan Turnbull]

> On 5/09/2021, at 10:21 AM, Marek Greško  wrote:
> 
> Hello,
> 
> could you please answer my previous question about anonymizing several
> parameters? I have the data ready, but will post after answer. I have
> no clue whether I could disclose some important data not deleting
> them.
> 
> Regarding sdp, the address will be the internal one, since the phone
> is behind nat and it is not aware of the nat. The provider's nat
> device is configured as dump nat, no application tweaking is done. So
> the asterisk will see the lan address in the sip.
> 
There are two conversations to look at
Provider to Asterisk 
Asterisk to Phone
You need the packet captures of both.

Your statements are mixing them up

I don’t know what you mean by LAN address, that’s an ambiguous term. The ip 
your asterisk receives from the provider should be the providers external ip or 
in the sdp the external address of the media server which may or may not be the 
same device

> In the working scenario it is sending rtp packets to the internal
> address which is wrong, but after receiving cca 5 rtp packets from the
> phone it somehow discovers correct nat ip/port and switches to it. In
> non-working scenario it never switches and still sends to the lan
> address. Strange there is no audio, even one direction. Another
> strange thing is there are 2 phones (different vendors) behind the
> same nat and the problem appearance on them is independent, sometimes
> the first has problem, sometimes the second and sometimes both.
> 
> The tcpdumps are made on the asterisk side. I have currently no means
> of capturing on phone side.
> 
> Marek
> 
> 2021-09-04 23:56 GMT+02:00, Antony Stone 
> :
>>> On Saturday 04 September 2021 at 22:13:32, Marek Greško wrote:
>>> 
>>> Hello,
>>> 
>>> I agree my knowledge of SIP itself is poor, but I have quite well
>>> general tcp/ip understanding. What sip parameters should be
>>> anonymized? How about tag, branch, call-id, cseq values?
>> 
>> Show us your packet captures with meaningful addresses (not necessarily
>> accurate ones, but at least unambiguous - see my previous suggestion re
>> RFC5737) and we can help you to understand them and what they mean.
>> 
>> 
>> Antony.
>> 
>> --
>> Heisenberg, Gödel, and Chomsky walk in to a bar.
>> Heisenberg says, "Clearly this is a joke, but how can we work out if it's
>> funny or not?"
>> Gödel replies, "We can't know that because we're inside the joke."
>> Chomsky says, "Of course it's funny. You're just saying it wrong."
>> 
>>   Please reply to the list;
>> please *don't* CC
>> me.
>> 
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> 
>> Check out the new Asterisk community forum at:
>> https://community.asterisk.org/
>> 
>> New to Asterisk? Start here:
>>  https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>> 
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
> 
> -- 
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> Check out the new Asterisk community forum at: https://community.asterisk.org/
> 
> New to Asterisk? Start here:
>  https://wiki.asterisk.org/wiki/display/AST/Getting+Started
> 
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Antony Stone]

On Sunday 05 September 2021 at 00:54:10, Marek Greško wrote:

> the local provider's router does not possess any ipv4 address on the
> external interface, only ipv6.

So, what do the two addresses which you have labelled in the packet captures 
as 198.51.100.1 and 192.0.2.2 correspond to?

I see nothing at all in your packet captures which indicate IPv6.

Please tell us which address means what:

 - which is the public address of the Asterisk server?

 - which is the public address of the telephone?

(I'm assuming that the private address of the telephone is 192.168.100.235, 
please confirm).

We really do need to understand enough about your network arrangement to be 
able to help here.


Antony.

-- 
Your work is both good and original.  Unfortunately the parts that are good 
aren't original, and the parts that are original aren't good.

 - Samuel Johnson

   Please reply to the list;
 please *don't* CC me.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Hello,

I first tried to communicate to internet provider but without any
result. They told me I should find problem on my side. It does not
seem the provider is blocking SIP, since it is working for some time
and then stops. But I suspect the problem could be the NAT address
change. The provider offers only some IPv6 tunnel to his network and
the NAT is done probably on other property, I am not sure. But the
local provider's router does not possess any ipv4 address on the
external interface, only ipv6. I noticed the change now, when
anonymizing the tcpdumps. But the working scenario is after reboot, so
the ip address change is expected, but I cannot guarantee it does not
change in time. Maybe my previous expectation it is caused by asterisk
reboot was misleading. Could this be the cause? If yes, are there any
means how to overcome it on the asterisk side? I attached the
tcpdumps. Do you see something inconsistent in it?

By algorithms I meant when the router actively translates the sip
payload to change the lan addresses to the natted one.

Thanks

Marek

2021-09-05 0:40 GMT+02:00, Antony Stone :
> On Thursday 08 July 2021 at 20:57:30, Marek Greško wrote:
>
>> Hello,
>>
>> I have an asterisk setup using pjsip. Everything used to work
>> correctly until one remote site changed internet provider and thier
>> router does not support sip protocol algorithms.
>
> I'm slightly bothered by the word "algorithms" in that comment, but I do
> wonder whether it simply means that this is a connectivity provider
> (possibly
> a mobile phone network?) which actively blocks SIP.
>
> Some of them (in my experience) do this by blocking UDP port 5060, but
> others
> are more subtle about it, and (for example) block the authentication
> responses
> to a Register request, thereby meaning that UDP port 5060 is in general
> accessible, but any attempt to Register to it using SIP will fail.
>
> Have you asked the new Internet connectivity provider whether they support
> or
> block SIP across their network?
>
>
> Antony
>
> --
> "Remember: the S in IoT stands for Security."
>
>  - Jan-Piet Mens
>
>Please reply to the list;
>  please *don't* CC
> me.
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users
21:39:47.710512 IP 192.0.2.1.32260 > 198.51.100.1.5060: SIP


21:39:49.950775 IP 198.51.100.1.5060 > 192.0.2.1.32260: SIP: INVITE 
sip:999@192.0.2.1:32260 SIP/2.0
INVITE sip:999@192.0.2.1:32260 SIP/2.0
Via: SIP/2.0/UDP 
198.51.100.1:5060;rport;branch=z9hG4bKPjf0991750-2e98-4f19-9749-c4eee08a4e37
From: ;tag=e842dd73-cda0-45f5-81a7-a8fcc1472ac9
To: 
Contact: 
Call-ID: 603c61b6-5679-452a-aafa-0436f8d8b672
CSeq: 19604 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, 
UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 18.2.0
Content-Type: application/sdp
Content-Length:   376

v=0
o=- 121003081 121003081 IN IP4 198.51.100.1
s=Asterisk
c=IN IP4 198.51.100.1
t=0 0
m=audio 13786 RTP/AVP 8 18 97 3 4 101
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:3 GSM/8000
a=rtpmap:4 G723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

21:39:50.022921 IP 192.0.2.1.32260 > 198.51.100.1.5060: SIP: SIP/2.0 100 Trying
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 
198.51.100.1:5060;rport=5060;branch=z9hG4bKPjf0991750-2e98-4f19-9749-c4eee08a4e37
From: ;tag=e842dd73-cda0-45f5-81a7-a8fcc1472ac9
To: ;tag=1427222172
Call-ID: 603c61b6-5679-452a-aafa-0436f8d8b672
CSeq: 19604 INVITE
Contact: 
User-Agent: A540 IP/42.247.00.000.000
Content-Length: 0


21:39:50.559818 IP 192.0.2.1.32260 > 198.51.100.1.5060: SIP


21:39:50.563295 IP 192.0.2.1.32260 > 198.51.100.1.5060: SIP


21:39:50.568182 IP 192.0.2.1.32260 > 198.51.100.1.5060: SIP: SIP/2.0 180 Ringing
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 
198.51.100.1:5060;rport=5060;branch=z9hG4bKPjf0991750-2e98-4f19-9749-c4eee08a4e37
From: ;tag=e842dd73-cda0-45f5-81a7-a8fcc1472ac9
To: ;tag=1427222172
Call-ID: 603c61b6-5679-452a-aafa-0436f8d8b672
CSeq: 19604 INVITE
Contact: 
Allow-Events: message-summary, refer, ua-profile, talk, check-sync
User-Agent: A540 IP/42.247.00.000.000
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE
Content-Length: 0


21:39:52.496169 IP 192.0.2.1.32260 > 198.51.100.1.5060: SIP


21:39:52.499501 IP 192.0.2.1.32260 

Re: [asterisk-users] problems with natted phones

[Antony Stone]

On Thursday 08 July 2021 at 20:57:30, Marek Greško wrote:

> Hello,
> 
> I have an asterisk setup using pjsip. Everything used to work
> correctly until one remote site changed internet provider and thier
> router does not support sip protocol algorithms.

I'm slightly bothered by the word "algorithms" in that comment, but I do 
wonder whether it simply means that this is a connectivity provider (possibly 
a mobile phone network?) which actively blocks SIP.

Some of them (in my experience) do this by blocking UDP port 5060, but others 
are more subtle about it, and (for example) block the authentication responses 
to a Register request, thereby meaning that UDP port 5060 is in general 
accessible, but any attempt to Register to it using SIP will fail.

Have you asked the new Internet connectivity provider whether they support or 
block SIP across their network?


Antony

-- 
"Remember: the S in IoT stands for Security."

 - Jan-Piet Mens

   Please reply to the list;
 please *don't* CC me.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Antony Stone]

On Sunday 05 September 2021 at 00:19:41, Marek Greško wrote:

> Hello,
> 
> could you please answer my previous question about anonymizing several
> parameters? I have the data ready, but will post after answer. I have
> no clue whether I could disclose some important data not deleting
> them.

Nothing other than IP addresses (if you consider those to be sensitive) needs 
to be anonymised.

> The tcpdumps are made on the asterisk side. I have currently no means
> of capturing on phone side.

I suspect that is in fact ideal.


Antony.

-- 
I thought I had type A blood, but it turned out to be a typo.

   Please reply to the list;
 please *don't* CC me.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Hello,

could you please answer my previous question about anonymizing several
parameters? I have the data ready, but will post after answer. I have
no clue whether I could disclose some important data not deleting
them.

Regarding sdp, the address will be the internal one, since the phone
is behind nat and it is not aware of the nat. The provider's nat
device is configured as dump nat, no application tweaking is done. So
the asterisk will see the lan address in the sip.

In the working scenario it is sending rtp packets to the internal
address which is wrong, but after receiving cca 5 rtp packets from the
phone it somehow discovers correct nat ip/port and switches to it. In
non-working scenario it never switches and still sends to the lan
address. Strange there is no audio, even one direction. Another
strange thing is there are 2 phones (different vendors) behind the
same nat and the problem appearance on them is independent, sometimes
the first has problem, sometimes the second and sometimes both.

The tcpdumps are made on the asterisk side. I have currently no means
of capturing on phone side.

Marek

2021-09-04 23:56 GMT+02:00, Antony Stone :
> On Saturday 04 September 2021 at 22:13:32, Marek Greško wrote:
>
>> Hello,
>>
>> I agree my knowledge of SIP itself is poor, but I have quite well
>> general tcp/ip understanding. What sip parameters should be
>> anonymized? How about tag, branch, call-id, cseq values?
>
> Show us your packet captures with meaningful addresses (not necessarily
> accurate ones, but at least unambiguous - see my previous suggestion re
> RFC5737) and we can help you to understand them and what they mean.
>
>
> Antony.
>
> --
> Heisenberg, Gödel, and Chomsky walk in to a bar.
> Heisenberg says, "Clearly this is a joke, but how can we work out if it's
> funny or not?"
> Gödel replies, "We can't know that because we're inside the joke."
> Chomsky says, "Of course it's funny. You're just saying it wrong."
>
>Please reply to the list;
>  please *don't* CC
> me.
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Antony Stone]

On Saturday 04 September 2021 at 22:13:32, Marek Greško wrote:

> Hello,
> 
> I agree my knowledge of SIP itself is poor, but I have quite well
> general tcp/ip understanding. What sip parameters should be
> anonymized? How about tag, branch, call-id, cseq values?

Show us your packet captures with meaningful addresses (not necessarily 
accurate ones, but at least unambiguous - see my previous suggestion re 
RFC5737) and we can help you to understand them and what they mean.


Antony.

-- 
Heisenberg, Gödel, and Chomsky walk in to a bar.
Heisenberg says, "Clearly this is a joke, but how can we work out if it's 
funny or not?"
Gödel replies, "We can't know that because we're inside the joke."
Chomsky says, "Of course it's funny. You're just saying it wrong."

   Please reply to the list;
 please *don't* CC me.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Duncan Turnbull]

Hi Marek

The way it works is that the sip message will carry the sdp and in that will be 
the instructions for where to route the rtp

If systems don’t know their external address or are misconfigured they send an 
internal address that is not reachable from the far end. This is where lack of 
audio issues occur 

The main thing to show are the sip to/from addresses, anonymised but 
consistent, and the sdp data particularly the c and the media attributes

Here is some background 

https://support.yeastar.com/hc/en-us/articles/360009806434-Brief-Introduction-of-SIP-and-SDP-Protocol-?mobile_site=true

If the c attribute has an address that is not routeable from the device that 
received it then you won’t get any audio

It’s confusing at this stage but once you get a little more familiar it will 
start to make a lot of sense

> On 5/09/2021, at 8:16 AM, Marek Greško  wrote:
> 
> Hello,
> 
> I agree my knowledge of SIP itself is poor, but I have quite well
> general tcp/ip understanding. What sip parameters should be
> anonymized? How about tag, branch, call-id, cseq values?
> 
> Thanks
> 
> Marek
> 
> 
> 2021-09-04 12:36 GMT+02:00, Duncan Turnbull :
>> 
>> 
 On 4/09/2021, at 8:55 PM, Marek Greško  wrote:
>>> 
>>> Ok,
>>> 
>>> let substitute lan for 192.168.100.235, provider with 192.0.2.1 and
>>> asterisk with 198.51.100.1.
>> 
>> Can you provide the previous packet details with these addresses filled in
>>> 
>>> In the working scenario understand that asterisk is not aware of the
>>> providers ip address
>> If the call goes provider - asterisk - phone then asterisk is absolutely
>> aware of the provider ip. I think you need to get more familiar with sip and
>> rtp
>> 
>>> 192.0.2.1 in the sip protocol, and it should pick
>>> it from the network layer. It is harder to calcutale port, so it
>>> should probably listen for incoming rtp stream?
>> 
>> The sdp in the sip packet tells the rtp ip and port to connect to
>>> Until then it is just
>>> sending to private address? But I thing it is futile, since it is
>>> known from the sip protocol there is nat involved and thus the packets
>>> are destined to nowhere.
>> 
>> You need to realise that this works normally everyday all over the place so
>> what you are imagining is incorrect
>>> 
>>> But I still cannot imagine what goes wrong in non working scenario and
>>> how the asterisk reboot (not every one and not sure this is the real
>>> trigger). The sip communication seems identical to me. The provider's
>>> router does not touch SIP now as observed after disabling SIP ALG.
>> 
>> It is very unclear as to how you are justifying these statements. You don’t
>> yet understand how sip and call setup with media works. If you provide the
>> whole sip packet capture with the substituted ips it should be easier to
>> point out where the error is
>> 
>> You need to be really clear on what’s ip
>> is what and where the conversations are captured
>> 
>> It will become clear once you provide all the details
>> 
>> 
>>> 
>>> Thanks
>>> 
>>> Marek
>>> 
>>> 2021-09-04 0:40 GMT+02:00, Antony Stone
>>> :
 On Saturday 04 September 2021 at 00:34:49, Duncan Turnbull wrote:
 
>>> On 4/09/2021, at 7:53 AM, Marek Greško  wrote:
>>> 
>>> So you suspect something is messing up SIP protocol? Maybe the phone
>>> itself is not working properly. The phone itself is not aware of the
>>> internet address, so is sending lan private address in the sip
>>> protocol.
> 
> I doubt it’s the phone. You need to check your data again and ideally
> explain what you mean by the names you have substituted for the ip
> addresses
 
 My advice (regarding the IP addresses) is:
 
 - where you have https://tools.ietf.org/html/rfc1918 addresses, leave
 them
 as
 they are - you're not giving away any sensitive information by telling us
 about your internal addresses which can't be routed over the Internet
 
 - where you have public addresses and would prefer not to reveal what
 these
 are, substitute with https://tools.ietf.org/html/rfc5737 addresses
 instead.
 
 - always ensure that you substitute address A in the same way each time,
 and
 address B, etc.
 
 
 Antony.
 
 --
 You can spend the whole of your life trying to be popular,
 but at the end of the day the size of the crowd at your funeral
 will be largely dictated by the weather.
 
 - Frank Skinner
 
  Please reply to the
 list;
please *don't* CC
 me.
 
 --
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com --
 
 Check out the new Asterisk community forum at:
 https://community.asterisk.org/
 
 New to Asterisk? Start here:
 

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Hello,

I agree my knowledge of SIP itself is poor, but I have quite well
general tcp/ip understanding. What sip parameters should be
anonymized? How about tag, branch, call-id, cseq values?

Thanks

Marek


2021-09-04 12:36 GMT+02:00, Duncan Turnbull :
>
>
>> On 4/09/2021, at 8:55 PM, Marek Greško  wrote:
>>
>> Ok,
>>
>> let substitute lan for 192.168.100.235, provider with 192.0.2.1 and
>> asterisk with 198.51.100.1.
>
> Can you provide the previous packet details with these addresses filled in
>>
>> In the working scenario understand that asterisk is not aware of the
>> providers ip address
> If the call goes provider - asterisk - phone then asterisk is absolutely
> aware of the provider ip. I think you need to get more familiar with sip and
> rtp
>
>> 192.0.2.1 in the sip protocol, and it should pick
>> it from the network layer. It is harder to calcutale port, so it
>> should probably listen for incoming rtp stream?
>
> The sdp in the sip packet tells the rtp ip and port to connect to
>> Until then it is just
>> sending to private address? But I thing it is futile, since it is
>> known from the sip protocol there is nat involved and thus the packets
>> are destined to nowhere.
>
> You need to realise that this works normally everyday all over the place so
> what you are imagining is incorrect
>>
>> But I still cannot imagine what goes wrong in non working scenario and
>> how the asterisk reboot (not every one and not sure this is the real
>> trigger). The sip communication seems identical to me. The provider's
>> router does not touch SIP now as observed after disabling SIP ALG.
>
> It is very unclear as to how you are justifying these statements. You don’t
> yet understand how sip and call setup with media works. If you provide the
> whole sip packet capture with the substituted ips it should be easier to
> point out where the error is
>
> You need to be really clear on what’s ip
> is what and where the conversations are captured
>
> It will become clear once you provide all the details
>
>
>>
>> Thanks
>>
>> Marek
>>
>> 2021-09-04 0:40 GMT+02:00, Antony Stone
>> :
>>> On Saturday 04 September 2021 at 00:34:49, Duncan Turnbull wrote:
>>>
>> On 4/09/2021, at 7:53 AM, Marek Greško  wrote:
>>
>> So you suspect something is messing up SIP protocol? Maybe the phone
>> itself is not working properly. The phone itself is not aware of the
>> internet address, so is sending lan private address in the sip
>> protocol.

 I doubt it’s the phone. You need to check your data again and ideally
 explain what you mean by the names you have substituted for the ip
 addresses
>>>
>>> My advice (regarding the IP addresses) is:
>>>
>>> - where you have https://tools.ietf.org/html/rfc1918 addresses, leave
>>> them
>>> as
>>> they are - you're not giving away any sensitive information by telling us
>>> about your internal addresses which can't be routed over the Internet
>>>
>>> - where you have public addresses and would prefer not to reveal what
>>> these
>>> are, substitute with https://tools.ietf.org/html/rfc5737 addresses
>>> instead.
>>>
>>> - always ensure that you substitute address A in the same way each time,
>>> and
>>> address B, etc.
>>>
>>>
>>> Antony.
>>>
>>> --
>>> You can spend the whole of your life trying to be popular,
>>> but at the end of the day the size of the crowd at your funeral
>>> will be largely dictated by the weather.
>>>
>>> - Frank Skinner
>>>
>>>   Please reply to the
>>> list;
>>> please *don't* CC
>>> me.
>>>
>>> --
>>> _
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> Check out the new Asterisk community forum at:
>>> https://community.asterisk.org/
>>>
>>> New to Asterisk? Start here:
>>>  https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>>>
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> Check out the new Asterisk community forum at:
>> https://community.asterisk.org/
>>
>> New to Asterisk? Start here:
>>  https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE 

Re: [asterisk-users] problems with natted phones

[Duncan Turnbull]

> On 4/09/2021, at 8:55 PM, Marek Greško  wrote:
> 
> Ok,
> 
> let substitute lan for 192.168.100.235, provider with 192.0.2.1 and
> asterisk with 198.51.100.1.

Can you provide the previous packet details with these addresses filled in
> 
> In the working scenario understand that asterisk is not aware of the
> providers ip address
If the call goes provider - asterisk - phone then asterisk is absolutely aware 
of the provider ip. I think you need to get more familiar with sip and rtp 

> 192.0.2.1 in the sip protocol, and it should pick
> it from the network layer. It is harder to calcutale port, so it
> should probably listen for incoming rtp stream?

The sdp in the sip packet tells the rtp ip and port to connect to
> Until then it is just
> sending to private address? But I thing it is futile, since it is
> known from the sip protocol there is nat involved and thus the packets
> are destined to nowhere.

You need to realise that this works normally everyday all over the place so 
what you are imagining is incorrect
> 
> But I still cannot imagine what goes wrong in non working scenario and
> how the asterisk reboot (not every one and not sure this is the real
> trigger). The sip communication seems identical to me. The provider's
> router does not touch SIP now as observed after disabling SIP ALG.

It is very unclear as to how you are justifying these statements. You don’t yet 
understand how sip and call setup with media works. If you provide the whole 
sip packet capture with the substituted ips it should be easier to point out 
where the error is

You need to be really clear on what’s ip
is what and where the conversations are captured

It will become clear once you provide all the details


> 
> Thanks
> 
> Marek
> 
> 2021-09-04 0:40 GMT+02:00, Antony Stone 
> :
>> On Saturday 04 September 2021 at 00:34:49, Duncan Turnbull wrote:
>> 
> On 4/09/2021, at 7:53 AM, Marek Greško  wrote:
> 
> So you suspect something is messing up SIP protocol? Maybe the phone
> itself is not working properly. The phone itself is not aware of the
> internet address, so is sending lan private address in the sip
> protocol.
>>> 
>>> I doubt it’s the phone. You need to check your data again and ideally
>>> explain what you mean by the names you have substituted for the ip
>>> addresses
>> 
>> My advice (regarding the IP addresses) is:
>> 
>> - where you have https://tools.ietf.org/html/rfc1918 addresses, leave them
>> as
>> they are - you're not giving away any sensitive information by telling us
>> about your internal addresses which can't be routed over the Internet
>> 
>> - where you have public addresses and would prefer not to reveal what these
>> are, substitute with https://tools.ietf.org/html/rfc5737 addresses instead.
>> 
>> - always ensure that you substitute address A in the same way each time,
>> and
>> address B, etc.
>> 
>> 
>> Antony.
>> 
>> --
>> You can spend the whole of your life trying to be popular,
>> but at the end of the day the size of the crowd at your funeral
>> will be largely dictated by the weather.
>> 
>> - Frank Skinner
>> 
>>   Please reply to the list;
>> please *don't* CC
>> me.
>> 
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> 
>> Check out the new Asterisk community forum at:
>> https://community.asterisk.org/
>> 
>> New to Asterisk? Start here:
>>  https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>> 
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
> 
> -- 
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> Check out the new Asterisk community forum at: https://community.asterisk.org/
> 
> New to Asterisk? Start here:
>  https://wiki.asterisk.org/wiki/display/AST/Getting+Started
> 
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Ok,

let substitute lan for 192.168.100.235, provider with 192.0.2.1 and
asterisk with 198.51.100.1.

In the working scenario understand that asterisk is not aware of the
providers ip address 192.0.2.1 in the sip protocol, and it should pick
it from the network layer. It is harder to calcutale port, so it
should probably listen for incoming rtp stream? Until then it is just
sending to private address? But I thing it is futile, since it is
known from the sip protocol there is nat involved and thus the packets
are destined to nowhere.

But I still cannot imagine what goes wrong in non working scenario and
how the asterisk reboot (not every one and not sure this is the real
trigger). The sip communication seems identical to me. The provider's
router does not touch SIP now as observed after disabling SIP ALG.

Thanks

Marek

2021-09-04 0:40 GMT+02:00, Antony Stone :
> On Saturday 04 September 2021 at 00:34:49, Duncan Turnbull wrote:
>
>> > On 4/09/2021, at 7:53 AM, Marek Greško  wrote:
>> >
>> > So you suspect something is messing up SIP protocol? Maybe the phone
>> > itself is not working properly. The phone itself is not aware of the
>> > internet address, so is sending lan private address in the sip
>> > protocol.
>>
>> I doubt it’s the phone. You need to check your data again and ideally
>> explain what you mean by the names you have substituted for the ip
>> addresses
>
> My advice (regarding the IP addresses) is:
>
>  - where you have https://tools.ietf.org/html/rfc1918 addresses, leave them
> as
> they are - you're not giving away any sensitive information by telling us
> about your internal addresses which can't be routed over the Internet
>
>  - where you have public addresses and would prefer not to reveal what these
> are, substitute with https://tools.ietf.org/html/rfc5737 addresses instead.
>
>  - always ensure that you substitute address A in the same way each time,
> and
> address B, etc.
>
>
> Antony.
>
> --
> You can spend the whole of your life trying to be popular,
> but at the end of the day the size of the crowd at your funeral
> will be largely dictated by the weather.
>
>  - Frank Skinner
>
>Please reply to the list;
>  please *don't* CC
> me.
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Antony Stone]

On Saturday 04 September 2021 at 00:34:49, Duncan Turnbull wrote:

> > On 4/09/2021, at 7:53 AM, Marek Greško  wrote:
> > 
> > So you suspect something is messing up SIP protocol? Maybe the phone
> > itself is not working properly. The phone itself is not aware of the
> > internet address, so is sending lan private address in the sip
> > protocol.
> 
> I doubt it’s the phone. You need to check your data again and ideally
> explain what you mean by the names you have substituted for the ip
> addresses

My advice (regarding the IP addresses) is:

 - where you have https://tools.ietf.org/html/rfc1918 addresses, leave them as 
they are - you're not giving away any sensitive information by telling us 
about your internal addresses which can't be routed over the Internet

 - where you have public addresses and would prefer not to reveal what these 
are, substitute with https://tools.ietf.org/html/rfc5737 addresses instead.

 - always ensure that you substitute address A in the same way each time, and 
address B, etc.


Antony.

-- 
You can spend the whole of your life trying to be popular,
but at the end of the day the size of the crowd at your funeral
will be largely dictated by the weather.

 - Frank Skinner

   Please reply to the list;
 please *don't* CC me.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Duncan Turnbull]

> On 4/09/2021, at 7:53 AM, Marek Greško  wrote:
> 
> So you suspect something is messing up SIP protocol? Maybe the phone
> itself is not working properly. The phone itself is not aware of the
> internet address, so is sending lan private address in the sip
> protocol.

I doubt it’s the phone. You need to check your data again and ideally explain 
what you mean by the names you have substituted for the ip addresses

> I would expect asterisk itself is pairing the provider
> address with the lan address. I was asked to disable all the SIP ALG
> on the provider's router in the previous discussion. And it made a big
> improvement in the experience.
> 
> Marek
> 
> 2021-09-03 12:19 GMT+02:00, Duncan Turnbull :
>>> On Fri, Sep 3, 2021 at 8:47 PM Marek Greško  wrote:
>>> 
>>> Hello,
>>> 
>>> I looked into tcpdumps. When problem starts (after some asterisk
>>> reboot) the call looks like this:
>>> 
>>> provider:25298 -> asterisk:5060
>>> SIP: SIP/2.0 200 OK
>>> Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=...
>>> From: ;tag=...
>>> To: ;tag=...
>>> Call-ID: ...
>>> CSeq: ... INVITE
>>> Contact: 
>>> Supported: replaces
>>> Allow-Events: message-sumary, refer, ua-profile, talk, check-sync
>>> Allow: INVITE, ACK, CANCEL, BYE, OPTIONS. INFO, SUBSCRIBE, NOTIFY, REFER,
>>> UPDATE
>>> Content-Type: application/sdp
>>> Content-Length: ...
>>> 
>>> v=0
>>> o=... 5010 ... IN IP4 lan
>>> s=Mapping
>>> 
>> This bit here tells where the rtp has to go to. I don't think you want it
>> to be IP4 lan. It would be a lot more helpful if you had the ip address but
>> the use of the word LAN suggests its a private IP which asterisk is not
>> going to be able to route to
>> 
>> 
>>> c=IN IP4 lan
C = is telling the asterisk what ip to send rtp to. So if ip4 lan is a valid 
external address then that’s ok but if not your provider is sending you an IP 
address that asterisk doesn’t know how to connect to and therefore rtp will go 
nowhere leaving you with no sound

>>> t=0 0
>>> m=audio 5010 RTP/AVP 8 101
>>> a=rtpmap:8 PCMA/8000
>>> a=rtpmap:101 telephone-event/8000
>>> a=fmtp:101 0-16
>>> a=sendrcv
>>> a=ptime:20
>>> 
>>> asterisk:5060 -> provider:25298
>>> Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=...
>>> From: ;tag=...
>>> To: ;tag=...
>>> Call-ID: ...
>>> CSeq: ... ACK
>>> Max-Forwards: 70
>>> User-Agent: Asterisk PBX 18.2.0
>>> Content-Length: 0
>>> 
>>> Then I see RTP packets:
>>> asterisk:18892 -> lan:5010
>>> provider:25420 -> asterisk:18892
>>> 
>> As above for RTP to work they have to go to/from the end points. Asterisk
>> is sending to 18892 instead of the provider 25420
>> 
>> Why is your provider sending you an sdp with rtp with a private ip address?
>> Or are they sending the right address and your ALG or something else is
>> changing it? Ask your provider what they are sending you? Then find out
>> who/what is messing up the SDP
>> 
>> 
>>> 
>>> I hear no audio. I heard stream towards the asterisk prior to SIP ALG
>>> disabling. Now silence both directions. It should not be a codec
>>> problem. After providers router reboot I can hear both directions but
>>> it still seems weird:
>>> 
>>> provider:32260 -> asterisk:5060
>>> SIP: SIP/2.0 200 OK
>>> Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=...
>>> From: ;tag=...
>>> To: ;tag=...
>>> Call-ID: ...
>>> CSeq: ... INVITE
>>> Contact: 
>>> Supported: replaces
>>> Allow-Events: message-sumary, refer, ua-profile, talk, check-sync
>>> Allow: INVITE, ACK, CANCEL, BYE, OPTIONS. INFO, SUBSCRIBE, NOTIFY, REFER,
>>> UPDATE
>>> Content-Type: application/sdp
>>> Content-Length: ...
>>> 
>>> v=0
>>> o=... 5016 ... IN IP4 lan
>>> s=Mapping
>>> c=IN IP4 lan
>>> t=0 0
>>> m=audio 5016 RTP/AVP 8 101
>>> a=rtpmap:8 PCMA/8000
>>> a=rtpmap:101 telephone-event/8000
>>> a=fmtp:101 0-16
>>> a=sendrcv
>>> a=ptime:20
>>> 
>>> asterisk:5060 -> provider:32260
>>> Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=...
>>> From: ;tag=...
>>> To: ;tag=...
>>> Call-ID: ...
>>> CSeq: ... ACK
>>> Max-Forwards: 70
>>> User-Agent: Asterisk PBX 18.2.0
>>> Content-Length: 0
>>> 
>>> Then I see several RTP packets:
>>> asterisk:13786 -> lan:5016
>>> provider:32327 -> asterisk:13786
>>> for a while and the suddenly
>>> asterisk:13786 -> provider:32327
>>> provider:32327 -> asterisk:13786
>>> 
>>> The user experience for that scenario is OK.
>>> 
>>> I suspect some configuration error on asterisk side, since also for
>>> working scenario I see RTP packets to the lan. But I cannot figure out
>>> what it is. When I was using another provider which had working SIP
>>> ALG I had no problem even without nat configuration on the asterisk
>>> side.
>>> 
>>> The experience is clearly better after disabling SIP ALG, but we still
>>> face problems after asterisk side reboots.
>>> 
>>> Could you point me for what should I look in the asterisk
>>> configuration? And why the problems are gone after provider's router
>>> reboot?
>>> 
>>> Thanks
>>> 
>>> Marek
>>> 
>>> 
>>> 
>>> 2021-08-13 15:31 GMT+02:00, 

Re: [asterisk-users] problems with natted phones

[Marek Greško]

So you suspect something is messing up SIP protocol? Maybe the phone
itself is not working properly. The phone itself is not aware of the
internet address, so is sending lan private address in the sip
protocol. I would expect asterisk itself is pairing the provider
address with the lan address. I was asked to disable all the SIP ALG
on the provider's router in the previous discussion. And it made a big
improvement in the experience.

Marek

2021-09-03 12:19 GMT+02:00, Duncan Turnbull :
> On Fri, Sep 3, 2021 at 8:47 PM Marek Greško  wrote:
>
>> Hello,
>>
>> I looked into tcpdumps. When problem starts (after some asterisk
>> reboot) the call looks like this:
>>
>> provider:25298 -> asterisk:5060
>> SIP: SIP/2.0 200 OK
>> Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=...
>> From: ;tag=...
>> To: ;tag=...
>> Call-ID: ...
>> CSeq: ... INVITE
>> Contact: 
>> Supported: replaces
>> Allow-Events: message-sumary, refer, ua-profile, talk, check-sync
>> Allow: INVITE, ACK, CANCEL, BYE, OPTIONS. INFO, SUBSCRIBE, NOTIFY, REFER,
>> UPDATE
>> Content-Type: application/sdp
>> Content-Length: ...
>>
>> v=0
>> o=... 5010 ... IN IP4 lan
>> s=Mapping
>>
> This bit here tells where the rtp has to go to. I don't think you want it
> to be IP4 lan. It would be a lot more helpful if you had the ip address but
> the use of the word LAN suggests its a private IP which asterisk is not
> going to be able to route to
>
>
>> c=IN IP4 lan
>> t=0 0
>> m=audio 5010 RTP/AVP 8 101
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-16
>> a=sendrcv
>> a=ptime:20
>>
>> asterisk:5060 -> provider:25298
>> Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=...
>> From: ;tag=...
>> To: ;tag=...
>> Call-ID: ...
>> CSeq: ... ACK
>> Max-Forwards: 70
>> User-Agent: Asterisk PBX 18.2.0
>> Content-Length: 0
>>
>> Then I see RTP packets:
>> asterisk:18892 -> lan:5010
>> provider:25420 -> asterisk:18892
>>
> As above for RTP to work they have to go to/from the end points. Asterisk
> is sending to 18892 instead of the provider 25420
>
> Why is your provider sending you an sdp with rtp with a private ip address?
> Or are they sending the right address and your ALG or something else is
> changing it? Ask your provider what they are sending you? Then find out
> who/what is messing up the SDP
>
>
>>
>> I hear no audio. I heard stream towards the asterisk prior to SIP ALG
>> disabling. Now silence both directions. It should not be a codec
>> problem. After providers router reboot I can hear both directions but
>> it still seems weird:
>>
>> provider:32260 -> asterisk:5060
>> SIP: SIP/2.0 200 OK
>> Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=...
>> From: ;tag=...
>> To: ;tag=...
>> Call-ID: ...
>> CSeq: ... INVITE
>> Contact: 
>> Supported: replaces
>> Allow-Events: message-sumary, refer, ua-profile, talk, check-sync
>> Allow: INVITE, ACK, CANCEL, BYE, OPTIONS. INFO, SUBSCRIBE, NOTIFY, REFER,
>> UPDATE
>> Content-Type: application/sdp
>> Content-Length: ...
>>
>> v=0
>> o=... 5016 ... IN IP4 lan
>> s=Mapping
>> c=IN IP4 lan
>> t=0 0
>> m=audio 5016 RTP/AVP 8 101
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-16
>> a=sendrcv
>> a=ptime:20
>>
>> asterisk:5060 -> provider:32260
>> Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=...
>> From: ;tag=...
>> To: ;tag=...
>> Call-ID: ...
>> CSeq: ... ACK
>> Max-Forwards: 70
>> User-Agent: Asterisk PBX 18.2.0
>> Content-Length: 0
>>
>> Then I see several RTP packets:
>> asterisk:13786 -> lan:5016
>> provider:32327 -> asterisk:13786
>> for a while and the suddenly
>> asterisk:13786 -> provider:32327
>> provider:32327 -> asterisk:13786
>>
>> The user experience for that scenario is OK.
>>
>> I suspect some configuration error on asterisk side, since also for
>> working scenario I see RTP packets to the lan. But I cannot figure out
>> what it is. When I was using another provider which had working SIP
>> ALG I had no problem even without nat configuration on the asterisk
>> side.
>>
>> The experience is clearly better after disabling SIP ALG, but we still
>> face problems after asterisk side reboots.
>>
>> Could you point me for what should I look in the asterisk
>> configuration? And why the problems are gone after provider's router
>> reboot?
>>
>> Thanks
>>
>> Marek
>>
>>
>>
>> 2021-08-13 15:31 GMT+02:00, Duncan Turnbull :
>> >
>> >>Hello,
>> >>
>> >>it triggered again. Even disabling RTSp ALG did not help. My fantasy
>> >>ends here. It agains seems to be reboot triggered on asterisk side.
>> >>Not every one. But there was surely one before it was last working.
>> >>Reboot of the router on the phone side fixes the problem. Any other
>> >>suggestions?
>> >>
>> > This is where you use sngrep or tcpdump to look at whats actually
>> > happening on the asterisk box. sngrep is focussed on sip dialogs and is
>> > probably easier than tcpdump when you are just interested in sip
>> >
>> > If you use sngrep on the asterisk server sip port you will see the SIP
>> > packet 

Re: [asterisk-users] problems with natted phones

[Duncan Turnbull]

On Fri, Sep 3, 2021 at 8:47 PM Marek Greško  wrote:

> Hello,
>
> I looked into tcpdumps. When problem starts (after some asterisk
> reboot) the call looks like this:
>
> provider:25298 -> asterisk:5060
> SIP: SIP/2.0 200 OK
> Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=...
> From: ;tag=...
> To: ;tag=...
> Call-ID: ...
> CSeq: ... INVITE
> Contact: 
> Supported: replaces
> Allow-Events: message-sumary, refer, ua-profile, talk, check-sync
> Allow: INVITE, ACK, CANCEL, BYE, OPTIONS. INFO, SUBSCRIBE, NOTIFY, REFER,
> UPDATE
> Content-Type: application/sdp
> Content-Length: ...
>
> v=0
> o=... 5010 ... IN IP4 lan
> s=Mapping
>
This bit here tells where the rtp has to go to. I don't think you want it
to be IP4 lan. It would be a lot more helpful if you had the ip address but
the use of the word LAN suggests its a private IP which asterisk is not
going to be able to route to


> c=IN IP4 lan
> t=0 0
> m=audio 5010 RTP/AVP 8 101
> a=rtpmap:8 PCMA/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=sendrcv
> a=ptime:20
>
> asterisk:5060 -> provider:25298
> Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=...
> From: ;tag=...
> To: ;tag=...
> Call-ID: ...
> CSeq: ... ACK
> Max-Forwards: 70
> User-Agent: Asterisk PBX 18.2.0
> Content-Length: 0
>
> Then I see RTP packets:
> asterisk:18892 -> lan:5010
> provider:25420 -> asterisk:18892
>
As above for RTP to work they have to go to/from the end points. Asterisk
is sending to 18892 instead of the provider 25420

Why is your provider sending you an sdp with rtp with a private ip address?
Or are they sending the right address and your ALG or something else is
changing it? Ask your provider what they are sending you? Then find out
who/what is messing up the SDP


>
> I hear no audio. I heard stream towards the asterisk prior to SIP ALG
> disabling. Now silence both directions. It should not be a codec
> problem. After providers router reboot I can hear both directions but
> it still seems weird:
>
> provider:32260 -> asterisk:5060
> SIP: SIP/2.0 200 OK
> Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=...
> From: ;tag=...
> To: ;tag=...
> Call-ID: ...
> CSeq: ... INVITE
> Contact: 
> Supported: replaces
> Allow-Events: message-sumary, refer, ua-profile, talk, check-sync
> Allow: INVITE, ACK, CANCEL, BYE, OPTIONS. INFO, SUBSCRIBE, NOTIFY, REFER,
> UPDATE
> Content-Type: application/sdp
> Content-Length: ...
>
> v=0
> o=... 5016 ... IN IP4 lan
> s=Mapping
> c=IN IP4 lan
> t=0 0
> m=audio 5016 RTP/AVP 8 101
> a=rtpmap:8 PCMA/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=sendrcv
> a=ptime:20
>
> asterisk:5060 -> provider:32260
> Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=...
> From: ;tag=...
> To: ;tag=...
> Call-ID: ...
> CSeq: ... ACK
> Max-Forwards: 70
> User-Agent: Asterisk PBX 18.2.0
> Content-Length: 0
>
> Then I see several RTP packets:
> asterisk:13786 -> lan:5016
> provider:32327 -> asterisk:13786
> for a while and the suddenly
> asterisk:13786 -> provider:32327
> provider:32327 -> asterisk:13786
>
> The user experience for that scenario is OK.
>
> I suspect some configuration error on asterisk side, since also for
> working scenario I see RTP packets to the lan. But I cannot figure out
> what it is. When I was using another provider which had working SIP
> ALG I had no problem even without nat configuration on the asterisk
> side.
>
> The experience is clearly better after disabling SIP ALG, but we still
> face problems after asterisk side reboots.
>
> Could you point me for what should I look in the asterisk
> configuration? And why the problems are gone after provider's router
> reboot?
>
> Thanks
>
> Marek
>
>
>
> 2021-08-13 15:31 GMT+02:00, Duncan Turnbull :
> >
> >>Hello,
> >>
> >>it triggered again. Even disabling RTSp ALG did not help. My fantasy
> >>ends here. It agains seems to be reboot triggered on asterisk side.
> >>Not every one. But there was surely one before it was last working.
> >>Reboot of the router on the phone side fixes the problem. Any other
> >>suggestions?
> >>
> > This is where you use sngrep or tcpdump to look at whats actually
> > happening on the asterisk box. sngrep is focussed on sip dialogs and is
> > probably easier than tcpdump when you are just interested in sip
> >
> > If you use sngrep on the asterisk server sip port you will see the SIP
> > packet flows for registration and call setups. You can check the
> > addresses given out for rtp to respond to and the codecs. Is an address
> > incorrect? Is a code incorrect? You will see in the session description
> > protocol what codecs the client is requesting and what the replies are
> >
> > asterisk works well around the world with many nat scenarios so I
> > imagine its either config or firewall. A firewall with ALGs is often
> > problematic but your log suggests a lack of negotiation of agreed
> > codecs.
> >
> > Good luck, you will learn some interesting things.
> >
> >
> >
> >>
> >>Thanks
> >>
> >>Marek
> >>
> >>
> >>2021-07-26 9:31 

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Hello,

I looked into tcpdumps. When problem starts (after some asterisk
reboot) the call looks like this:

provider:25298 -> asterisk:5060
SIP: SIP/2.0 200 OK
Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=...
From: ;tag=...
To: ;tag=...
Call-ID: ...
CSeq: ... INVITE
Contact: 
Supported: replaces
Allow-Events: message-sumary, refer, ua-profile, talk, check-sync
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS. INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE
Content-Type: application/sdp
Content-Length: ...

v=0
o=... 5010 ... IN IP4 lan
s=Mapping
c=IN IP4 lan
t=0 0
m=audio 5010 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrcv
a=ptime:20

asterisk:5060 -> provider:25298
Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=...
From: ;tag=...
To: ;tag=...
Call-ID: ...
CSeq: ... ACK
Max-Forwards: 70
User-Agent: Asterisk PBX 18.2.0
Content-Length: 0

Then I see RTP packets:
asterisk:18892 -> lan:5010
provider:25420 -> asterisk:18892

I hear no audio. I heard stream towards the asterisk prior to SIP ALG
disabling. Now silence both directions. It should not be a codec
problem. After providers router reboot I can hear both directions but
it still seems weird:

provider:32260 -> asterisk:5060
SIP: SIP/2.0 200 OK
Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=...
From: ;tag=...
To: ;tag=...
Call-ID: ...
CSeq: ... INVITE
Contact: 
Supported: replaces
Allow-Events: message-sumary, refer, ua-profile, talk, check-sync
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS. INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE
Content-Type: application/sdp
Content-Length: ...

v=0
o=... 5016 ... IN IP4 lan
s=Mapping
c=IN IP4 lan
t=0 0
m=audio 5016 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrcv
a=ptime:20

asterisk:5060 -> provider:32260
Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=...
From: ;tag=...
To: ;tag=...
Call-ID: ...
CSeq: ... ACK
Max-Forwards: 70
User-Agent: Asterisk PBX 18.2.0
Content-Length: 0

Then I see several RTP packets:
asterisk:13786 -> lan:5016
provider:32327 -> asterisk:13786
for a while and the suddenly
asterisk:13786 -> provider:32327
provider:32327 -> asterisk:13786

The user experience for that scenario is OK.

I suspect some configuration error on asterisk side, since also for
working scenario I see RTP packets to the lan. But I cannot figure out
what it is. When I was using another provider which had working SIP
ALG I had no problem even without nat configuration on the asterisk
side.

The experience is clearly better after disabling SIP ALG, but we still
face problems after asterisk side reboots.

Could you point me for what should I look in the asterisk
configuration? And why the problems are gone after provider's router
reboot?

Thanks

Marek



2021-08-13 15:31 GMT+02:00, Duncan Turnbull :
>
>>Hello,
>>
>>it triggered again. Even disabling RTSp ALG did not help. My fantasy
>>ends here. It agains seems to be reboot triggered on asterisk side.
>>Not every one. But there was surely one before it was last working.
>>Reboot of the router on the phone side fixes the problem. Any other
>>suggestions?
>>
> This is where you use sngrep or tcpdump to look at whats actually
> happening on the asterisk box. sngrep is focussed on sip dialogs and is
> probably easier than tcpdump when you are just interested in sip
>
> If you use sngrep on the asterisk server sip port you will see the SIP
> packet flows for registration and call setups. You can check the
> addresses given out for rtp to respond to and the codecs. Is an address
> incorrect? Is a code incorrect? You will see in the session description
> protocol what codecs the client is requesting and what the replies are
>
> asterisk works well around the world with many nat scenarios so I
> imagine its either config or firewall. A firewall with ALGs is often
> problematic but your log suggests a lack of negotiation of agreed
> codecs.
>
> Good luck, you will learn some interesting things.
>
>
>
>>
>>Thanks
>>
>>Marek
>>
>>
>>2021-07-26 9:31 GMT+02:00, Marek Greško :
>>>  I currently disabled also RTSP ALG and rebooted the router. Fixed for
>>>  now. I do not know for how long.
>>>
>>>  Marek
>>>
>>>
>>>  2021-07-26 8:54 GMT+02:00, Marek Greško :
  Hmm, back to original problem. My happines was premature. Today one of
  the phones have no audio again. I see packets from lan segment again.

  I double checked the router configuration. SIP ALG is disabled. There
  are also another ALGs present:

  NAT ALG
  RTSP ALG
  PPTP ALG
  IPSEC ALG

  Which of them are neede to be disabled?

  As of my observations these problems are triggered by reboots on
  asterisk side. How could this be related? (I may be wrong.)

  Thanks

  Marek



  2021-07-23 14:54 GMT+02:00, Marek Greško :
>  I achieved a partial success adding --use-compact-form option.
>
>  Marek
>
>
>  2021-07-23 13:47 GMT+02:00, Marek 

Re: [asterisk-users] problems with natted phones

[Duncan Turnbull]

Hello,

it triggered again. Even disabling RTSp ALG did not help. My fantasy
ends here. It agains seems to be reboot triggered on asterisk side.
Not every one. But there was surely one before it was last working.
Reboot of the router on the phone side fixes the problem. Any other
suggestions?

This is where you use sngrep or tcpdump to look at whats actually 
happening on the asterisk box. sngrep is focussed on sip dialogs and is 
probably easier than tcpdump when you are just interested in sip


If you use sngrep on the asterisk server sip port you will see the SIP 
packet flows for registration and call setups. You can check the 
addresses given out for rtp to respond to and the codecs. Is an address 
incorrect? Is a code incorrect? You will see in the session description 
protocol what codecs the client is requesting and what the replies are


asterisk works well around the world with many nat scenarios so I 
imagine its either config or firewall. A firewall with ALGs is often 
problematic but your log suggests a lack of negotiation of agreed 
codecs.


Good luck, you will learn some interesting things.





Thanks

Marek


2021-07-26 9:31 GMT+02:00, Marek Greško :

 I currently disabled also RTSP ALG and rebooted the router. Fixed for
 now. I do not know for how long.

 Marek


 2021-07-26 8:54 GMT+02:00, Marek Greško :

 Hmm, back to original problem. My happines was premature. Today one of
 the phones have no audio again. I see packets from lan segment again.

 I double checked the router configuration. SIP ALG is disabled. There
 are also another ALGs present:

 NAT ALG
 RTSP ALG
 PPTP ALG
 IPSEC ALG

 Which of them are neede to be disabled?

 As of my observations these problems are triggered by reboots on
 asterisk side. How could this be related? (I may be wrong.)

 Thanks

 Marek



 2021-07-23 14:54 GMT+02:00, Marek Greško :

 I achieved a partial success adding --use-compact-form option.

 Marek


 2021-07-23 13:47 GMT+02:00, Marek Greško :

 Hello,

 your suggestion to turn off SIP ALG on provider's router was probably
 correct. no problem until now. Thank you very much.

 I just found out another issue. I had a pjsue client in that network
 which called specific number when turned on. It was working perfectly
 with the old provider with working SIP ALG. But now with this provider
 and SIP ALG disabled I am not able to make the call using pjsua
 client.

 My pjsua config looks like this:
 --id sip:ext@asterisk.domain
 --registrar sip:asterisk.domain
 --proxy sip:asterisk.domain
 --outbound sip:asterisk.domain
 --realm *
 --username username
 --password password
 --null-audio
 --no-tcp
 --max-calls=1
 --no-vad

 The pjsua client successfully registers but is unable to call.

 I see the following:
 IP address change detected for account 1
 (localip:5060-->nattedip:newport). Updating registration (using method
 4)
 Temporary failure in sending Request msg INVITE/cseq=, will try
 next server: Unsupported transport (PJSIP_EUNSUPTRANSPORT)

 What could be the problem? How can I convince pjsue to work correctly
 behind nat?

 Thanks

 Marek





 2021-07-10 11:08 GMT+02:00, Marek Greško :

 Hello,

 I just disabled. Currently it is working. I shloud give it some time
 to confirm the problem has gone. Maybe one month would be enough to
 confirm.

 Thanks

 Marek


 2021-07-09 20:11 GMT+02:00, Abdenasser Ghomri
 :

 Yes just disable the SIP ALG and see if it helps, Thanks.

 Best Regards,

 On Fri, Jul 9, 2021, 09:10 Antony Stone <
antony.st...@asterisk.open.source.it> wrote:


 On Friday 09 July 2021 at 08:47:46, Marek Greško wrote:

 > Hello,
 >
 > yes SIP ALG are anbled on the router. Should I disable?

 In my opinion, always.

 Antony.

 --
 I don't know, maybe if we all waited then cosmic rays would write
 all
 our
 software for us. Of course it might take a while.

  - Ron Minnich, Los Alamos National Laboratory

Please reply to
 the
 list;
  please
 *don't*
 CC
 me.

 --
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com
 --

 Check out the new Asterisk community forum at:
https://community.asterisk.org/

 New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started

 asterisk-users mailing list
 To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users














--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users



--

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Hello,

it triggered again. Even disabling RTSp ALG did not help. My fantasy
ends here. It agains seems to be reboot triggered on asterisk side.
Not every one. But there was surely one before it was last working.
Reboot of the router on the phone side fixes the problem. Any other
suggestions?

Thanks

Marek


2021-07-26 9:31 GMT+02:00, Marek Greško :
> I currently disabled also RTSP ALG and rebooted the router. Fixed for
> now. I do not know for how long.
>
> Marek
>
>
> 2021-07-26 8:54 GMT+02:00, Marek Greško :
>> Hmm, back to original problem. My happines was premature. Today one of
>> the phones have no audio again. I see packets from lan segment again.
>>
>> I double checked the router configuration. SIP ALG is disabled. There
>> are also another ALGs present:
>>
>> NAT ALG
>> RTSP ALG
>> PPTP ALG
>> IPSEC ALG
>>
>> Which of them are neede to be disabled?
>>
>> As of my observations these problems are triggered by reboots on
>> asterisk side. How could this be related? (I may be wrong.)
>>
>> Thanks
>>
>> Marek
>>
>>
>>
>> 2021-07-23 14:54 GMT+02:00, Marek Greško :
>>> I achieved a partial success adding --use-compact-form option.
>>>
>>> Marek
>>>
>>>
>>> 2021-07-23 13:47 GMT+02:00, Marek Greško :
 Hello,

 your suggestion to turn off SIP ALG on provider's router was probably
 correct. no problem until now. Thank you very much.

 I just found out another issue. I had a pjsue client in that network
 which called specific number when turned on. It was working perfectly
 with the old provider with working SIP ALG. But now with this provider
 and SIP ALG disabled I am not able to make the call using pjsua
 client.

 My pjsua config looks like this:
 --id sip:ext@asterisk.domain
 --registrar sip:asterisk.domain
 --proxy sip:asterisk.domain
 --outbound sip:asterisk.domain
 --realm *
 --username username
 --password password
 --null-audio
 --no-tcp
 --max-calls=1
 --no-vad

 The pjsua client successfully registers but is unable to call.

 I see the following:
 IP address change detected for account 1
 (localip:5060-->nattedip:newport). Updating registration (using method
 4)
 Temporary failure in sending Request msg INVITE/cseq=, will try
 next server: Unsupported transport (PJSIP_EUNSUPTRANSPORT)

 What could be the problem? How can I convince pjsue to work correctly
 behind nat?

 Thanks

 Marek





 2021-07-10 11:08 GMT+02:00, Marek Greško :
> Hello,
>
> I just disabled. Currently it is working. I shloud give it some time
> to confirm the problem has gone. Maybe one month would be enough to
> confirm.
>
> Thanks
>
> Marek
>
>
> 2021-07-09 20:11 GMT+02:00, Abdenasser Ghomri
> :
>> Yes just disable the SIP ALG and see if it helps, Thanks.
>>
>> Best Regards,
>>
>> On Fri, Jul 9, 2021, 09:10 Antony Stone <
>> antony.st...@asterisk.open.source.it> wrote:
>>
>>> On Friday 09 July 2021 at 08:47:46, Marek Greško wrote:
>>>
>>> > Hello,
>>> >
>>> > yes SIP ALG are anbled on the router. Should I disable?
>>>
>>> In my opinion, always.
>>>
>>> Antony.
>>>
>>> --
>>> I don't know, maybe if we all waited then cosmic rays would write
>>> all
>>> our
>>> software for us. Of course it might take a while.
>>>
>>>  - Ron Minnich, Los Alamos National Laboratory
>>>
>>>Please reply to
>>> the
>>> list;
>>>  please
>>> *don't*
>>> CC
>>> me.
>>>
>>> --
>>> _
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com
>>> --
>>>
>>> Check out the new Asterisk community forum at:
>>> https://community.asterisk.org/
>>>
>>> New to Asterisk? Start here:
>>>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>>>
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>

>>>
>>
>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Marek Greško]

I currently disabled also RTSP ALG and rebooted the router. Fixed for
now. I do not know for how long.

Marek


2021-07-26 8:54 GMT+02:00, Marek Greško :
> Hmm, back to original problem. My happines was premature. Today one of
> the phones have no audio again. I see packets from lan segment again.
>
> I double checked the router configuration. SIP ALG is disabled. There
> are also another ALGs present:
>
> NAT ALG
> RTSP ALG
> PPTP ALG
> IPSEC ALG
>
> Which of them are neede to be disabled?
>
> As of my observations these problems are triggered by reboots on
> asterisk side. How could this be related? (I may be wrong.)
>
> Thanks
>
> Marek
>
>
>
> 2021-07-23 14:54 GMT+02:00, Marek Greško :
>> I achieved a partial success adding --use-compact-form option.
>>
>> Marek
>>
>>
>> 2021-07-23 13:47 GMT+02:00, Marek Greško :
>>> Hello,
>>>
>>> your suggestion to turn off SIP ALG on provider's router was probably
>>> correct. no problem until now. Thank you very much.
>>>
>>> I just found out another issue. I had a pjsue client in that network
>>> which called specific number when turned on. It was working perfectly
>>> with the old provider with working SIP ALG. But now with this provider
>>> and SIP ALG disabled I am not able to make the call using pjsua
>>> client.
>>>
>>> My pjsua config looks like this:
>>> --id sip:ext@asterisk.domain
>>> --registrar sip:asterisk.domain
>>> --proxy sip:asterisk.domain
>>> --outbound sip:asterisk.domain
>>> --realm *
>>> --username username
>>> --password password
>>> --null-audio
>>> --no-tcp
>>> --max-calls=1
>>> --no-vad
>>>
>>> The pjsua client successfully registers but is unable to call.
>>>
>>> I see the following:
>>> IP address change detected for account 1
>>> (localip:5060-->nattedip:newport). Updating registration (using method
>>> 4)
>>> Temporary failure in sending Request msg INVITE/cseq=, will try
>>> next server: Unsupported transport (PJSIP_EUNSUPTRANSPORT)
>>>
>>> What could be the problem? How can I convince pjsue to work correctly
>>> behind nat?
>>>
>>> Thanks
>>>
>>> Marek
>>>
>>>
>>>
>>>
>>>
>>> 2021-07-10 11:08 GMT+02:00, Marek Greško :
 Hello,

 I just disabled. Currently it is working. I shloud give it some time
 to confirm the problem has gone. Maybe one month would be enough to
 confirm.

 Thanks

 Marek


 2021-07-09 20:11 GMT+02:00, Abdenasser Ghomri
 :
> Yes just disable the SIP ALG and see if it helps, Thanks.
>
> Best Regards,
>
> On Fri, Jul 9, 2021, 09:10 Antony Stone <
> antony.st...@asterisk.open.source.it> wrote:
>
>> On Friday 09 July 2021 at 08:47:46, Marek Greško wrote:
>>
>> > Hello,
>> >
>> > yes SIP ALG are anbled on the router. Should I disable?
>>
>> In my opinion, always.
>>
>> Antony.
>>
>> --
>> I don't know, maybe if we all waited then cosmic rays would write all
>> our
>> software for us. Of course it might take a while.
>>
>>  - Ron Minnich, Los Alamos National Laboratory
>>
>>Please reply to
>> the
>> list;
>>  please
>> *don't*
>> CC
>> me.
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> Check out the new Asterisk community forum at:
>> https://community.asterisk.org/
>>
>> New to Asterisk? Start here:
>>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>http://lists.digium.com/mailman/listinfo/asterisk-users
>

>>>
>>
>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Hmm, back to original problem. My happines was premature. Today one of
the phones have no audio again. I see packets from lan segment again.

I double checked the router configuration. SIP ALG is disabled. There
are also another ALGs present:

NAT ALG
RTSP ALG
PPTP ALG
IPSEC ALG

Which of them are neede to be disabled?

As of my observations these problems are triggered by reboots on
asterisk side. How could this be related? (I may be wrong.)

Thanks

Marek



2021-07-23 14:54 GMT+02:00, Marek Greško :
> I achieved a partial success adding --use-compact-form option.
>
> Marek
>
>
> 2021-07-23 13:47 GMT+02:00, Marek Greško :
>> Hello,
>>
>> your suggestion to turn off SIP ALG on provider's router was probably
>> correct. no problem until now. Thank you very much.
>>
>> I just found out another issue. I had a pjsue client in that network
>> which called specific number when turned on. It was working perfectly
>> with the old provider with working SIP ALG. But now with this provider
>> and SIP ALG disabled I am not able to make the call using pjsua
>> client.
>>
>> My pjsua config looks like this:
>> --id sip:ext@asterisk.domain
>> --registrar sip:asterisk.domain
>> --proxy sip:asterisk.domain
>> --outbound sip:asterisk.domain
>> --realm *
>> --username username
>> --password password
>> --null-audio
>> --no-tcp
>> --max-calls=1
>> --no-vad
>>
>> The pjsua client successfully registers but is unable to call.
>>
>> I see the following:
>> IP address change detected for account 1
>> (localip:5060-->nattedip:newport). Updating registration (using method
>> 4)
>> Temporary failure in sending Request msg INVITE/cseq=, will try
>> next server: Unsupported transport (PJSIP_EUNSUPTRANSPORT)
>>
>> What could be the problem? How can I convince pjsue to work correctly
>> behind nat?
>>
>> Thanks
>>
>> Marek
>>
>>
>>
>>
>>
>> 2021-07-10 11:08 GMT+02:00, Marek Greško :
>>> Hello,
>>>
>>> I just disabled. Currently it is working. I shloud give it some time
>>> to confirm the problem has gone. Maybe one month would be enough to
>>> confirm.
>>>
>>> Thanks
>>>
>>> Marek
>>>
>>>
>>> 2021-07-09 20:11 GMT+02:00, Abdenasser Ghomri :
 Yes just disable the SIP ALG and see if it helps, Thanks.

 Best Regards,

 On Fri, Jul 9, 2021, 09:10 Antony Stone <
 antony.st...@asterisk.open.source.it> wrote:

> On Friday 09 July 2021 at 08:47:46, Marek Greško wrote:
>
> > Hello,
> >
> > yes SIP ALG are anbled on the router. Should I disable?
>
> In my opinion, always.
>
> Antony.
>
> --
> I don't know, maybe if we all waited then cosmic rays would write all
> our
> software for us. Of course it might take a while.
>
>  - Ron Minnich, Los Alamos National Laboratory
>
>Please reply to the
> list;
>  please
> *don't*
> CC
> me.
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users

>>>
>>
>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Marek Greško]

I achieved a partial success adding --use-compact-form option.

Marek


2021-07-23 13:47 GMT+02:00, Marek Greško :
> Hello,
>
> your suggestion to turn off SIP ALG on provider's router was probably
> correct. no problem until now. Thank you very much.
>
> I just found out another issue. I had a pjsue client in that network
> which called specific number when turned on. It was working perfectly
> with the old provider with working SIP ALG. But now with this provider
> and SIP ALG disabled I am not able to make the call using pjsua
> client.
>
> My pjsua config looks like this:
> --id sip:ext@asterisk.domain
> --registrar sip:asterisk.domain
> --proxy sip:asterisk.domain
> --outbound sip:asterisk.domain
> --realm *
> --username username
> --password password
> --null-audio
> --no-tcp
> --max-calls=1
> --no-vad
>
> The pjsua client successfully registers but is unable to call.
>
> I see the following:
> IP address change detected for account 1
> (localip:5060-->nattedip:newport). Updating registration (using method
> 4)
> Temporary failure in sending Request msg INVITE/cseq=, will try
> next server: Unsupported transport (PJSIP_EUNSUPTRANSPORT)
>
> What could be the problem? How can I convince pjsue to work correctly
> behind nat?
>
> Thanks
>
> Marek
>
>
>
>
>
> 2021-07-10 11:08 GMT+02:00, Marek Greško :
>> Hello,
>>
>> I just disabled. Currently it is working. I shloud give it some time
>> to confirm the problem has gone. Maybe one month would be enough to
>> confirm.
>>
>> Thanks
>>
>> Marek
>>
>>
>> 2021-07-09 20:11 GMT+02:00, Abdenasser Ghomri :
>>> Yes just disable the SIP ALG and see if it helps, Thanks.
>>>
>>> Best Regards,
>>>
>>> On Fri, Jul 9, 2021, 09:10 Antony Stone <
>>> antony.st...@asterisk.open.source.it> wrote:
>>>
 On Friday 09 July 2021 at 08:47:46, Marek Greško wrote:

 > Hello,
 >
 > yes SIP ALG are anbled on the router. Should I disable?

 In my opinion, always.

 Antony.

 --
 I don't know, maybe if we all waited then cosmic rays would write all
 our
 software for us. Of course it might take a while.

  - Ron Minnich, Los Alamos National Laboratory

Please reply to the
 list;
  please *don't*
 CC
 me.

 --
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com --

 Check out the new Asterisk community forum at:
 https://community.asterisk.org/

 New to Asterisk? Start here:
   https://wiki.asterisk.org/wiki/display/AST/Getting+Started

 asterisk-users mailing list
 To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
>>>
>>
>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Hello,

your suggestion to turn off SIP ALG on provider's router was probably
correct. no problem until now. Thank you very much.

I just found out another issue. I had a pjsue client in that network
which called specific number when turned on. It was working perfectly
with the old provider with working SIP ALG. But now with this provider
and SIP ALG disabled I am not able to make the call using pjsua
client.

My pjsua config looks like this:
--id sip:ext@asterisk.domain
--registrar sip:asterisk.domain
--proxy sip:asterisk.domain
--outbound sip:asterisk.domain
--realm *
--username username
--password password
--null-audio
--no-tcp
--max-calls=1
--no-vad

The pjsua client successfully registers but is unable to call.

I see the following:
IP address change detected for account 1
(localip:5060-->nattedip:newport). Updating registration (using method
4)
Temporary failure in sending Request msg INVITE/cseq=, will try
next server: Unsupported transport (PJSIP_EUNSUPTRANSPORT)

What could be the problem? How can I convince pjsue to work correctly
behind nat?

Thanks

Marek





2021-07-10 11:08 GMT+02:00, Marek Greško :
> Hello,
>
> I just disabled. Currently it is working. I shloud give it some time
> to confirm the problem has gone. Maybe one month would be enough to
> confirm.
>
> Thanks
>
> Marek
>
>
> 2021-07-09 20:11 GMT+02:00, Abdenasser Ghomri :
>> Yes just disable the SIP ALG and see if it helps, Thanks.
>>
>> Best Regards,
>>
>> On Fri, Jul 9, 2021, 09:10 Antony Stone <
>> antony.st...@asterisk.open.source.it> wrote:
>>
>>> On Friday 09 July 2021 at 08:47:46, Marek Greško wrote:
>>>
>>> > Hello,
>>> >
>>> > yes SIP ALG are anbled on the router. Should I disable?
>>>
>>> In my opinion, always.
>>>
>>> Antony.
>>>
>>> --
>>> I don't know, maybe if we all waited then cosmic rays would write all
>>> our
>>> software for us. Of course it might take a while.
>>>
>>>  - Ron Minnich, Los Alamos National Laboratory
>>>
>>>Please reply to the
>>> list;
>>>  please *don't*
>>> CC
>>> me.
>>>
>>> --
>>> _
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> Check out the new Asterisk community forum at:
>>> https://community.asterisk.org/
>>>
>>> New to Asterisk? Start here:
>>>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>>>
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Hello,

I just disabled. Currently it is working. I shloud give it some time
to confirm the problem has gone. Maybe one month would be enough to
confirm.

Thanks

Marek


2021-07-09 20:11 GMT+02:00, Abdenasser Ghomri :
> Yes just disable the SIP ALG and see if it helps, Thanks.
>
> Best Regards,
>
> On Fri, Jul 9, 2021, 09:10 Antony Stone <
> antony.st...@asterisk.open.source.it> wrote:
>
>> On Friday 09 July 2021 at 08:47:46, Marek Greško wrote:
>>
>> > Hello,
>> >
>> > yes SIP ALG are anbled on the router. Should I disable?
>>
>> In my opinion, always.
>>
>> Antony.
>>
>> --
>> I don't know, maybe if we all waited then cosmic rays would write all our
>> software for us. Of course it might take a while.
>>
>>  - Ron Minnich, Los Alamos National Laboratory
>>
>>Please reply to the
>> list;
>>  please *don't*
>> CC
>> me.
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> Check out the new Asterisk community forum at:
>> https://community.asterisk.org/
>>
>> New to Asterisk? Start here:
>>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>http://lists.digium.com/mailman/listinfo/asterisk-users
>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Abdenasser Ghomri]

Yes just disable the SIP ALG and see if it helps, Thanks.

Best Regards,

On Fri, Jul 9, 2021, 09:10 Antony Stone <
antony.st...@asterisk.open.source.it> wrote:

> On Friday 09 July 2021 at 08:47:46, Marek Greško wrote:
>
> > Hello,
> >
> > yes SIP ALG are anbled on the router. Should I disable?
>
> In my opinion, always.
>
> Antony.
>
> --
> I don't know, maybe if we all waited then cosmic rays would write all our
> software for us. Of course it might take a while.
>
>  - Ron Minnich, Los Alamos National Laboratory
>
>Please reply to the
> list;
>  please *don't* CC
> me.
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Antony Stone]

On Friday 09 July 2021 at 08:47:46, Marek Greško wrote:

> Hello,
> 
> yes SIP ALG are anbled on the router. Should I disable?

In my opinion, always.

Antony.

-- 
I don't know, maybe if we all waited then cosmic rays would write all our 
software for us. Of course it might take a while.

 - Ron Minnich, Los Alamos National Laboratory

   Please reply to the list;
 please *don't* CC me.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Marek Greško]

To be more specific I was on the
https://wiki.asterisk.org/wiki/display/AST/Getting+Started already,
but I assume all the additional transport parameters are relevant only
when asterisk itself is behind nat. Is not it true?

Marek


2021-07-09 8:47 GMT+02:00, Marek Greško :
> Hello,
>
> yes SIP ALG are anbled on the router. Should I disable?
>
> Transport config looks like that:
>
> [transport-udp]
> type = transport
> protocol = udp
> bind = 0.0.0.0
> domain = mydomain.com
>
> Asterisk itself is not natted.
>
> Marek
>
>
> 2021-07-08 21:14 GMT+02:00, Michael L. Young :
>> El jue, 8 de jul. de 2021 a la(s) 14:58, Marek Greško
>> (mgres...@gmail.com)
>> escribió:
>>
>>
>>> The asterisk is connected to the internet with public static IP address.
>>>
>>> The pjsip config contains:
>>>
>>>
>> What does your transport config look like?
>>
>> Take a look at this wiki page:
>> https://wiki.asterisk.org/wiki/display/AST/Configuring+res_pjsip+to+work+through+NAT
>>
>> --
>> Michael L. Young
>> (elguero)
>>
>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Marek Greško]

Hello,

yes SIP ALG are anbled on the router. Should I disable?

Transport config looks like that:

[transport-udp]
type = transport
protocol = udp
bind = 0.0.0.0
domain = mydomain.com

Asterisk itself is not natted.

Marek


2021-07-08 21:14 GMT+02:00, Michael L. Young :
> El jue, 8 de jul. de 2021 a la(s) 14:58, Marek Greško (mgres...@gmail.com)
> escribió:
>
>
>> The asterisk is connected to the internet with public static IP address.
>>
>> The pjsip config contains:
>>
>>
> What does your transport config look like?
>
> Take a look at this wiki page:
> https://wiki.asterisk.org/wiki/display/AST/Configuring+res_pjsip+to+work+through+NAT
>
> --
> Michael L. Young
> (elguero)
>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Michael L. Young]

El jue, 8 de jul. de 2021 a la(s) 14:58, Marek Greško (mgres...@gmail.com)
escribió:


> The asterisk is connected to the internet with public static IP address.
>
> The pjsip config contains:
>
>
What does your transport config look like?

Take a look at this wiki page:
https://wiki.asterisk.org/wiki/display/AST/Configuring+res_pjsip+to+work+through+NAT

--
Michael L. Young
(elguero)
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] problems with natted phones

[Abdenasser Ghomri]

Have you tried to see if the router has any SIP ALG enabled this might
create such issues, Thanks.

Best Regards,


On Thu, Jul 8, 2021, 19:59 Marek Greško  wrote:

> Hello,
>
> I have an asterisk setup using pjsip. Everything used to work
> correctly until one remote site changed internet provider and thier
> router does not support sip protocol algorithms.
>
> It works for some time, but then suddenly audio stops working both
> directions. When this happens I see RTP responses going out to the
> local address of the natted phone, not to the natted address. The
> problem appears for the phones independently.
>
> The asterisk is connected to the internet with public static IP address.
>
> The pjsip config contains:
>
> [aor]
> type=aor
> qualify_frequency = 60
> max_contacts=1
> remove_existing = yes
>
> [endpoint]
> type = endpoint
> context = internal
> dtmf_mode = rfc4733
> disallow = all
> allow = alaw
> allow = ilbc
> allow = g729
> allow = gsm
> allow = g723
> direct_media = no
> allow_subscribe = yes
> subscribe_context = blf
> rewrite_contact = yes
> rtp_symmetric = yes
> force_rport = yes
>
>
> Am I missing something? Why the communication breaks suddenly?
>
> Thanks
>
> Marek
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] problems with natted phones

[Marek Greško]

Hello,

I have an asterisk setup using pjsip. Everything used to work
correctly until one remote site changed internet provider and thier
router does not support sip protocol algorithms.

It works for some time, but then suddenly audio stops working both
directions. When this happens I see RTP responses going out to the
local address of the natted phone, not to the natted address. The
problem appears for the phones independently.

The asterisk is connected to the internet with public static IP address.

The pjsip config contains:

[aor]
type=aor
qualify_frequency = 60
max_contacts=1
remove_existing = yes

[endpoint]
type = endpoint
context = internal
dtmf_mode = rfc4733
disallow = all
allow = alaw
allow = ilbc
allow = g729
allow = gsm
allow = g723
direct_media = no
allow_subscribe = yes
subscribe_context = blf
rewrite_contact = yes
rtp_symmetric = yes
force_rport = yes


Am I missing something? Why the communication breaks suddenly?

Thanks

Marek

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users