[asterisk-users] One Way Audio with WebRTC (with external asterisk)
Gary Shergill
gshergill at gltd.net
Thu May 22 04:34:14 CDT 2014
Hi Amit,
My rtp.conf has the stunaddr listed and icesupport set to yes.
It looks like the issue is that the media isn't being sent from 192.168.3.150 to 192.168.3.131 (chrome browser to asteriskrtc.local).
When using asteriskrtc.local to originate the call (make a call directly from sipml client to another number on asteriskrtc.local or to a number on another asterisk server) audio flows both ways with no issue, it's just when asteriskgary.local is originating the call that there is no audio flowing from chrome to asteriskrtc.local.
I should probably rephrase the above though to say that on tshark I can actually see the packets flowing (tshark host 192.168.3.150):
2.384874 192.168.3.150 -> 192.168.3.131 STUN 174 Binding Request user: 15bd74963e5dcabb5eda052841431514:EnntMcdgY8Rm17Ik
2.384925 192.168.3.150 -> 192.168.3.131 STUN 174 Binding Request user: 15bd74963e5dcabb5eda052841431514:EnntMcdgY8Rm17Ik
2.385060 192.168.3.131 -> 192.168.3.150 STUN 122 Binding Success Response XOR-MAPPED-ADDRESS: 192.168.3.150:60175
2.385256 192.168.3.131 -> 192.168.3.150 STUN 122 Binding Success Response XOR-MAPPED-ADDRESS: 192.168.3.150:65021
2.394891 192.168.3.131 -> 192.168.3.150 UDP 224 Source port: 16514 Destination port: 65021
2.415195 192.168.3.131 -> 192.168.3.150 UDP 224 Source port: 16514 Destination port: 65021
2.434063 192.168.3.150 -> 192.168.3.131 STUN 174 Binding Request user: 15bd74963e5dcabb5eda052841431514:EnntMcdgY8Rm17Ik
2.434121 192.168.3.150 -> 192.168.3.131 STUN 174 Binding Request user: 15bd74963e5dcabb5eda052841431514:EnntMcdgY8Rm17Ik
2.434296 192.168.3.131 -> 192.168.3.150 STUN 122 Binding Success Response XOR-MAPPED-ADDRESS: 192.168.3.150:60175
2.434462 192.168.3.131 -> 192.168.3.150 STUN 122 Binding Success Response XOR-MAPPED-ADDRESS: 192.168.3.150:65021
2.435083 192.168.3.131 -> 192.168.3.150 UDP 224 Source port: 16514 Destination port: 65021
2.455310 192.168.3.131 -> 192.168.3.150 UDP 224 Source port: 16514 Destination port: 65021
2.475009 192.168.3.131 -> 192.168.3.150 UDP 224 Source port: 16514 Destination port: 65021
Thanks again for your time!
Kind Regards,
Gary Shergill
----- Original Message -----
From: "Amit Patkar" <amit at avhan.com>
To: asterisk-users at lists.digium.com
Sent: Wednesday, May 21, 2014 4:55:57 PM
Subject: Re: [asterisk-users] One Way Audio with WebRTC (with external asterisk)
Please check rtp.conf
Look for stunaddr setting. You can try with google STUN server
stunaddr = stun.l.google.com:19302
Thanks & Regards,
Amit Patkar
On 5/21/2014 9:13 PM, Gary Shergill wrote:
Hi again,
Just noticed this is being sent to the wrong thread... first time using a mailing list and I just replied to the mail sent by the mailing list for Amit's reply. Hope this time it works...
Anyway, I have audio from 1000 to 6901 working, that was a mistake on my side (I tested using the SIPml demo site and it worked, then realised I was missing a setting).
However, the issue still remains where 1000 can not always hear 6901. As mentioned before, this works only SOMETIMES, and when it does work asteriskgary.local sees RTP packets coming FROM 192.168.3.131 (asteriskrtc.local).
Unsure what would be causing this, because it does work sometimes and doesn't at others, with no obvious reason either way.
Thanks again.
Kind Regards,
Gary Shergill
----- Original Message -----
From: "Gary Shergill" <gshergill at gltd.net> To: "Asterisk Users Mailing List - Non-Commercial Discussion" <asterisk-users at lists.digium.com> Sent: Wednesday, May 21, 2014 3:36:54 PM
Subject: Re: [asterisk-users] One Way Audio with WebRTC (with external asterisk)
Hi Amit,
ICE/STUN is configured correctly. The extension for the webrtc user is defined in sip.conf on the asteriskrtc.local server. The other user is defined in Elastix.
I have "directmedia=no" set for the user on asteriskrtc.local.
My exact setup/scenario is below:
- asteriskgary.local has a route to dial extensions on my Elastix server.
- asteriskgary.local has a route to dial extensions on asteriskrtc.local server.
- The call is being originated from asteriskgary.local. The first party is an extension on asteriskgary.local, the destination party is an extension on my Elastix server.
What's happening is as follows (this is a reverse of the previous case as 6901 is now dialling 1000):
- User on asteriskgary.local places a call to 1000, his number is 6901
- 6901 answers on the web browser and begins to dial 1000
- 1000 answers and the call is established correctly
- SOMETIMES 1000 can hear 6901. Other times he can not (seems to be random...)
- 6901 can NEVER hear 1000
key:
192.168.3.127 - asteriskgary.local
192.168.3.131 - asteriskrtc.local
192.168.3.150 - machine running chrome browser where 6901 is logged on
192.168.3.100 - phone where 1000 is logged on
(1000 can hear 6901) RTP TRACE ON asteriskrtc.local
....
Got RTP packet from 192.168.3.150:55148 (type 00, seq 014308, ts 2304496631, len 000160)
Sent RTP packet to 192.168.3.127:15942 (type 00, seq 054709, ts 2304496624, len 000160)
> 0x7fe73c021740 -- Probation passed - setting RTP source address to 192.168.3.127:15942
Got RTP packet from 192.168.3.127:15942 (type 00, seq 003763, ts 000160, len 000160)
Sent RTP packet to 192.168.3.150:55148 (via ICE) (type 00, seq 047008, ts 000160, len 4294967284)
Got RTP packet from 192.168.3.150:55148 (type 00, seq 014309, ts 2304496791, len 000160)
Sent RTP packet to 192.168.3.127:15942 (type 00, seq 054710, ts 2304496784, len 000160)
Got RTP packet from 192.168.3.150:55148 (type 00, seq 014310, ts 2304496951, len 000160)
Sent RTP packet to 192.168.3.127:15942 (type 00, seq 054711, ts 2304496944, len 000160)
Got RTP packet from 192.168.3.127:15942 (type 00, seq 003764, ts 000320, len 000160)
Sent RTP packet to 192.168.3.150:55148 (via ICE) (type 00, seq 047009, ts 000320, len 4294967284)
Got RTP packet from 192.168.3.150:55148 (type 00, seq 014311, ts 2304497111, len 000160)
Sent RTP packet to 192.168.3.127:15942 (type 00, seq 054712, ts 2304497104, len 000160)
Got RTP packet from 192.168.3.127:15942 (type 00, seq 003765, ts 000480, len 000160)
Sent RTP packet to 192.168.3.150:55148 (via ICE) (type 00, seq 047010, ts 000480, len 4294967284)
....
(1000 can hear 6901) RTP TRACE ON asteriskgary.local
...
Got RTP packet from 192.168.3.131:17836 (type 00, seq 055375, ts 2304603184, len 000160)
Sent RTP packet to 192.168.3.131:17836 (type 00, seq 004428, ts 106560, len 000160)
Got RTP packet from 192.168.3.131:17836 (type 00, seq 055376, ts 2304603344, len 000160)
Sent RTP packet to 192.168.3.131:17836 (type 00, seq 004429, ts 106720, len 000160)
Got RTP packet from 192.168.3.131:17836 (type 00, seq 055377, ts 2304603504, len 000160)
Sent RTP packet to 192.168.3.131:17836 (type 00, seq 004430, ts 106880, len 000160)
Got RTP packet from 192.168.3.131:17836 (type 00, seq 055378, ts 2304603664, len 000160)
Sent RTP packet to 192.168.3.131:17836 (type 00, seq 004431, ts 107040, len 000160)
...
(no audio) RTP TRACE ON asteriskrtc.local
....
Got RTP packet from 192.168.3.127:17796 (type 00, seq 035016, ts 000640, len 000160)
Sent RTP packet to 192.168.3.150:53684 (via ICE) (type 00, seq 060981, ts 000640, len 4294967284)
Got RTP packet from 192.168.3.127:17796 (type 00, seq 035017, ts 000800, len 000160)
Sent RTP packet to 192.168.3.150:53684 (via ICE) (type 00, seq 060982, ts 000800, len 4294967284)
Got RTP packet from 192.168.3.127:17796 (type 00, seq 035018, ts 000960, len 000160)
Sent RTP packet to 192.168.3.150:53684 (via ICE) (type 00, seq 060983, ts 000960, len 4294967284)
Got RTP packet from 192.168.3.127:17796 (type 00, seq 035019, ts 001120, len 000160)
Sent RTP packet to 192.168.3.150:53684 (via ICE) (type 00, seq 060984, ts 001120, len 4294967284)
Got RTP packet from 192.168.3.127:17796 (type 00, seq 035020, ts 001280, len 000160)
Sent RTP packet to 192.168.3.150:53684 (via ICE) (type 00, seq 060985, ts 001280, len 4294967284)
....
(no audio) RTP TRACE ON asteriskgary.local
...
Sent RTP packet to 192.168.3.131:16116 (type 00, seq 035355, ts 054880, len 000160)
Sent RTP packet to 192.168.3.131:16116 (type 00, seq 035356, ts 055040, len 000160)
Sent RTP packet to 192.168.3.131:16116 (type 00, seq 035357, ts 055200, len 000160)
Sent RTP packet to 192.168.3.131:16116 (type 00, seq 035358, ts 055360, len 000160)
...
SIP.conf
[6901]
type=peer
username=6901
host=dynamic
secret=6901
qualify=yes
context=webrtc
hasiax = no
hassip = yes
encryption = yes
avpf = yes
icesupport = yes
videosupport=no
directmedia=no
canreinvite=no
You can see from the trace packets that sometimes asteriskgary.local sees no packets from asteriskrtc.local, and at the same time the packets on asteriskrtc.local show half the number of records (there is no "Probation passed - setting RTP source address to 192.168.3.127:15942 which causes twice the number of packets, no idea if this is relevant though).
Please ask if you need anything else. I'm totally stumped with this issue... Note that on asteriskgary.local ICE is not configured, I wouldn't have though it would need it as it isn't talking with the webrtc client itself, it is just talking to an Asterisk server (and that asterisk server is the one which talks to the webrtc client).
Thank you.
Kind Regards,
Gary Shergill
----- Original Message -----
From: "Amit Patkar" <amit at avhan.com> To: asterisk-users at lists.digium.com Sent: Wednesday, May 21, 2014 04:41:50 AM
Subject: Re: [asterisk-users] One Way Audio with WebRTC (with external asterisk)
Hi Gary
You need to check if ICE / STUN is configured.
How are these extensions configured? If you are in private network, you
might have to disable DirectMedia / reInvite for calls going between 2
asterisk boxes.
I hope this helps to resolve your issue.
*Thanks & Regards,*
Amit Patkar
On 5/21/2014 2:26 PM, Gary Shergill wrote:
Hi,
I've run into a slight issue when using WebRTC and two Asterisk boxes.
I am using SIPml as the test WebRTC client.
My two asterisk boxes, one of them is configured for WebRTC with websockets, etc (asteriskrtc.local) and the other is just a standard asterisk server (asteriskgary.local).
Dealing with just the WebRTC asterisk server, asteriskrtc.local, I am able to log in to the SIPml webpage and make a call from a SIP Phone to that WebRTC user, and vice versa, and all the media flows.
When I try making a call from the other asterisk server (asteriskgary.local) to asteriskrtc.local (all routes are set up) I am seeing the following behaviour:
- asteriskgary.local user, 1000, dials asteriskrtc.local number, 6901
- 6901 sees the call and has the option to answer
- 6901 answers the call
- 6901 can hear 1000 talking
- 1000 can not hear 6901
The weird thing is, sometimes it works, sometimes it doesn't...
I think it has something to do with the port destination changing when the call is answered but I'm not sure (wireshark suggests that, as it says "Port Unreachable").
Has anyone tried this before and seen this issue? Or knows why it is and how to debug it? I can provide any logs required, I have some logs from when it works and doesn't.
Thank you for your help.
Kind Regards,
Gary Shergill
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
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