webrtc client not able to play audio sent from non-webrtc client

[Sheel Patel]

Hi,

I am in process of developing a webrtc gateway. Currently, able to make an audio call successfully between two jssip clients through the gateway.

Although when done between jssip and a soft client (x-lite or linphone) Only one way audio is working (i.e. on x-lite/linphone) the jssip is not able to

play the srtp packets received.

I verified that DTLS-handshake is negotiated successfully. And also verified that the keys used for encryption-decryption is correct on the gateway,

by separately decryption some of the SRTP packet which match to the input RTP from x-lite.

The only deference I see is, addition of,

abs-send-time and extension header RFC-5285 in the SRTP packets sent from jssip/chrome but missing in the SRTP sent towards jssip/chrome client.

Are these mandatory headers? As, there is no debugging logs available on the chrome/jssip side, but following,

WARNING 5176 15172 11:05:40-783 c:\b\build\slave\win\build\src\third_party\webrtc\modules\audio_coding\neteq\packet_buffer.cc 71 Packet buffer flushed

Any help much appreciated!

Thanks,

Sheel

[PhistucK]

Just to make sure, how you used chrome://webrtc-logs/ and chrome://webrtc-internals/ for debugging?

☆PhistucK

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/e6795fc2-4ac5-437c-933c-ac5c57e9f287%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sheel Patel]

Hi, I was not aware of the chrome://webrtc-internals/. I was using --enable-logging --vmodule=*/webrtc/*=2,*/libjingle/*=2,*=-2 --no-sandbox and sawbuck log viewer.

Now, I explored the webrtc-internals and do see received bytes and send bytes in the audio-connections. And generated following files,

<base filename>.<render process ID>.aec_dump.<recording ID>

<base filename>.<render process ID>.source_input.<stream ID>.pcm

How to debug these files and verify that the audio receiving is correct or not? As still there is no audio output from webrtc client.

[Christoffer Jansson]

In chrome://webrtc-internals, do you see the audioInputLevel move at all for the send audio SSRC stat graph?

The diagnostic recording is mainly used for debugging audio processing issues.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/e60a2d2a-5fd4-4dc7-98b7-cd7dd93fe9d0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

/Chris

[Sheel Patel]

Hi Christoffer, 

Yes find attached screen shots.

I am running a loop back call where jssip is generating audio packets and receiving same packets back.

SRTP (decrypted)  -----

                                 |

                                rtp (looping back same packets) 

                                 |

SRTP (encrypted) <----

From the stats I can see I am receiving all the packets back but webrtc client doesn't play any sound.

I also tried to play following files,

<base filename>.<render process ID>.aec_dump.<recording ID> --> which is the speaker output (I guess) does not play clearly but the noise

<base filename>.<render process ID>.source_input.<stream ID>.pcm --> which is the microphone input (I guess) does play a clear audio what is the input.

Also, I did wireshark capture of the SRTP packets received on the jssip side and decrypted using the keys negotiated from the gateway side, and replayed in wireshark and it plays almost clearly as the input.

This proves that the encryption from my media server is correct, but how do I verify whether the chrome is negotiated with the correct keys for SRTP decryption and doing it correctly.

Thanks,

Sheel

[Sheel Patel]

Some more findings.....

I am not able to see diagnostics event logs generated even though I have  enabled it.

When I run jssip to jssip call it is showing the receiver stats too. Find attached

Is use of BUNDLE and SSRC are mandatory for webrtc? I am not negotiating bundle back in the ANSWER SDP to the INVITE received from jssip.

As, I am seeing following warning in the chrome logs,

WARNING 9376 15488 12:09:27-580 c:\b\build\slave\win\build\src\third_party\libjingle\source\talk\app\webrtc\statscollector.cc 934 The SSRC 4181936935 is not associated with a receiving track

WARNING 9376 7216 12:09:28-212 c:\b\build\slave\win\build\src\third_party\webrtc\modules\audio_coding\neteq\packet_buffer.cc 71 Packet buffer flushed

Assuming https://tools.ietf.org/html/draft-ietf-mmusic-msid-13 is still a draft and should be backward compatible.

Thanks,

Sheel

[Christoffer Jansson]

On Fri, Apr 15, 2016 at 9:49 PM Sheel Patel <hots...@gmail.com> wrote:

Some more findings.....

I am not able to see diagnostics event logs generated even though I have  enabled it.

When I run jssip to jssip call it is showing the receiver stats too. Find attached

Is use of BUNDLE and SSRC are mandatory for webrtc? I am not negotiating bundle back in the ANSWER SDP to the INVITE received from jssip.

Please try to use bundle and see if it works, it's not required but recommended. 

AFAIK SSRC is not required for WebRTC (Firefox to Firefox does not use it but Firefox to Chrome does due to Chrome wants it). I do not know if it works without SSRCs in Chrome, what's the reason for not using it?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/c77ae58a-39ff-4c45-828d-ecfcf778c580%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

/Chris

[Sheel Patel]

Hi Christoffer,

I added SSRC attributes in the answer and it is working now.

So, it does not work without SSRC in chrome. I went through some of the rtcweb compliance drafts and it mandates the use of BUNDLE and SSRC, May be I am running single stream audio call it

did not complain about BUNDLE.

https://tools.ietf.org/pdf/draft-ietf-rtcweb-jsep-14.pdf

Unfortunately I did not come across this one before and had to do so many trial and error because of lake of specific error logged by chrome.

This issue normally arise when there is an interworking scenario between webrtc client and normal sip client which does not support SSRC and grouping in the SDP,

As an interworking gateway it has to be taken care separately.

Thanks,

Sheel

[Taylor Brandstetter]

As long as you're only sending one SSRC per audio/video track, it should work even without signaling the SSRCs.

Unless you're using "a=msid-semantic:WMS", because then the PeerConnection expects the endpoint to be capable of signaling SSRCs.

Could you attach an example of the SDP for the answer? I'm curious about what the problem was.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/81eb71d1-acab-445f-b8d8-07a47b9e8c07%40googlegroups.com.

[Sheel Patel]

Hi Taylor, Thanks for your comment. Yes, unfortunately I was sending a=msid-semantic back in the answer without SSRC.

Following is the SDP now after removing it,

v=0

o=- 2005961193 2 IN IP4 10.2.3.65

s=xyz

c=IN IP4 10.2.3.65

t=0 0

a=ice-lite

a=ice-ufrag:jP5EosXa

a=ice-pwd:VO9Y8HC/feAMAzeGl2Z6OtJI

m=audio 6000 UDP/TLS/RTP/SAVPF 0

c=IN IP4 10.2.3.65

a=rtpmap:0 PCMU/8000

a=mid:audio

a=sendrecv

a=setup:active

a=fingerprint:SHA-1 30:83:C3:1B:F5:CB:F4:76:BA:CB:9F:06:EA:AB:24:E0:8A:9F:DE:4A

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=conf:qos remote sendrecv

a=candidate:235 1 UDP 2130706431 10.2.3.65 6000 typ host

a=rtcp:6000 IN IP4 10.2.3.65

a=rtcp-mux

m=video 0 UDP/TLS/RTP/SAVPF 0

a=setup:active

a=fingerprint:SHA-1 30:83:C3:1B:F5:CB:F4:76:BA:CB:9F:06:EA:AB:24:E0:8A:9F:DE:4A

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=conf:qos remote sendrecv

Although when ssrc is not negotiated in SDP, chrome://webrtc-internals/ doesn't show received packet stats.

Thanks,

Sheel