Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

H.264 codec and/or SDP issues with RTCPeerConnection

648 views
Skip to first unread message

Christian

unread,
Jan 27, 2016, 3:53:39 PM1/27/16
to dev-...@lists.mozilla.org
Hi,

We are trying to analyze a problem with a RTCPeerConnection between
Firefox 44.0 and a Cisco 8520 MCU (connected via the Janus WebRTC
Gateway (https://github.com/meetecho/janus-gateway)). Unfortunately,
we've got stuck. :(

Problem description: The remote SDP gets accepted by Firefox, but no
video is playing.

local SDP:
[...]
a=fmtp:126
profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
[...]

remote SDP:
[...]
a=fmtp:97
profile-level-id=420016;level-asymmetry-allowed=0;max-mbps=108000;max-fs=3840;max-dpb=5408
a=fmtp:126
profile-level-id=420016;level-asymmetry-allowed=0;packetization-mode=1;max-mbps=108000;max-fs=3840;max-dpb=5408
[...]

Although the remote SDP gets accepted by RTCSessionDescription(), there
is no remote video playing in Firefox. We could not find any error hint.

We have prepared a test case:
1. open https://janus.bfs.de/
2. select "Cisco MCU"
3. select "Connect"

In contrast to that a RTCPeerConnection between Firefox and an
OpenMCU-ru installation works flawlessly (same gateway, same JavaScript
code):
1. open https://janus.bfs.de/
2. select "Open MCU"
3. select "Connect"

We have worked hard on this problem for several days now, but we could
not figure out what is going wrong. We would really appreciate your
advice, how to track down and fix this problem.

Many thanks in advance and best regards,

Christian

Byron Campen

unread,
Jan 27, 2016, 3:59:03 PM1/27/16
to dev-...@lists.mozilla.org
Can you send the full SDP?

Best regards,
Byron Campen
> _______________________________________________
> dev-media mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media

Adam Roach

unread,
Jan 27, 2016, 4:10:10 PM1/27/16
to Byron Campen, dev-...@lists.mozilla.org
Byron --

Running through the testcase they put up for us, I get this for the SDP
that does not work:

Local SDP

v=0
o=mozilla...THIS_IS_SDPARTA-44.0 1351892368469534143 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256
01:BA:26:1A:61:1A:64:45:08:D4:48:5F:F7:D7:7E:FF:EB:0A:B0:16:27:E7:80:D9:0F:96:D6:FE:65:60:E4:84
a=group:BUNDLE sdparta_0 sdparta_1
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 61733 UDP/TLS/RTP/SAVPF 109 9 0 8
c=IN IP4 99.152.145.110
a=candidate:0 1 UDP 2122252543 172.17.0.2 61733 typ host
a=candidate:2 1 UDP 2122187007 192.168.2.1 55828 typ host
a=candidate:0 2 UDP 2122252542 172.17.0.2 61942 typ host
a=candidate:2 2 UDP 2122187006 192.168.2.1 50044 typ host
a=candidate:1 1 UDP 1686052863 99.152.145.110 61733 typ srflx raddr
172.17.0.2 rport 61733
a=candidate:1 2 UDP 1686052862 99.152.145.110 61942 typ srflx raddr
172.17.0.2 rport 61942
a=sendrecv
a=end-of-candidates
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=ice-pwd:2633a47c2d3522a7d36a442df338b276
a=ice-ufrag:49068820
a=mid:sdparta_0
a=msid:{01466a0a-f1cc-bb41-8308-ad4611f90774}
{88c4d5c1-8d8e-4747-8dce-3fb5eec337e3}
a=rtcp:61942 IN IP4 99.152.145.110
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=setup:actpass
a=ssrc:3002933469 cname:{a7df74f5-d65f-b243-a1e8-7996e388e70c}
m=video 54139 UDP/TLS/RTP/SAVPF 120 126 97
c=IN IP4 99.152.145.110
a=candidate:0 1 UDP 2122252543 172.17.0.2 54139 typ host
a=candidate:2 1 UDP 2122187007 192.168.2.1 61350 typ host
a=candidate:0 2 UDP 2122252542 172.17.0.2 52337 typ host
a=candidate:2 2 UDP 2122187006 192.168.2.1 65496 typ host
a=candidate:1 1 UDP 1686052863 99.152.145.110 54139 typ srflx raddr
172.17.0.2 rport 54139
a=candidate:1 2 UDP 1686052862 99.152.145.110 52337 typ srflx raddr
172.17.0.2 rport 52337
a=sendrecv
a=end-of-candidates
a=fmtp:126
profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=fmtp:120 max-fs=12288;max-fr=60
a=ice-pwd:2633a47c2d3522a7d36a442df338b276
a=ice-ufrag:49068820
a=mid:sdparta_1
a=msid:{01466a0a-f1cc-bb41-8308-ad4611f90774}
{c6d9add3-9057-ca4a-9c25-15a4b10a9885}
a=rtcp:52337 IN IP4 99.152.145.110
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-mux
a=rtpmap:120 VP8/90000
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/90000
a=setup:actpass
a=ssrc:2343910383 cname:{a7df74f5-d65f-b243-a1e8-7996e388e70c}

Remote SDP

v=0
o=tandberg 0 1 IN IP4 194.94.69.142
s=-
t=0 0
a=sendrecv
a=group:BUNDLE sdparta_0 sdparta_1
a=msid-semantic:WMS janus
m=audio 1 RTP/SAVPF 9 8 0
c=IN IP4 194.94.69.142
b=AS:64000
a=candidate:1 1 udp 2013266431 194.94.69.142 51547 typ host
a=sendrecv
a=fingerprint:sha-256
D2:B9:31:8F:DF:24:D8:0E:ED:D2:EF:25:9E:AF:6F:B8:34:AE:53:9C:E6:F3:8F:F2:64:15:FA:E8:7F:53:2D:38
a=ice-options:trickle
a=ice-pwd:6UlnDoxLo/Z+f/WRRNsxtw
a=ice-ufrag:r1+W
a=mid:sdparta_0
a=rtcp-mux
a=rtpmap:9 G722/8000/1
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=setup:active
a=ssrc:1928289623 cname:janusaudio
a=ssrc:1928289623 msid:janus janusa0
a=ssrc:1928289623 mslabel:janus
a=ssrc:1928289623 label:janusa0
m=video 1 RTP/SAVPF 97 126
c=IN IP4 194.94.69.142
b=AS:4000000
a=candidate:1 1 udp 2013266431 194.94.69.142 51547 typ host
a=sendrecv
a=fingerprint:sha-256
D2:B9:31:8F:DF:24:D8:0E:ED:D2:EF:25:9E:AF:6F:B8:34:AE:53:9C:E6:F3:8F:F2:64:15:FA:E8:7F:53:2D:38
a=fmtp:97
profile-level-id=420016;level-asymmetry-allowed=0;max-mbps=108000;max-fs=3840;max-dpb=5408
a=fmtp:126
profile-level-id=420016;level-asymmetry-allowed=0;packetization-mode=1;max-mbps=108000;max-fs=3840;max-dpb=5408
a=ice-options:trickle
a=ice-pwd:6UlnDoxLo/Z+f/WRRNsxtw
a=ice-ufrag:r1+W
a=label:11
a=mid:sdparta_1
a=rtcp-mux
a=rtpmap:97 H264/90000
a=rtpmap:126 H264/90000
a=setup:active
a=ssrc:659197214 cname:janusvideo
a=ssrc:659197214 msid:janus janusv0
a=ssrc:659197214 mslabel:janus
a=ssrc:659197214 label:janusv0
--
Adam Roach
Principal Platform Engineer
Office of the CTO

Byron Campen

unread,
Jan 27, 2016, 4:15:21 PM1/27/16
to Adam Roach, dev-...@lists.mozilla.org
Maybe a problem with packetization mode 0? That is the codec
preferred by janus in its answer.

Best regards,
Byron Campen

Randell Jesup

unread,
Jan 27, 2016, 4:56:49 PM1/27/16
to dev-...@lists.mozilla.org
On 1/27/2016 1:53 PM, Christian wrote:
> Hi,
>
> We are trying to analyze a problem with a RTCPeerConnection between
> Firefox 44.0 and a Cisco 8520 MCU (connected via the Janus WebRTC
> Gateway (https://github.com/meetecho/janus-gateway)). Unfortunately,
> we've got stuck. :(
>
> Problem description: The remote SDP gets accepted by Firefox, but no
> video is playing.
>
> local SDP:
> [...]
> a=fmtp:126
> profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
> a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
> [...]
>
> remote SDP:
> [...]
> a=fmtp:97
> profile-level-id=420016;level-asymmetry-allowed=0;max-mbps=108000;max-fs=3840;max-dpb=5408
> a=fmtp:126
> profile-level-id=420016;level-asymmetry-allowed=0;packetization-mode=1;max-mbps=108000;max-fs=3840;max-dpb=5408
> [...]
>

RFC 6184 8.2.2:

o The parameters identifying a media format configuration for H.264
are profile-level-id and packetization-mode. These media format
configuration parameters (except for the level part of profile-
level-id) MUST be used symmetrically; that is, the answerer MUST
either maintain all configuration parameters or remove the media
format (payload type) completely if one or more of the parameter
values are not supported. Note that the level part of profile-
level-id includes level_idc, and, for indication of Level 1b when
profile_idc is equal to 66, 77, or 88, bit 4
(constraint_set3_flag) of profile-iop. The level part of profile-
level-id is changeable.

i.e. you can't answer profile-level-id=42e0xx with 4200xx - they don't
match. Many H264 impls ignore the constraint bits and hope things just
work. As it's invalid, we should probably call the error callback, but
I think instead it just didn't start send or receive for video.

Also: I would generally suggest using Mode 1 and not mode 0. While it
may not matter (most implementations that support both handle this) but
mode 0 has a bug where we send SPS/PPS in a STAP-A packet (which is
mode-1 only).

Randell Jesup

Christian

unread,
Feb 2, 2016, 10:42:31 AM2/2/16
to dev-...@lists.mozilla.org
Thank you very much for your explanation!

I have contacted the owner of the MCU and asked for filing a bug report
at Cisco. I hope that they'll fix this soon -- the device is expensive
enough....

Christian
0 new messages