[asterisk-users] problems with natted phones

Marek Greško mgresko8 at gmail.com
Mon Sep 6 04:50:13 CDT 2021 

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 <mgresko8 at gmail.com>:
> 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 <mgresko8 at gmail.com>
>>>>> 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 <duncan at e-simple.co.nz>:
>>>>>>
>>>>>>
>>>>>>> On 5/09/2021, at 10:21 AM, Marek Greško <mgresko8 at gmail.com> 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
>>>>>>> <Antony.Stone at asterisk.open.source.it>:
>>>>>>>>> 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 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
>

More information about the asterisk-users mailing list