I added the bind_rtp_to_media_address=yes on all endpoints but still the same behaviour. The funny thing is that the G711 audio early media works and doesn't have that Private IP issue. I was also able to cross check with chan_sip on Asterisk 15, exactly the same wrong behaviour. See following capture (PJSIP):
No. Time Source Destination Protocol Length Info 187 2018-04-11 07:19:56.735967 159.89.XX.XX 192.168.1.185 H264 943 PT=H264, SSRC=0x3A7AF929, Seq=27144, Time=1248011648 FU-A Frame 187: 943 bytes on wire (7544 bits), 943 bytes captured (7544 bits) Ethernet II, Src: da:81:42:3d:d0:e7 (da:81:42:3d:d0:e7), Dst: IETF-VRRP-VRID_6e (00:00:5e:00:01:6e) Internet Protocol Version 4, Src: 159.89.XX.XX, Dst: 192.168.1.185 User Datagram Protocol, Src Port: 11502, Dst Port: 5022 Real-Time Transport Protocol H.264 No. Time Source Destination Protocol Length Info 188 2018-04-11 07:19:56.735993 159.89.XX.XX 192.168.1.185 H264 943 PT=H264, SSRC=0x3A7AF929, Seq=27145, Time=1248011648, Mark FU-A End Frame 188: 943 bytes on wire (7544 bits), 943 bytes captured (7544 bits) Ethernet II, Src: da:81:42:3d:d0:e7 (da:81:42:3d:d0:e7), Dst: IETF-VRRP-VRID_6e (00:00:5e:00:01:6e) Internet Protocol Version 4, Src: 159.89.XX.XX, Dst: 192.168.1.185 User Datagram Protocol, Src Port: 11502, Dst Port: 5022 Real-Time Transport Protocol H.264 No. Time Source Destination Protocol Length Info 189 2018-04-11 07:19:56.738966 178.82.XX.XX 159.89.XX.XX RTP 214 PT=ITU-T G.711 PCMU, SSRC=0x2A1A1C31, Seq=1820, Time=1104983225 Frame 189: 214 bytes on wire (1712 bits), 214 bytes captured (1712 bits) Ethernet II, Src: JuniperN_34:67:f0 (40:a6:77:34:67:f0), Dst: da:81:42:3d:d0:e7 (da:81:42:3d:d0:e7) Internet Protocol Version 4, Src: 178.82.XX.XX, Dst: 159.89.XX.XX User Datagram Protocol, Src Port: 5020, Dst Port: 16130 Real-Time Transport Protocol No. Time Source Destination Protocol Length Info 190 2018-04-11 07:19:56.738975 178.82.XX.XX 159.89.XX.XX RTP 214 PT=ITU-T G.722, SSRC=0x49CD55FD, Seq=26679, Time=470333826 Frame 190: 214 bytes on wire (1712 bits), 214 bytes captured (1712 bits) Ethernet II, Src: JuniperN_4f:3f:f0 (40:a6:77:4f:3f:f0), Dst: da:81:42:3d:d0:e7 (da:81:42:3d:d0:e7) Internet Protocol Version 4, Src: 178.82.XX.XX, Dst: 159.89.XX.XX User Datagram Protocol, Src Port: 5004, Dst Port: 18280 Real-Time Transport Protocol 2018-04-11 9:11 GMT+02:00 Floimair Florian <f.floim...@commend.com>: > I did a quick check between what I have set and your settings below. > > > > You can try the following and see if it helps > > > > In your endpoint: > bind_rtp_to_media_address=yes > > > > > > > > > > With best regards > > > > *Florian Floimair *Innovation - Software-Development - VoIP & DevOps > > > *COMMEND INTERNATIONAL GMBH *A-5020 Salzburg, Saalachstraße 51 > Tel: +43-662-85 62 25 > Fax: +43-662-85 62 26 > http://www.commend.com > > > > *Security and Communication by Commend *FN 178618z | LG Salzburg > > > > *Von:* asterisk-users-boun...@lists.digium.com [mailto:asterisk-users- > boun...@lists.digium.com] *Im Auftrag von *Benjamin Marty > *Gesendet:* Mittwoch, 11. April 2018 08:55 > *An:* Asterisk Users Mailing List - Non-Commercial Discussion < > asterisk-users@lists.digium.com> > > *Betreff:* Re: [asterisk-users] Asterisk behind NAT Early Media Video > > > > I think I found the root cause. The H264 Early Media video is received > successfully on the Asterisk Server. It also seems to get processed. But > it's send to the private IP of the receipent SIP phone. > > For clarification: > > 178.82.XX.XX is my Public IP of my Internet access. Both phones use this > as Public IP via standard Source NAT. > > 159.89.XX.XX is the IP of the Asterisk Server. For this test I used a > Server without Destination NAT. So the eth0 interface has this IP. > > Packet capture: > > No. Time Source > Destination Protocol Length Info > 141 2018-04-11 06:40:03.306561 178.82.XX.XX 159.89.XX.XX > H264 64 PT=H264, SSRC=0x3CB1E12D, Seq=19561, Time=319121408 > SPS > > Frame 141: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) > Ethernet II, Src: JuniperN_34:67:f0 (40:a6:77:34:67:f0), Dst: > da:81:42:3d:d0:e7 (da:81:42:3d:d0:e7) > Internet Protocol Version 4, Src: 178.82.169.0, Dst: 159.89.104.193 > User Datagram Protocol, Src Port: 5006, Dst Port: 13182 > Real-Time Transport Protocol > H.264 > > No. Time Source > Destination Protocol Length Info > 142 2018-04-11 06:40:03.306682 159.89.XX.XX > 192.168.XX.XX H264 64 PT=H264, SSRC=0x5EE97C55, Seq=30572, > Time=319121408 SPS > > Frame 142: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) > Ethernet II, Src: da:81:42:3d:d0:e7 (da:81:42:3d:d0:e7), Dst: > IETF-VRRP-VRID_6e (00:00:5e:00:01:6e) > Internet Protocol Version 4, Src: 159.89.104.193, Dst: 192.168.1.185 > User Datagram Protocol, Src Port: 10298, Dst Port: 5022 > Real-Time Transport Protocol > H.264 > > PJSIP.conf: > [7004] > type = endpoint > context = internal > rewrite_contact = yes > direct_media = no > rtp_symmetric = yes > ;force_rport = yes > disallow = all > allow = g722, alaw, ulaw, gsm, ilbc, h264 > aors = 7004 > auth = auth7004 > > [7004] > type = aor > max_contacts = 2 > > [auth7004] > type=auth > auth_type=userpass > password=1234 > username=7004 > > extensions.conf: > [internal] > exten => _700X,1,Dial(PJSIP/${EXTEN}) > > > > > > 2018-04-10 16:43 GMT+02:00 Benjamin Marty <benjamin.ma...@gmail.com>: > > I just noticed, the calling device isn't even sending the early media > video stream. It just sends an early media audio stream. Is there propably > a change in the signaling needed? > > (On another P2P SIP Server the early media video works.) > > > > 2018-04-10 12:29 GMT+02:00 Benjamin Marty <benjamin.ma...@gmail.com>: > > Hi Florian > > I already have the external_media_address set in the PJSIP setup. Also the > external_signaling_address is set to the Public IP. If I make a call from > an Early Media (video&audio) capable device to an Early Media capable > device (also video&audio) the Early Media audio works perfectly. But no > video. If I sniff with wireshark on the recipent device I just see G711 > (audio) RTP traffic. The h264 RTP traffic is missing before I accept the > call. After accepting the call the h264 RTP traffic comes through. > > The 183 SIP protocoll comes through. Even Asterisk is noticing it: > -- PJSIP/6002-00000013 is making progress passing it to PJSIP/6001-00000012 > > > > I tried both Asterisk 15 with pjsip.conf configuration and Asterisk 13 > with sip.conf (chan_sip). In both cases I just put the both case > AST_FRAME_VIDEO: statements before the two voice cases, like in your diff > and recompiled/reinstalled. > > Regards > > Benjamin > > > > > > 2018-04-10 9:37 GMT+02:00 Floimair Florian <f.floim...@commend.com>: > > Hi Benjamin! > > You're obviously using a similar scenario that I have in place for testing. > I initially had issues with early media (not only video also audio) as > well in that scenario. What I had to do was to additionally set > > external_media_address=<your external IP> > > in pjsip.conf > > Also, as I wrote the patch for early-media video I'd be interested in any > feedback from it. > > > > > With best regards > > Florian Floimair > Innovation - Software-Development - VoIP & DevOps > > COMMEND INTERNATIONAL GMBH > A-5020 Salzburg, Saalachstraße 51 > Tel: +43-662-85 62 25 > Fax: +43-662-85 62 26 > http://www.commend.com > <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.commend.com&c=E,1,3-QFS79bl07XJ1At9-FN042YWg_pIhOoaMJ3B13IzEVsdUP_-SFZDUg5wBrnkEzQgB7TrZRQzaiO0icSJ3UXSJSRnjIVOu0661La-Fj5_q1BczQlPWU_otM,&typo=1> > > Security and Communication by Commend > > FN 178618z | LG Salzburg > > -----Ursprüngliche Nachricht----- > Von: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users- > boun...@lists.digium.com] Im Auftrag von Joshua Colp > Gesendet: Montag, 9. April 2018 18:15 > An: asterisk-users@lists.digium.com > Betreff: Re: [asterisk-users] Asterisk behind NAT Early Media Video > > On Mon, Apr 9, 2018, at 1:05 PM, Benjamin Marty wrote: > > wohoo, so if I unterstand it correctly with that patch early media > > video works over the Asterisk server? In other words the Asterisk > > server get's able to (process/)forward the early media video stream with > that patch? > > The patch forwards video while in an early media state before the call is > answered and bridged, yes. > > -- > Joshua Colp > Digium, Inc. | Senior Software Developer > 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: > https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.digium.com&c=E,1, > fYho2t3OGEPSC6ILhV9IAhfyqyv57q-c2eodmmoTlhRYCnEpbgeqpqYbk39h-m_ > lDWff7UIltd0zakv3XGb858ysVJbX0qeWGwdsbcgvduNnaBqVCDk,&typo=1 & > www.asterisk.org > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by https://linkprotect.cudasvc. > com/url?a=http%3a%2f%2fwww.api-digital.com&c=E,1, > XToemLgPy6NQVyb_dF1q0qXSk-3YylF6rmIrWQvPhspxagnF5G63VHCU > 2nB67YHjZewMQU1rUCME4JBQMFPmNOCpc6ESOin_3Al6kti-lRo,&typo=1 -- > > 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: > https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flists. > digium.com%2fmailman%2flistinfo%2fasterisk-users&c= > E,1,6VfJH-ysYuWrel9Apl4EqHb4_MpDTQHdQ3lJU3_Zojgbn4stUdMfchlswYSSwVO9jmol- > 9H658j2bZr9JmLmb9WCM5OXKTsb_DsBIYKACtBorWRSU6-q1FjJkrbc&typo=1 > > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com > <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.api-digital.com&c=E,1,PnNwdEEyPY7U1qaNcxb8yUrJXcp8-NvkrDLCR364tWngtudmTLLLKMqIZMGStTHZj13smqfVh9i5NxlSKDrNcwhVpVtXB2PEy_r7vw_mFQVXvOTG6Ij1gYZW&typo=1> > -- > > 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 > <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flists.digium.com%2fmailman%2flistinfo%2fasterisk-users&c=E,1,uQCF0lb-FVg7pXggKAUTEtnGK1_1mGw0nOxXQuIjguKmln4FVUxJx5U_zKiUgjLJga4yYkV2gBkqpmYOax10QzZSczShffKMpqE2hPha_ocKhdu0Vdbm8Q,,&typo=1> > > > > > > > > -- > _____________________________________________________________________ > -- 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