> On 6/09/2021, at 7:10 PM, Marek Greško <mgresko8 at gmail.com> wrote:
>
> Hello,
>
>
>
> 2021-09-06 2:51 GMT+02:00, Duncan Turnbull <duncan at
turnbull.co.nz>:
>> 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 <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