Floimair Florian
2018-Apr-11 07:11 UTC
[asterisk-users] Asterisk behind NAT Early Media Video
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-bounces at lists.digium.com [mailto:asterisk-users-bounces
at 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
at 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.marty at
gmail.com<mailto:benjamin.marty at 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.marty at
gmail.com<mailto:benjamin.marty at 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.floimair at
commend.com<mailto:f.floimair at 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-bounces at lists.digium.com<mailto:asterisk-users-bounces
at lists.digium.com> [mailto:asterisk-users-bounces at
lists.digium.com<mailto:asterisk-users-bounces at lists.digium.com>] Im
Auftrag von Joshua Colp
Gesendet: Montag, 9. April 2018 18:15
An: asterisk-users at lists.digium.com<mailto:asterisk-users at
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<http://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-3YylF6rmIrWQvPhspxagnF5G63VHCU2nB67YHjZewMQU1rUCME4JBQMFPmNOCpc6ESOin_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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20180411/9379d65d/attachment.html>
Benjamin Marty
2018-Apr-11 07:33 UTC
[asterisk-users] Asterisk behind NAT Early Media Video
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.floimair at 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-bounces at lists.digium.com [mailto:asterisk-users-
> bounces at 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 at 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.marty at
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.marty at
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.floimair at
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-bounces at lists.digium.com [mailto:asterisk-users-
> bounces at lists.digium.com] Im Auftrag von Joshua Colp
> Gesendet: Montag, 9. April 2018 18:15
> An: asterisk-users at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20180411/49e733a1/attachment-0001.html>
On Wed, Apr 11, 2018, at 4:33 AM, Benjamin Marty wrote:> 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):As I stated previously in order for media to go to the source IP address and port, media has to be received from the endpoint. If this doesn't happen then you'll see exactly this behavior - we'll send to the IP address and port they told us. There's nothing that Asterisk itself can do in that instance, the endpoint has to send media or place the correct IP address and port in the messages. Was any media received from it? -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org