One way audio case between FS and Chrome on WebRTC.
Hello, I am trying to validate FS as a SIP to WebRTC Gateway in our lab environment. I started in middle October and cannot understand this One Way Audio trouble. I must thank the Freeswitch team and contributors for this very impressive work. FreeSWITCH Version 1.8.1-2-4f54cff36a~64bit (-2-4f54cff36a 64bit) On system: SMP Debian 4.9.110-3+deb9u6 (2018-10-08) x86_64 GNU/Linux Openssl version : OpenSSL 1.1.0f 25 May 2017 Chrome version: 69.0 (I tried with different version and with Firefox with the same trouble). The wss part is ok with sip.js and verto.js The Ice negotiation is ok, I use sometimes local networks and sometimes web, I have had to authorize networks in the candidate ACL and domain ACL (acl.conf.xml) The result is the same on both topology. DTLS negotiation is OK, and there is UDP streams between Chrome (or Firefox) and FS in both ways. There is no audio in the direction from FS to Chrome, the other direction is OK. The simplest test is to call the 5000 number from the Chrome client, I send you a paste bin and pcap trace for this call. Should you give me information element to progress on this, what is really mandatory in the sip_profile/internal.xml and external.xml files, and in directory/default/1000.xml for a WebRTC call ?? What should be the good options in fs_cli to see if the encryption of RTP packets is ok or not.. ? Do you think that I have to reinstall a Freeswitch from the current branch ? @IP for FS : 192.168.145.67 @IP for Chrome : 10.70.54.43 Link on the pastebin : https://pastebin.freeswitch.org/view/09a72087 The pcap trace joined is done on Freeswitch on the same call. Thank you for helping me !! Best regards. [Prosodie-signature]<http://www.prosodie.com/> Rémi Marand - Product Owner - Pod Connect. PROSODIE - Marketing & Produit Tél. : +33 (0)1.46.84.12.77 / 06.87.72.53.25 rmarand@prosodie.com<mailto:rmarand@prosodie.com> This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Hi, Have you tried disabling STUN? Does it work in the same LAN? There are many "Sending RTCP NACK" lines in your logs, meaning that fsw is not receiving all the RTP from your endpoint. It may be related to the stun or you may need to check your network. Hope this helps. Best Regards, -- Vallimamod Abdullah SIP Solutions vma@sipsolutions.fr linkedin.com/in/vallimamod .
On 5 Nov 2018, at 16:46, MARAND, Remi <rmarand@prosodie.com> wrote:
Hello,
I am trying to validate FS as a SIP to WebRTC Gateway in our lab environment. I started in middle October and cannot understand this One Way Audio trouble.
I must thank the Freeswitch team and contributors for this very impressive work.
FreeSWITCH Version 1.8.1-2-4f54cff36a~64bit (-2-4f54cff36a 64bit) On system: SMP Debian 4.9.110-3+deb9u6 (2018-10-08) x86_64 GNU/Linux Openssl version : OpenSSL 1.1.0f 25 May 2017 Chrome version: 69.0 (I tried with different version and with Firefox with the same trouble).
The wss part is ok with sip.js and verto.js
The Ice negotiation is ok, I use sometimes local networks and sometimes web, I have had to authorize networks in the candidate ACL and domain ACL (acl.conf.xml) The result is the same on both topology.
DTLS negotiation is OK, and there is UDP streams between Chrome (or Firefox) and FS in both ways.
There is no audio in the direction from FS to Chrome, the other direction is OK.
The simplest test is to call the 5000 number from the Chrome client, I send you a paste bin and pcap trace for this call.
Should you give me information element to progress on this, what is really mandatory in the sip_profile/internal.xml and external.xml files, and in directory/default/1000.xml for a WebRTC call ?? What should be the good options in fs_cli to see if the encryption of RTP packets is ok or not.. ? Do you think that I have to reinstall a Freeswitch from the current branch ?
@IP for FS : 192.168.145.67 @IP for Chrome : 10.70.54.43
Link on the pastebin : https://pastebin.freeswitch.org/view/09a72087
The pcap trace joined is done on Freeswitch on the same call.
Thank you for helping me !! Best regards.
<image001.gif>
Rémi Marand – Product Owner – Pod Connect. PROSODIE – Marketing & Produit Tél. : +33 (0)1.46.84.12.77 / 06.87.72.53.25 rmarand@prosodie.com
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
<Pros7cMon4.pcap>_________________________________________________________________________ Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
Hi, We got exaclty the same issue with latest Verto js library. This work with latest Verto communicator. Our developer edited verto lib to fix this issue. I'll ask him tomorrow which modifications he did. Alexis Le 08/11/2018 à 10:10, Vallimamod Abdullah a écrit :
Hi,
Have you tried disabling STUN? Does it work in the same LAN?
There are many "Sending RTCP NACK" lines in your logs, meaning that fsw is not receiving all the RTP from your endpoint. It may be related to the stun or you may need to check your network.
Hope this helps.
Best Regards,
participants (3)
-
Alexis
-
MARAND, Remi
-
Vallimamod Abdullah