[asterisk-bugs] [JIRA] (ASTERISK-26729) Asterisk behind NAT not sending audio according to SDP

Tue Mar 14 14:06:10 CDT 2017

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235814#comment-235814 ] 

Luke Escude edited comment on ASTERISK-26729 at 3/14/17 2:04 PM:
-----------------------------------------------------------------

I apologize, however here's the proof (in Video2.txt): Keep in mind this is an Echo() with Answer() in front.... The audio works. It's the video re-INVITE that's failing.

[Mar 14 17:45:19] VERBOSE[1281] res_pjsip_logger.c: <--- Received SIP request (1199 bytes) from UDP:206.126.62.175:5060 --->
INVITE sip:*43 at 206.126.62.178:5060 SIP/2.0
Via: SIP/2.0/UDP 206.126.62.175;branch=z9hG4bK82f3.bc7727e32286c95afb53687ba5a45ecd.0
Via: SIP/2.0/UDP 192.168.1.12:18108;received=97.77.119.234;branch=z9hG4bK1214768101;rport=18108
Route: <sip:206.126.62.175:5060>
From: "PBX 242" <sip:242 at sip.primevox.net>;tag=974045422
To: <sip:*43 at sip.primevox.net>;tag=428575d4-4a59-4a93-a522-34ac9b8ee233
Call-ID: 1070804760-18108-19 at BJC.BGI.B.BC
CSeq: 183 INVITE
Contact: <sip:424242242 at 192.168.1.12:18108>
Max-Forwards: 70
Supported: replaces, path, timer, eventlist
User-Agent: Grandstream Wave/Android 1.0.2.5
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Type: application/sdp
Accept: application/sdp, application/dtmf-relay
Content-Length:   395

v=0
o=424242242 8000 8001 IN IP4 206.126.62.175
s=SIP Call
c=IN IP4 206.126.62.175
t=0 0
m=audio 11590 RTP/AVP 0 8 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
m=video 13452 RTP/AVP 105
b=AS:704
a=sendrecv
a=rtpmap:105 H264/90000
a=fmtp:105 profile-level-id=428016; packetization-mode=1
a=nortpproxy:yes

You can see that the Video RTP port is 13452 - However if you do a search for that port number, it never appears ever again in the debug output. Thus, Asterisk is not sending any info to it.

I realize it's not required by the RFC, but Asterisk should still have the capability to traverse NAT in itself.

was (Author: lukeescude):
I apologize, however here's the proof (in Video2.txt): Keep in mind this is an Echo() with Answer() in front

[Mar 14 17:45:19] VERBOSE[1281] res_pjsip_logger.c: <--- Received SIP request (1199 bytes) from UDP:206.126.62.175:5060 --->
INVITE sip:*43 at 206.126.62.178:5060 SIP/2.0
Via: SIP/2.0/UDP 206.126.62.175;branch=z9hG4bK82f3.bc7727e32286c95afb53687ba5a45ecd.0
Via: SIP/2.0/UDP 192.168.1.12:18108;received=97.77.119.234;branch=z9hG4bK1214768101;rport=18108
Route: <sip:206.126.62.175:5060>
From: "PBX 242" <sip:242 at sip.primevox.net>;tag=974045422
To: <sip:*43 at sip.primevox.net>;tag=428575d4-4a59-4a93-a522-34ac9b8ee233
Call-ID: 1070804760-18108-19 at BJC.BGI.B.BC
CSeq: 183 INVITE
Contact: <sip:424242242 at 192.168.1.12:18108>
Max-Forwards: 70
Supported: replaces, path, timer, eventlist
User-Agent: Grandstream Wave/Android 1.0.2.5
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Type: application/sdp
Accept: application/sdp, application/dtmf-relay
Content-Length:   395

v=0
o=424242242 8000 8001 IN IP4 206.126.62.175
s=SIP Call
c=IN IP4 206.126.62.175
t=0 0
m=audio 11590 RTP/AVP 0 8 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
m=video 13452 RTP/AVP 105
b=AS:704
a=sendrecv
a=rtpmap:105 H264/90000
a=fmtp:105 profile-level-id=428016; packetization-mode=1
a=nortpproxy:yes

You can see that the Video RTP port is 13452 - However if you do a search for that port number, it never appears ever again in the debug output. Thus, Asterisk is not sending any info to it.

I realize it's not required by the RFC, but Asterisk should still have the capability to traverse NAT in itself.

> Asterisk behind NAT not sending audio according to SDP
> ------------------------------------------------------
>
>                 Key: ASTERISK-26729
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26729
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 13.13.1
>         Environment: x64 CentOS
>            Reporter: Luke Escude
>            Assignee: Unassigned
>         Attachments: call1.pcap, Call1.txt, echo1.pcap, Echo1.txt, Video2.txt, video.pcap, Video.txt
>
>
> We are running Asterisk 13.13.1 with PJSIP.
> The setup is as follows:
> The Asterisk boxes are all virtualized behind NAT - let's say their address space is 172.x.x.x. The router that controls that nat is IP address 10.0.4.1. Kamailio/RTPProxy is running on 10.0.1.1.
> Kamailio essentially looks like a "public" IP to the asterisk boxes - we have them REGISTERING to kamailio to IP address 10.0.1.1 (which is routable of course). That way, Kamailio knows how to get to the Asterisks via their "public IP" (10.0.4.1) and NAT port (probably like 16875 or whatever).
> SIP communication happens wonderfully with this setup.
> However, when Kamailio sends an SDP containing its address 10.0.1.1 and an RTP address, it seems like Asterisk doesn't want to send audio to that address. In order for a new NAT port to open, Asterisk has to "talk" first.
> Regardless of our pjsip configuration, we cannot get Asterisk to behave properly, even by following the wiki and setting the external signaling/media addresses.

--
This message was sent by Atlassian JIRA
(v6.2#6252)