[asterisk-users] problems with natted phones
Marek Greško
mgresko8 at gmail.com
Fri Sep 3 02:41:33 CDT 2021
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: <sip:111 at asterisk>;tag=...
To: <sip:999 at provider>;tag=...
Call-ID: ...
CSeq: ... INVITE
Contact: <sip:999 at lan:5060>
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: <sip:111 at asterisk>;tag=...
To: <sip:999 at provider>;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: <sip:111 at asterisk>;tag=...
To: <sip:999 at provider>;tag=...
Call-ID: ...
CSeq: ... INVITE
Contact: <sip:999 at lan:5060>
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: <sip:111 at asterisk>;tag=...
To: <sip:999 at provider>;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 <duncan at e-simple.co.nz>:
>
>>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 <mgresko8 at gmail.com>:
>>> 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 <mgresko8 at gmail.com>:
>>>> 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 <mgresko8 at gmail.com>:
>>>>> I achieved a partial success adding --use-compact-form option.
>>>>>
>>>>> Marek
>>>>>
>>>>>
>>>>> 2021-07-23 13:47 GMT+02:00, Marek Greško <mgresko8 at gmail.com>:
>>>>>> 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 at 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 <mgresko8 at gmail.com>:
>>>>>>> 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
>>>>>>> <ghomri.nasser at gmail.com>:
>>>>>>>> Yes just disable the SIP ALG and see if it helps, Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> On Fri, Jul 9, 2021, 09:10 Antony Stone <
>>>>>>>>Antony.Stone at 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
>
>
> --
> _____________________________________________________________________
> -- 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