Re: Failed to unprotect audio/video RTCP ERRS on latest canary

Anthony Minessale

unread,

Jan 17, 2013, 5:46:47 PM1/17/13

to discuss...@googlegroups.com

I implemented rtcp-mux and the errors stopped. Looks like a bug in tolerating a response with regular non-muxed rtcp.

On Wednesday, January 16, 2013 12:39:11 AM UTC-6, Anthony Minessale wrote:

Hi,

I am seeing srtp decrypt errors only on RTCP in extended logging for both audio and video but on the outside everything is working:
Any insight?

[398:-1289560064:0116/001533:VERBOSE1:channel.cc(800)] Failed to unprotect video RTCP packet: size=90, type=200
[398:-1289560064:0116/001533:VERBOSE1:channel.cc(800)] Failed to unprotect video RTCP packet: size=90, type=200
[398:-1289560064:0116/001534:VERBOSE1:channel.cc(800)] Failed to unprotect video RTCP packet: size=90, type=200
[398:-1289560064:0116/001534:VERBOSE1:channel.cc(800)] Failed to unprotect video RTCP packet: size=90, type=200
[398:-1289560064:0116/001535:VERBOSE1:channel.cc(800)] Failed to unprotect video RTCP packet: size=90, type=200
[398:-1289560064:0116/001535:VERBOSE1:channel.cc(800)] Failed to unprotect audio RTCP packet: size=90, type=201
[398:-1289560064:0116/001535:VERBOSE1:channel.cc(800)] Failed to unprotect video RTCP packet: size=90, type=200
[398:-1289560064:0116/001535:VERBOSE1:channel.cc(800)] Failed to unprotect video RTCP packet: size=90, type=200

I tried to pull chrome svn to debug but the one I found has those lines at 754.
From the looks of it I am using the srtp lib the same exact way....At least as far as I can tell from reading libjingle code.

OFFER:
============
v=0
o=- 1896834151 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS t8CNFmyJQrnl4oHi9j0PEilZbDurviQfbJMB
m=audio 36790 RTP/SAVPF 103 104 111 0 8 107 106 105 13 126
c=IN IP4 222.222.222.222
a=rtcp:36790 IN IP4 222.222.222.222
a=candidate:90380972 1 udp 2113937151 192.168.2.1 51161 typ host generation 0
a=candidate:90380972 2 udp 2113937151 192.168.2.1 51161 typ host generation 0
a=candidate:3405893845 1 udp 2113937151 10.0.1.22 64506 typ host generation 0
a=candidate:3405893845 2 udp 2113937151 10.0.1.22 64506 typ host generation 0
a=candidate:189729040 1 udp 2113937151 169.254.41.222 58834 typ host generation 0
a=candidate:189729040 2 udp 2113937151 169.254.41.222 58834 typ host generation 0
a=candidate:1217027821 1 udp 2113937151 192.168.82.1 62605 typ host generation 0
a=candidate:1217027821 2 udp 2113937151 192.168.82.1 62605 typ host generation 0
a=candidate:1548745779 1 udp 2113937151 192.168.231.1 53621 typ host generation 0
a=candidate:1548745779 2 udp 2113937151 192.168.231.1 53621 typ host generation 0
a=candidate:2307665501 1 udp 1845501695 222.222.222.222 36790 typ srflx raddr 10.0.1.22 rport 64506 generation 0
a=candidate:2307665501 2 udp 1845501695 222.222.222.222 36790 typ srflx raddr 10.0.1.22 rport 64506 generation 0
a=candidate:1273030236 1 tcp 1509957375 192.168.2.1 49435 typ host generation 0
a=candidate:1273030236 2 tcp 1509957375 192.168.2.1 49435 typ host generation 0
a=candidate:2239900709 1 tcp 1509957375 10.0.1.22 49436 typ host generation 0
a=candidate:2239900709 2 tcp 1509957375 10.0.1.22 49436 typ host generation 0
a=candidate:1171060192 1 tcp 1509957375 169.254.41.222 49437 typ host generation 0
a=candidate:1171060192 2 tcp 1509957375 169.254.41.222 49437 typ host generation 0
a=candidate:101294621 1 tcp 1509957375 192.168.82.1 49438 typ host generation 0
a=candidate:101294621 2 tcp 1509957375 192.168.82.1 49438 typ host generation 0
a=candidate:315359427 1 tcp 1509957375 192.168.231.1 49439 typ host generation 0
a=candidate:315359427 2 tcp 1509957375 192.168.231.1 49439 typ host generation 0
a=ice-ufrag:iYXgKsUK8T05FLQV
a=ice-pwd:9nlvJbkhAWW5pIXNcsG1FhuA
a=ice-options:google-ice
a=sendrecv
a=mid:audio
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:dkTRiMIaXZ3bddNxiVnX7gjMl9YDiNmI4xF77Nbs
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:111 opus/48000/2
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:3178731743 cname:h6qCbiYzqBxsxi1k
a=ssrc:3178731743 msid:t8CNFmyJQrnl4oHi9j0PEilZbDurviQfbJMB a0
a=ssrc:3178731743 mslabel:t8CNFmyJQrnl4oHi9j0PEilZbDurviQfbJMB
a=ssrc:3178731743 label:t8CNFmyJQrnl4oHi9j0PEilZbDurviQfbJMBa0
m=video 36790 RTP/SAVPF 100 116 117
c=IN IP4 222.222.222.222
a=rtcp:36790 IN IP4 222.222.222.222
a=candidate:90380972 1 udp 2113937151 192.168.2.1 51161 typ host generation 0
a=candidate:90380972 2 udp 2113937151 192.168.2.1 51161 typ host generation 0
a=candidate:3405893845 1 udp 2113937151 10.0.1.22 64506 typ host generation 0
a=candidate:3405893845 2 udp 2113937151 10.0.1.22 64506 typ host generation 0
a=candidate:189729040 1 udp 2113937151 169.254.41.222 58834 typ host generation 0
a=candidate:189729040 2 udp 2113937151 169.254.41.222 58834 typ host generation 0
a=candidate:1217027821 1 udp 2113937151 192.168.82.1 62605 typ host generation 0
a=candidate:1217027821 2 udp 2113937151 192.168.82.1 62605 typ host generation 0
a=candidate:1548745779 1 udp 2113937151 192.168.231.1 53621 typ host generation 0
a=candidate:1548745779 2 udp 2113937151 192.168.231.1 53621 typ host generation 0
a=candidate:2307665501 1 udp 1845501695 222.222.222.222 36790 typ srflx raddr 10.0.1.22 rport 64506 generation 0
a=candidate:2307665501 2 udp 1845501695 222.222.222.222 36790 typ srflx raddr 10.0.1.22 rport 64506 generation 0
a=candidate:1273030236 1 tcp 1509957375 192.168.2.1 49435 typ host generation 0
a=candidate:1273030236 2 tcp 1509957375 192.168.2.1 49435 typ host generation 0
a=candidate:2239900709 1 tcp 1509957375 10.0.1.22 49436 typ host generation 0
a=candidate:2239900709 2 tcp 1509957375 10.0.1.22 49436 typ host generation 0
a=candidate:1171060192 1 tcp 1509957375 169.254.41.222 49437 typ host generation 0
a=candidate:1171060192 2 tcp 1509957375 169.254.41.222 49437 typ host generation 0
a=candidate:101294621 1 tcp 1509957375 192.168.82.1 49438 typ host generation 0
a=candidate:101294621 2 tcp 1509957375 192.168.82.1 49438 typ host generation 0
a=candidate:315359427 1 tcp 1509957375 192.168.231.1 49439 typ host generation 0
a=candidate:315359427 2 tcp 1509957375 192.168.231.1 49439 typ host generation 0
a=ice-ufrag:iYXgKsUK8T05FLQV
a=ice-pwd:9nlvJbkhAWW5pIXNcsG1FhuA
a=ice-options:google-ice
a=sendrecv
a=mid:video
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:dkTRiMIaXZ3bddNxiVnX7gjMl9YDiNmI4xF77Nbs
a=rtpmap:100 VP8/90000
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:152464154 cname:h6qCbiYzqBxsxi1k
a=ssrc:152464154 msid:t8CNFmyJQrnl4oHi9j0PEilZbDurviQfbJMB v0
a=ssrc:152464154 mslabel:t8CNFmyJQrnl4oHi9j0PEilZbDurviQfbJMB
a=ssrc:152464154 label:t8CNFmyJQrnl4oHi9j0PEilZbDurviQfbJMBv0

ANSWER:
=====================
v=0
o=FreeSWITCH 1358301505 1358301506 IN IP4 111.111.111.111
s=FreeSWITCH
c=IN IP4 111.111.111.111
t=0 0
a=msid-semantic: WMS YqAYYo2owT20KniSQNBjSnlqpx0gesi3
m=audio 10582 RTP/SAVPF 103 126
a=rtpmap:103 ISAC/16000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-16
a=silenceSupp:off - - - -
a=ptime:30
a=sendrecv
a=rtcp:10583 IN IP4 111.111.111.111
a=ssrc:1090042007 cname:IJRwXJLjtDa3QjMx
a=ssrc:1090042007 msid:YqAYYo2owT20KniSQNBjSnlqpx0gesi3 a0
a=ssrc:1090042007 mslabel:YqAYYo2owT20KniSQNBjSnlqpx0gesi3
a=ssrc:1090042007 label:YqAYYo2owT20KniSQNBjSnlqpx0gesi3a0
a=ice-ufrag:XdHGqSWFfNLj5UcD
a=ice-pwd:tU0huBrN4sHKBj8p
a=candidate:3205131696 1 udp 659136 111.111.111.111 10582 typ host generation 0
a=candidate:7003587207 1 udp 659126 111.111.111.111 10582 typ srflx generation 0
a=candidate:3205131696 2 udp 659134 111.111.111.111 10583 typ host generation 0
a=candidate:7003587207 2 udp 659124 111.111.111.111 10583 typ srflx generation 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:Rsha3cbVClbetEsMLZ7iOh6fKE9wYxpy+9IJHDb/
m=video 57176 RTP/SAVPF 100
a=rtpmap:100 VP8/90000
a=rtcp:57177 IN IP4 111.111.111.111
a=ssrc:410887475 cname:IJRwXJLjtDa3QjMx
a=ssrc:410887475 msid:YqAYYo2owT20KniSQNBjSnlqpx0gesi3 v0
a=ssrc:410887475 mslabel:YqAYYo2owT20KniSQNBjSnlqpx0gesi3
a=ssrc:410887475 label:YqAYYo2owT20KniSQNBjSnlqpx0gesi3v0
a=ice-ufrag:e854vr4jVXa9ROQd
a=ice-pwd:RnklJ2Bkg0vFw7KB
a=candidate:0625409032 1 udp 659136 111.111.111.111 57176 typ host generation 0
a=candidate:6756269338 1 udp 659126 111.111.111.111 57176 typ srflx generation 0
a=candidate:0625409032 2 udp 659134 111.111.111.111 57177 typ host generation 0
a=candidate:6756269338 2 udp 659124 111.111.111.111 57177 typ srflx generation 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:Rsha3cbVClbetEsMLZ7iOh6fKE9wYxpy+9IJHDb/

Justin Uberti

unread,

Jan 17, 2013, 8:17:45 PM1/17/13

to discuss-webrtc

We have tested with other endpoints with non-muxed RTCP, so I don't think the error is on the Chrome side.

--

Anthony Minessale

unread,

Jan 17, 2013, 11:49:58 PM1/17/13

to discuss...@googlegroups.com

I was wrong about that, I re-checked and realized I was not sending it anymore so that's why it appeared to improve.

I got it sending again with mux and its still failing both audio and video just for rtcp. If I call my own endpoint on both sides its fine so is there something special about decrypting rtcp in chrome? Is the beginnings of the DTLS-SRTP starting to emerge? If so is that negotiated or just presumed to be used.

--

--
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_...@hotmail.com
GTALK/JABBER/PAYPAL:anthony....@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org
googletalk:conf...@conference.freeswitch.org
pstn:+19193869900

Anthony Minessale

unread,

Jan 17, 2013, 11:55:58 PM1/17/13

to discuss...@googlegroups.com

Also, if chrome is the offerer, both audio and video RTCP cannot unprotect on the chrome recv end but if chrome is the answerer, only the video RTCP fails to unprotect.

Justin Uberti

unread,

Jan 18, 2013, 12:18:35 AM1/18/13

to discuss-webrtc

No, this has nothing to do with DTLS, this code is regularly tested and has not changed recently. (And use of DTLS is negotiated.)

Sounds like you might be using the wrong HMAC size for RTCP.

--

Anthony Minessale

unread,

Jan 18, 2013, 1:36:42 AM1/18/13

to discuss...@googlegroups.com

Got that part right, always hmac_sha1_80 for RTCP.

I'm sure whatever it is, its just something I need to uncover since it seems to work chrome on chrome.

I've noticed the line number has gone from 800 to 810 but the code I was looking at has the error printing from line 754.

VERBOSE1:channel.cc(810)] Failed to unprotect video RTCP packet: size=90, type=200

Do you know which repo has the source that matches up so i can look for something there and compare it to what I'm doing?

Anthony Minessale

unread,

Jan 20, 2013, 4:39:37 AM1/20/13

to discuss...@googlegroups.com

At long last the answer emerges.......

The srtp lib we were using was older than the one in chrome and updating our end made it work.

Anthony Minessale

unread,

Jan 20, 2013, 2:21:43 PM1/20/13

to discuss...@googlegroups.com

Yah, that's on the todo list.

On Fri, Jan 18, 2013 at 12:16 PM, Jon Steer <jon....@gmail.com> wrote:

I noticed that your SDP contains

a=candidate:7003587207 1 udp 659126 111.111.111.111 10582 typ srflx generation 0

which is missing the raddr/rport which is required. Is that also an issue?

MSN:anthon...@hotmail.com

GTALK/JABBER/PAYPAL:anthony.mine...@gmail.com

IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference

sip...@conference.freeswitch.org
googletal...@conference.freeswitch.org
pstn:+19193869900

--
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm

MSN:anthon...@hotmail.com

GTALK/JABBER/PAYPAL:anthony.mine...@gmail.com

IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference

sip...@conference.freeswitch.org
googletal...@conference.freeswitch.org
pstn:+19193869900

--

--

--
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm

MSN:anthon...@hotmail.com

GTALK/JABBER/PAYPAL:anthony.mine...@gmail.com

IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference

sip...@conference.freeswitch.org
googletal...@conference.freeswitch.org
pstn:+19193869900

--

Anthony Minessale

unread,

Jan 20, 2013, 4:04:13 PM1/20/13

to discuss...@googlegroups.com

Speaking of srtp and SDP, is the dtls ready for interop now? Is it enabled by default or behind a flag?

Reply all

Reply to author

Forward