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
