Feedback submitted for this issue:
https://feedback.corp.google.com/product/208/neutron?lView=rd&lRSort=1&lROrder=2&lRFilter=1&lReportSearch=user:srcv&lReport=9436501724

WebRTC internal dump and complete js logs from device Samus:
https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/616263/

If this is happening in M51 and M52, could this be a problem at apprtc side? 

I can repro this on:
Linux 52.0.2743.10 dev 
Mac 53.0.2754.0 canary

but not on Mac 50.0.2661.75 (stable), so I guess it's a M51 regression hitting all platforms?

jansson: can you have a look?

Actually it seems to be a loopback issue, audio=false param is not needed. Will take a look.

This is strange, I could repro without the video=false param but then it suddenly worked again. Hmm. I can however consistently repro using the video=false param hence I would focus on that.

One major difference I see beetween M50 and M51-52 is that the video m-line is no longer present when not sending video (it is always present in <=M50 regardless).

If I set offerToReceiveVideo to 0 on M50 I get the same error which in turn removes the video m-line.

Also noticed the addition of a crypto line:
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:aUDP5Kq5uZ0tq7VzJgbl4L7nk1U3xlpOUlFC0PnM
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:6CLZs1fyf4fgmBy6WUMTkdWucrHmP2WZf69FaUnT

Found the culprit, when setting up a normal P2P or Tab2Tab call, the first a=crypto:0 AES_CM_128_HMAC_SHA1_32 is negotiated away (answer only has the a=crypto:1 AES_CM_128_HMAC_SHA1_80) however when doing loopback, the offer SDP is reused, just replacing the type from "offer" to "answer" hence the crypto:0.... line is present in the answer causing setRemoteDescription to fail.

M50 does not generate the a=crypto:0 AES_CM_128_HMAC_SHA1_32 line (uses only the first 32 bits of the checksum?).

I can work around it in AppRTC by removing this line in the answer. 

Question is, was this intentional or a consequence of changing some crypto library?

FTR, yes AppRTC is using SDES for loopback due to DTLS has historically not been usable in this scenario, not sure if it could be worked around now (One client cannot have different keys (you need different keys on either side for DTLS, right?)?)

Using SDES is a Bad Thing - it's exercising a codepath we don't want developers to use. In fact, specs say implemenations MUST NOT implement SDES.

Try to just do normal negotiation for loopback - if it fails, file a bug.

We can't do normal negotiation for loopback, because one PeerConnection can't act as both a DTLS client and server. So the options are:

1. Use SDES (bad).
2. Use no encryption (worse, and not even possible without dev build of Chrome and command line flags).
3. Use two PeerConnections.

Two PeerConnections seems like the viable option to me (and lessens the difference between "loopback" and normal calls).

If you really want to make life complicated, you can connect a "loopback" call to a separate PeerConnection that just lives to connect its output to its input - that will give you two network transitions for the price of one :-)

Note:

1. This issue is not seen on Linux with chrome version 50.0.2661.102 stable
2. This issue was not observed when apprtc loopback audio only call was tested on CrOS with M52 52.0.2743.0 / 8350.8.0 dev on 5/27/2016 (but this issue is seen on 5/31/2016 when tested on same CrOS device with same version)

Thanks for the responses. I would still like to know why there is an additional crypto line in >= M51.

I think comment #6 would be the reason. For some reason, audio and video have different sets of supported cipher suites. So when offering both audio and video,  only one cipher suite is offered. But when offering just audio, two cipher suites are offered.

#17: This made me think of something. I seem to recall that when we gather stats about ciphersuite usage, "audio", "video" and "media" are treated as separate things. I think we typically only report one of the three even though I assume we use the same certificate for all three channels (the one picked based on the DTLS handshake).

We only negotiate one certificate, right? Is that so? (Splitting this up into "audio", "video" and "media" makes little sense?)

As such, #17 sounds like we only negotiate what is supported by all channels we want to use, and that "audio" and "video" have different overlapping sets?

I remember the SHA1_32 checksums ... they are used because they use 4 bytes of the packet for the checksum, instead of the 10 bytes used by the SHA1_80 checksum. This matters for audio, where packets can be quite small and bandwidth tighter than they are where video is feasible.

These are SRTP protection profiles, both are produced from the same DTLS handshake. So this part of the negotiation shouldn't affect certs.

SRTP_AES128_CM_HMAC_SHA1_80 is the only one mandated by rtcweb-security-arch.

Re #17, I see, that makes sense. FTR filed https://github.com/webrtc/apprtc/issues/312 to track using 2 peerconnections for AppRTC loopback.

Workaround has now been pushed to AppRTC. Long term is what I mentioned in #20.

Verified this issue on device Minnie with M52 stable( 52.0.2743.85 / 8350.60.0) Apprtc loopback audio only call is connected and there are no errors in js console.