no audio in Chrome when using G.711 / no RTCP
1,010 views
Skip to first unread message
SEN
Nov 21, 2012, 9:55:42 AM11/21/12
to discuss...@googlegroups.com
Hi,
we do have a problem when using G.711 in actual dev version.
Part a is calling part b. Both parts are chrome.
But they comunicate over a voice gateway.
Therefore are 4 RTP streams G.711 are seen in capture file.
All seems to be ok, but on Chrome no audio can be heard?
Browser complains in attached log following:
[4940:1524:1120/141510:VERBOSE1:channel.cc(743)] Failed to unprotect audio RTCP packet: size=92, type=200
[4940:1524:1120/141516:VERBOSE1:channel.cc(743)] Failed to unprotect audio RTCP packet: size=92, type=200
[5372:3932:1120/141522:VERBOSE1:channel.cc(733)] Failed to unprotect audio RTP packet: size=20, seqnum=0, SSRC=1013608503
[5372:3932:1120/141522:VERBOSE1:channel.cc(733)] Failed to unprotect audio RTP packet: size=20, seqnum=0, SSRC=2524082034
Why can't RTCP be decrypted?
Why STUN packets (size=20) are tried to be decoded and handled like RTP?
On gateway side streams can be decrypted.
What is the reason for no Audio?
Before some days it worked, but after an update not longer.
Best regards,
Stefan
Vikas
Nov 21, 2012, 8:11:08 PM11/21/12
to discuss-webrtc
Hi,
It looks like SRTP decryption is failing but i am not sure why. Can
you tell the purpose of voice gateway and what exactly it is doing?
Also if you can add chrome_debug logs for both sides that will be
useful. You can generate by running chrome with "./out/Debug/chrome --
enable-logging --v=1 --vmodule=*libjingle/source/talk/*=3"
You can file these details in issue tracker.
/Vikas
It looks like SRTP decryption is failing but i am not sure why. Can
you tell the purpose of voice gateway and what exactly it is doing?
Also if you can add chrome_debug logs for both sides that will be
useful. You can generate by running chrome with "./out/Debug/chrome --
enable-logging --v=1 --vmodule=*libjingle/source/talk/*=3"
You can file these details in issue tracker.
/Vikas
Plank, Stefan
Nov 22, 2012, 3:53:00 AM11/22/12
to discuss...@googlegroups.com
Hi,
Yes, it seems so, that RTP/RTCP isn't decrypted.
In my test a_part is caling b_part.
A mediaserver between contains a peerconnectionserver, browsers connected to.
The mediaserver get the offer from a_part.
The mediaserver then send a new offer to b_part.
Offer and answer from my side only contains (at moment) G.711.
4 RTP streams are captured and stun is ok.
RTP streams from browsers can be decrypted.
So all looks good (from my side).
Audio from offerer (a part) is in stream - checked.
Audio from answerer (b part) isn't in stream - checked.
Neither on a nor on b side anything is heard.
Hopefully you have an idea what is going wrong.
Best regards,
Stefan
-----Ursprüngliche Nachricht-----
Von: discuss...@googlegroups.com [mailto:discuss...@googlegroups.com] Im Auftrag von Vikas
Gesendet: Donnerstag, 22. November 2012 02:11
An: discuss-webrtc
Betreff: [discuss-webrtc] Re: no audio in Chrome when using G.711 / no RTCP
--
Yes, it seems so, that RTP/RTCP isn't decrypted.
In my test a_part is caling b_part.
A mediaserver between contains a peerconnectionserver, browsers connected to.
The mediaserver get the offer from a_part.
The mediaserver then send a new offer to b_part.
Offer and answer from my side only contains (at moment) G.711.
4 RTP streams are captured and stun is ok.
RTP streams from browsers can be decrypted.
So all looks good (from my side).
Audio from offerer (a part) is in stream - checked.
Audio from answerer (b part) isn't in stream - checked.
Neither on a nor on b side anything is heard.
Hopefully you have an idea what is going wrong.
Best regards,
Stefan
-----Ursprüngliche Nachricht-----
Von: discuss...@googlegroups.com [mailto:discuss...@googlegroups.com] Im Auftrag von Vikas
Gesendet: Donnerstag, 22. November 2012 02:11
An: discuss-webrtc
Betreff: [discuss-webrtc] Re: no audio in Chrome when using G.711 / no RTCP
Plank, Stefan
Nov 23, 2012, 7:03:03 AM11/23/12
to discuss...@googlegroups.com
Hi,
Yes, decrypting failed.
I found the reason. It was a missing ssrc attribute in offer/answer.
Unfortunately chrome hasn't logged a warning.
Now there is a full audio connection between a_part and b_part.
But still RTCP isn't working. This never worked before.
[400:4088:1123/112612:ERROR:audio_unified_win.cc(410)] NOT IMPLEMENTED
[1316:904:1123/112613:VERBOSE1:channel.cc(743)] Failed to unprotect audio RTCP packet: size=92, type=200
I added requested files and I hope you can help me.
>In my test a_part is calling b_part.
>A media server between contains a peerconnectionserver, browsers connected to.
>The media server get the offer from a_part.
>The media server then send a new offer to b_part.
--
Yes, decrypting failed.
I found the reason. It was a missing ssrc attribute in offer/answer.
Unfortunately chrome hasn't logged a warning.
Now there is a full audio connection between a_part and b_part.
But still RTCP isn't working. This never worked before.
[400:4088:1123/112612:ERROR:audio_unified_win.cc(410)] NOT IMPLEMENTED
[1316:904:1123/112613:VERBOSE1:channel.cc(743)] Failed to unprotect audio RTCP packet: size=92, type=200
I added requested files and I hope you can help me.
>In my test a_part is calling b_part.
>A media server between contains a peerconnectionserver, browsers connected to.
>The media server get the offer from a_part.
>The media server then send a new offer to b_part.
>Offer and answer from my side only contains (at moment) G.711.
Best regards,
Stefan
-----Ursprüngliche Nachricht-----
Von: discuss...@googlegroups.com [mailto:discuss...@googlegroups.com] Im Auftrag von Vikas
Gesendet: Donnerstag, 22. November 2012 02:11
An: discuss-webrtc
Betreff: [discuss-webrtc] Re: no audio in Chrome when using G.711 / no RTCP
Stefan
-----Ursprüngliche Nachricht-----
Von: discuss...@googlegroups.com [mailto:discuss...@googlegroups.com] Im Auftrag von Vikas
Gesendet: Donnerstag, 22. November 2012 02:11
An: discuss-webrtc
Betreff: [discuss-webrtc] Re: no audio in Chrome when using G.711 / no RTCP
Justin Uberti
Nov 29, 2012, 6:20:49 PM11/29/12
to discuss-webrtc
Are you sure that the remote side is using the same keying material for both RTP and RTCP?
RTCP decryption works properly in our basic samples, e.g. pc1.html.
--
Plank, Stefan
Nov 30, 2012, 8:24:53 AM11/30/12
to discuss...@googlegroups.com
Hello Justin,
yes, we took the key contained in SDP for RTP and RTCP.
RTP works but not RTCP.
On our side and in browser log we can see, decryption failed.
From our point it looks, the browser teak different keys for RTP and RTCP.
Best regards,
Stefan
Von: discuss...@googlegroups.com [mailto:discuss...@googlegroups.com] Im Auftrag von Justin Uberti
Gesendet: Freitag, 30. November 2012 00:21
An: discuss-webrtc
Betreff: Re: [discuss-webrtc] Re: no audio in Chrome when using G.711 / no RTCP
--
Sergio Garcia Murillo
Nov 30, 2012, 8:27:51 AM11/30/12
to discuss...@googlegroups.com
Hi Stefan,
From my experience RTCP is correctly encrypted by chrome using the same keys/algo than RTP. Tested it against my own media server.
Best regards
Sergio
From my experience RTCP is correctly encrypted by chrome using the same keys/algo than RTP. Tested it against my own media server.
Best regards
Sergio
--
Harald Alvestrand
Nov 30, 2012, 9:56:39 AM11/30/12
to discuss...@googlegroups.com
Where does your encryption code come from?
If I remember rightly, RTCP is supposed to be encrypted with a
different key than RTP, but derived from the same master key (RFC 3711
section 4.3.2).
(using the same key for both would lead to a two-time pad)
> --
>
>
>
If I remember rightly, RTCP is supposed to be encrypted with a
different key than RTP, but derived from the same master key (RFC 3711
section 4.3.2).
(using the same key for both would lead to a two-time pad)
>
>
>
Plank, Stefan
Dec 7, 2012, 4:07:15 AM12/7/12
to discuss...@googlegroups.com
We analyzed SRTCP streams and saw following.
Offerer sends two crypto attributes with auth length 32 and 80.
Answerer sends only one with auth length 32.
So we took auth length 32 for both directions.
As mentioned RTP is working well.
RTCP sent to offerer (chrome) has auth length 32.
But offerer (chrome) send RTCP packets with auth length 80!?
Decrypting therefore fail.
This seems to be a failure in chrome.
Attached cap file with SRTCP packets (Offerer 10.35.13.1 to mediaserver 10.35.13.2)
Why does offerer send RTCP with auth length 80 and RTP with 32?
Why does answerer not answer with two crypto (80 and 32) too?
Why does answerer not have candidates for RTCP?
Why is RCTP attribute from answerer a=rtcp:1 IN IP4 0.0.0.0?
Best regards,
Stefan
-----Ursprüngliche Nachricht-----
Von: discuss...@googlegroups.com [mailto:discuss...@googlegroups.com] Im Auftrag von Harald Alvestrand
Gesendet: Freitag, 30. November 2012 15:57
An: discuss...@googlegroups.com
Betreff: Re: [discuss-webrtc] Re: no RTCP
--
Offerer sends two crypto attributes with auth length 32 and 80.
Answerer sends only one with auth length 32.
So we took auth length 32 for both directions.
As mentioned RTP is working well.
RTCP sent to offerer (chrome) has auth length 32.
But offerer (chrome) send RTCP packets with auth length 80!?
Decrypting therefore fail.
This seems to be a failure in chrome.
Attached cap file with SRTCP packets (Offerer 10.35.13.1 to mediaserver 10.35.13.2)
Why does offerer send RTCP with auth length 80 and RTP with 32?
Why does answerer not answer with two crypto (80 and 32) too?
Why does answerer not have candidates for RTCP?
Why is RCTP attribute from answerer a=rtcp:1 IN IP4 0.0.0.0?
Best regards,
Stefan
-----Ursprüngliche Nachricht-----
Gesendet: Freitag, 30. November 2012 15:57
An: discuss...@googlegroups.com
Betreff: Re: [discuss-webrtc] Re: no RTCP
Justin Uberti
Dec 7, 2012, 7:15:16 PM12/7/12
to discuss-webrtc
RTCP auth length is always 80, even if RTP auth length is 32.
--
Plank, Stefan
Dec 10, 2012, 2:41:22 AM12/10/12
to discuss...@googlegroups.com
Wow, thanks a lot for that hint!
Can you tell me something about how answerer is reacting?
e.g.
no candidates for RTCP and curious RTCP attribute?
Best Regards,
Stefan
Gesendet: Samstag, 8. Dezember 2012 01:15
An: discuss-webrtc
Betreff: Re: [discuss-webrtc] Re: no RTCP
An: discuss-webrtc
Betreff: Re: [discuss-webrtc] Re: no RTCP
--
Justin Uberti
Dec 10, 2012, 10:17:34 PM12/10/12
to discuss-webrtc
There are no RTCP candidates from the answerer because RTCP mux is used (a=rtcp-mux).
--
Nick Foster
Dec 10, 2012, 10:31:52 PM12/10/12
to discuss...@googlegroups.com
Not sure that I totally follow that. But I added that as a trial, I have the same experience with it removed.
--
Justin Uberti
Dec 10, 2012, 10:37:41 PM12/10/12
to discuss-webrtc
That should not be the case. Can you paste in your offer and answer SDP?
--
Nick Foster
Dec 10, 2012, 11:03:11 PM12/10/12
to discuss...@googlegroups.com
Commuting home. Can do in about 30 mins
--
Justin Uberti
Dec 11, 2012, 12:00:34 AM12/11/12
to discuss-webrtc
I think your issue is something else. In your answer SDP, I do see RTCP candidates (component=2):
a=candidate:Hac58b8d 1 udp 2130706431 10.197.139.141 16988 typ host
a=candidate:H6c3b5c27 1 udp 2130706431 108.59.92.39 16988 typ host
a=candidate:Hac58b8d 2 udp 2130706430 10.197.139.141 16989 typ host
a=candidate:H6c3b5c27 2 udp 2130706430 108.59.92.39 16989 typ host
--
Plank, Stefan
Dec 11, 2012, 3:15:12 AM12/11/12
to discuss...@googlegroups.com
Hi, no candidates with component id 2 in answer due to a=rtcp-mux? Is this ok?
Have you an reason for
a=rtcp:1 IN IP4 0.0.0.0 and only
one key with 32 bit auth length?
See my SDP from offerer and answerer (both chrome)
See my SDP from offerer and answerer (both chrome)
v=0
o=- 3068400342 3 IN IP4 127.0.0.1
s=OFFERER
o=- 3068400342 3 IN IP4 127.0.0.1
s=OFFERER
t=0 0
a=group:BUNDLE audio
m=audio 59432 RTP/SAVPF 103 104 111 0 8 107 106 105 13 126
c=IN IP4 162.28.129.205
a=rtcp:59432 IN IP4 162.28.129.205
a=candidate:2817821791 1 udp 2113937151 10.35.13.1 59435 typ host generation 0
a=candidate:2817821791 2 udp 2113937151 10.35.13.1 59435 typ host generation 0
a=ice-ufrag:lCHqWBw5icIEcyvt
a=ice-pwd:kp8fZTGCVPU9HQWWtjvksIcH
a=ice-options:google-ice
a=sendrecv
a=mid:audio
a=rtcp-mux
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:wPt48A6P6rHST2qtiL3E6bo2IHNWkhYjSQhj21FN
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:3zydp+Fz3MPlknPdVLx4bZsG7n1djP5F68TSZl9P
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:111 opus/48000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:107 CN/48000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=ssrc:1764917052 cname:LejGqotoOcqm4j0o
a=ssrc:1764917052 msid:yVJBTKN8g1dxElZFsMLeBFbt97Vb4jXDJhP6 a0
a=ssrc:1764917052 mslabel:yVJBTKN8g1dxElZFsMLeBFbt97Vb4jXDJhP6
a=ssrc:1764917052 label:yVJBTKN8g1dxElZFsMLeBFbt97Vb4jXDJhP6a0
a=group:BUNDLE audio
m=audio 59432 RTP/SAVPF 103 104 111 0 8 107 106 105 13 126
c=IN IP4 162.28.129.205
a=rtcp:59432 IN IP4 162.28.129.205
a=candidate:2817821791 1 udp 2113937151 10.35.13.1 59435 typ host generation 0
a=candidate:2817821791 2 udp 2113937151 10.35.13.1 59435 typ host generation 0
a=ice-ufrag:lCHqWBw5icIEcyvt
a=ice-pwd:kp8fZTGCVPU9HQWWtjvksIcH
a=ice-options:google-ice
a=sendrecv
a=mid:audio
a=rtcp-mux
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:wPt48A6P6rHST2qtiL3E6bo2IHNWkhYjSQhj21FN
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:3zydp+Fz3MPlknPdVLx4bZsG7n1djP5F68TSZl9P
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:111 opus/48000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:107 CN/48000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=ssrc:1764917052 cname:LejGqotoOcqm4j0o
a=ssrc:1764917052 msid:yVJBTKN8g1dxElZFsMLeBFbt97Vb4jXDJhP6 a0
a=ssrc:1764917052 mslabel:yVJBTKN8g1dxElZFsMLeBFbt97Vb4jXDJhP6
a=ssrc:1764917052 label:yVJBTKN8g1dxElZFsMLeBFbt97Vb4jXDJhP6a0
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
v=0
o=- 3143123538 3 IN IP4 127.0.0.1
s=ANSWERER
o=- 3143123538 3 IN IP4 127.0.0.1
s=ANSWERER
t=0 0
a=group:BUNDLE audio
m=audio 61064 RTP/SAVPF 0 8
c=IN IP4 10.35.12.1
a=rtcp:1 IN IP4 0.0.0.0
a=candidate:1822973946 1 udp 2113937151 10.35.12.1 61064 typ host generation 0
a=ice-ufrag:r1epgb115J/jRFS0
a=ice-pwd:BUFz3Fe4m0VdHX8xF7U7SXXT
a=sendrecv
a=mid:audio
a=rtcp-mux
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:071Wqqdn81i6+EHKsd6exd/c7Dt7fUYguy9+QHRk
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=ssrc:503452348 cname:dsQQUmH1TIesU6VQ
a=ssrc:503452348 msid:Wk3noEYYIXerPAcOjLcygUqryDDU7iUEeYW1 a0
a=ssrc:503452348 mslabel:Wk3noEYYIXerPAcOjLcygUqryDDU7iUEeYW1
a=ssrc:503452348 label:Wk3noEYYIXerPAcOjLcygUqryDDU7iUEeYW1a0
a=group:BUNDLE audio
m=audio 61064 RTP/SAVPF 0 8
c=IN IP4 10.35.12.1
a=rtcp:1 IN IP4 0.0.0.0
a=candidate:1822973946 1 udp 2113937151 10.35.12.1 61064 typ host generation 0
a=ice-ufrag:r1epgb115J/jRFS0
a=ice-pwd:BUFz3Fe4m0VdHX8xF7U7SXXT
a=sendrecv
a=mid:audio
a=rtcp-mux
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:071Wqqdn81i6+EHKsd6exd/c7Dt7fUYguy9+QHRk
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=ssrc:503452348 cname:dsQQUmH1TIesU6VQ
a=ssrc:503452348 msid:Wk3noEYYIXerPAcOjLcygUqryDDU7iUEeYW1 a0
a=ssrc:503452348 mslabel:Wk3noEYYIXerPAcOjLcygUqryDDU7iUEeYW1
a=ssrc:503452348 label:Wk3noEYYIXerPAcOjLcygUqryDDU7iUEeYW1a0
Gesendet: Dienstag, 11. Dezember 2012 06:01
--
Justin Uberti
Dec 11, 2012, 10:45:54 PM12/11/12
to discuss-webrtc
Yes, this is normal operation, the SRTP answer should only include the chosen crypto-suite. See http://tools.ietf.org/html/rfc4568#section-5.1.2
--
Reply all
Reply to author
Forward
0 new messages