Bowser ICE offer SDP cannot be parsed by server? about bowser

[pantaoran]

Some more digging into the code of mentioned "webrtcsdp.cc" shows that the empty string is passed like that in the source, it's not something taken from the SDP contents. See line 2190 here:

https://chromium.googlesource.com/external/webrtc/stable/talk/+/master/app/webrtc/webrtcsdp.cc

This actually occurs because "AddTransportInfo" returns false, and that seems to happen because it's already present. See the method comment for this in the source:

// Adds a TransportInfo to this description.
// Returns false if a TransportInfo with the same name already exists.
bool AddTransportInfo(const TransportInfo& transport_info);

All this indicates to me that the problem is that Bowser's ICE offer SDP contains two audio and two video blocks for some reason, which doesn't happen on other browsers.
I'm not sure how to further debug this, any ideas?

[pantaoran]

In my Javascript I have the following code:

this.configOffer={ "offerToReceiveAudio": 1, "offerToReceiveVideo": 1 }

I would then pass this in as constraints when I create the offer. It seems that this is the source of my problem; when I remove this I don't get any errors and the offer only has one respective audio and video section.

[stefanalund]

Good. I guess we could close this issue then?

[pantaoran]

I'm off work now, tomorrow morning I need to test if this version works for other systems/browsers or not.
But I have the feeling that this is a workaround at best. The same code didn't produce duplicated sections in other browsers, so I'm not sure if we can call it "solved".

[stefhak]

I agree. I think it should work as a workaround, but I think bowser does
the wrong thing.

On Tue, Sep 15, 2015 at 2:30 PM, pantaoran [email protected] wrote:

I'm off work now, tomorrow morning I need to test if this version works
for other systems/browsers or not.
But I have the feeling that this is a workaround at best. The same code
didn't produce duplicated sections in other browsers, so I'm not sure if we
can call it "solved".

—
Reply to this email directly or view it on GitHub
#51 (comment)
.

[pantaoran]

Like I feared: omitting the mentioned constraints makes Bowser work but breaks Chrome, it doesn't include audio/video in the offer anymore.
So now the workaround becomes more elaborate, I need to detect if the code is running in Bowser and behave differently in that case. That is definitely not good.

Edit: But since I have no choice for now, this is what I'm using
if(-1 < navigator.userAgent.indexOf("Bowser")) isBowser=true;

[stefhak]

I'll let someone else respond about detecting Bowser (not sure) but would
like to understand a bit more about the situation.

The SDP you attached indicate that you have one audio and one video track
attached to the PeerConnection, and in addition set the offerToReceive to 1
for both audio and video. Bowser here creates two m-lines, but it should
create only one.

But what puzzles me is that Chrome does not work if you omit the
offerToReceiveX. Would it be possible for you to attach SDPs for Chrome
with and without the offerToReceive?

On Wed, Sep 16, 2015 at 4:17 AM, pantaoran [email protected] wrote:

Like I feared: omitting the mentioned constraints makes Bowser work but
breaks Chrome, it doesn't include audio/video in the offer anymore.
So now the workaround becomes more elaborate, I need to detect if the code
is running in Bowser and behave differently in that case. That is
definitely not good.

But since I have no choice for now: How can I detect that I'm running
Bowser?

—
Reply to this email directly or view it on GitHub
#51 (comment)
.

[stefhak]

s/two m-lines/two m-lines per media type (i.e. two audio lines and two
video lines)/

On Wed, Sep 16, 2015 at 7:46 AM, stefan hakansson [email protected] wrote:

I'll let someone else respond about detecting Bowser (not sure) but would
like to understand a bit more about the situation.

The SDP you attached indicate that you have one audio and one video track
attached to the PeerConnection, and in addition set the offerToReceive to 1
for both audio and video. Bowser here creates two m-lines, but it should
create only one.

But what puzzles me is that Chrome does not work if you omit the
offerToReceiveX. Would it be possible for you to attach SDPs for Chrome
with and without the offerToReceive?

On Wed, Sep 16, 2015 at 4:17 AM, pantaoran [email protected]
wrote:

Like I feared: omitting the mentioned constraints makes Bowser work but
breaks Chrome, it doesn't include audio/video in the offer anymore.
So now the workaround becomes more elaborate, I need to detect if the
code is running in Bowser and behave differently in that case. That is
definitely not good.

But since I have no choice for now: How can I detect that I'm running
Bowser?

—
Reply to this email directly or view it on GitHub
#51 (comment)
.

[pantaoran]

Sure. Showing client's offers such as logged by the server.
Used both desktop and mobile due to different hardware which affects offer (presence of camera).

Chrome on my Ubuntu Desktop (no webcam) WITH the explicit audio/video offers (works)
o=- 6998835424337475692 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video data
a=msid-semantic: WMS fGmW7VOqkF60FshlxShEAIg6ahntBItq0MIw
m=audio 48144 RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
c=IN IP4 192.168.0.53
a=rtcp:55281 IN IP4 192.168.0.53
a=candidate:2991111282 1 udp 2122260223 192.168.0.53 48144 typ host generation 0
a=candidate:2991111282 2 udp 2122260222 192.168.0.53 55281 typ host generation 0
a=ice-ufrag:kBpDO36IJK7N0AY2
a=ice-pwd:n3nLejOAkfy2ZUBXWznqGkZy
a=fingerprint:sha-256 9D:58:90:CE:E7:21:91:B8:B3:0B:CE:C6:B6:D8:E5:19:43:EC:DF:F9:7A:37:90:B1:B5:0D:B4:04:B3:C9:45:57
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10; useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:3693806476 cname:tfRRsuMoa7r+AYND
a=ssrc:3693806476 msid:fGmW7VOqkF60FshlxShEAIg6ahntBItq0MIw 157a734e-da7c-499a-9e6e-1d1765f64ae2
a=ssrc:3693806476 mslabel:fGmW7VOqkF60FshlxShEAIg6ahntBItq0MIw
a=ssrc:3693806476 label:157a734e-da7c-499a-9e6e-1d1765f64ae2
m=video 43674 RTP/SAVPF 100 116 117 96
c=IN IP4 192.168.0.53
a=rtcp:49001 IN IP4 192.168.0.53
a=candidate:2991111282 1 udp 2122260223 192.168.0.53 43674 typ host generation 0
a=candidate:2991111282 2 udp 2122260222 192.168.0.53 49001 typ host generation 0
a=ice-ufrag:kBpDO36IJK7N0AY2
a=ice-pwd:n3nLejOAkfy2ZUBXWznqGkZy
a=fingerprint:sha-256 9D:58:90:CE:E7:21:91:B8:B3:0B:CE:C6:B6:D8:E5:19:43:EC:DF:F9:7A:37:90:B1:B5:0D:B4:04:B3:C9:45:57
a=setup:actpass
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=recvonly
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
m=application 60991 DTLS/SCTP 5000
c=IN IP4 192.168.0.53
a=candidate:2991111282 1 udp 2122260223 192.168.0.53 60991 typ host generation 0
a=ice-ufrag:kBpDO36IJK7N0AY2
a=ice-pwd:n3nLejOAkfy2ZUBXWznqGkZy
a=fingerprint:sha-256 9D:58:90:CE:E7:21:91:B8:B3:0B:CE:C6:B6:D8:E5:19:43:EC:DF:F9:7A:37:90:B1:B5:0D:B4:04:B3:C9:45:57
a=setup:actpass
a=mid:data
a=sctpmap:5000 webrtc-datachannel 1024

Chrome on my Ubuntu Desktop (no webcam) WITHOUT the explicit audio/video offers (fails, works on Bowser)
o=- 7246236476092860033 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio data
a=msid-semantic: WMS MQdFkTJZyLm7repktwTVxAPoKF7tLmrpxGtl
m=audio 9 RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:KQUcjkO8Y069+/rs
a=ice-pwd:w15r3fc4xsHpdCOgfGLKquRs
a=fingerprint:sha-256 9D:58:90:CE:E7:21:91:B8:B3:0B:CE:C6:B6:D8:E5:19:43:EC:DF:F9:7A:37:90:B1:B5:0D:B4:04:B3:C9:45:57
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10; useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:1706480669 cname:f8P2om/bI4ChENB8
a=ssrc:1706480669 msid:MQdFkTJZyLm7repktwTVxAPoKF7tLmrpxGtl 447bb470-55d8-49aa-ab35-0bed2ef397c2
a=ssrc:1706480669 mslabel:MQdFkTJZyLm7repktwTVxAPoKF7tLmrpxGtl
a=ssrc:1706480669 label:447bb470-55d8-49aa-ab35-0bed2ef397c2
m=application 9 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=ice-ufrag:KQUcjkO8Y069+/rs
a=ice-pwd:w15r3fc4xsHpdCOgfGLKquRs
a=fingerprint:sha-256 9D:58:90:CE:E7:21:91:B8:B3:0B:CE:C6:B6:D8:E5:19:43:EC:DF:F9:7A:37:90:B1:B5:0D:B4:04:B3:C9:45:57
a=setup:actpass
a=mid:data
a=sctpmap:5000 webrtc-datachannel 1024

Chrome on my Android Nexus 5 WITH the explicit audio/video offers (works)
o=- 2869945560636614785 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video data
a=msid-semantic: WMS
m=audio 9 RTP/SAVPF 111 103 9 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:HO7kZWNYAbh2AuYZ
a=ice-pwd:BoTGM8eW3lO26uGMkZ67wSWk
a=fingerprint:sha-256 A9:FE:2C:33:CE:D9:68:B1:A0:AB:7B:19:3E:1F:D4:95:8B:62:FF:56:04:91:80:43:67:0B:C7:AE:F2:4A:1E:18
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=recvonly
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10; useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
m=video 9 RTP/SAVPF 100 116 117 96
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:HO7kZWNYAbh2AuYZ
a=ice-pwd:BoTGM8eW3lO26uGMkZ67wSWk
a=fingerprint:sha-256 A9:FE:2C:33:CE:D9:68:B1:A0:AB:7B:19:3E:1F:D4:95:8B:62:FF:56:04:91:80:43:67:0B:C7:AE:F2:4A:1E:18
a=setup:actpass
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=recvonly
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
m=application 9 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=ice-ufrag:HO7kZWNYAbh2AuYZ
a=ice-pwd:BoTGM8eW3lO26uGMkZ67wSWk
a=fingerprint:sha-256 A9:FE:2C:33:CE:D9:68:B1:A0:AB:7B:19:3E:1F:D4:95:8B:62:FF:56:04:91:80:43:67:0B:C7:AE:F2:4A:1E:18
a=setup:actpass
a=mid:data
a=sctpmap:5000 webrtc-datachannel 1024

Chrome on my Android Nexus 5 WITHOUT the explicit audio/video offers (fails, works on Bowser)
v=0
o=- 4916567557874506893 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS
m=application 42832 DTLS/SCTP 5000
c=IN IP4 192.168.0.100
a=candidate:2131708102 1 udp 2122194687 192.168.0.100 42832 typ host generation 0
a=ice-ufrag:KR65a9BMBOzpGJtX
a=ice-pwd:e5MZwv10e8CexPQ1H0CZCrvL
a=fingerprint:sha-256 A9:FE:2C:33:CE:D9:68:B1:A0:AB:7B:19:3E:1F:D4:95:8B:62:FF:56:04:91:80:43:67:0B:C7:AE:F2:4A:1E:18
a=setup:actpass
a=mid:data
a=sctpmap:5000 webrtc-datachannel 1024

[stefhak]

Hi, interesting.

I understand why your ubuntu computer only creates an audio m-line since it
has no camera, but why are there no m-lines (except for the data channel)
on the Nexus 5? It has both microphone and camera.

On Wed, Sep 16, 2015 at 11:43 AM, pantaoran [email protected]
wrote:

Sure. Showing client's offers such as logged by the server.
Used both desktop and mobile due to different hardware which affects offer
(presence of camera).

Chrome on my Ubuntu Desktop (no webcam) WITH the explicit audio/video
offers (works)
o=- 6998835424337475692 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video data
a=msid-semantic: WMS fGmW7VOqkF60FshlxShEAIg6ahntBItq0MIw
m=audio 48144 RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
c=IN IP4 192.168.0.53
a=rtcp:55281 IN IP4 192.168.0.53
a=candidate:2991111282 1 udp 2122260223 192.168.0.53 48144 typ host
generation 0
a=candidate:2991111282 2 udp 2122260222 192.168.0.53 55281 typ host
generation 0
a=ice-ufrag:kBpDO36IJK7N0AY2
a=ice-pwd:n3nLejOAkfy2ZUBXWznqGkZy
a=fingerprint:sha-256
9D:58:90:CE:E7:21:91:B8:B3:0B:CE:C6:B6:D8:E5:19:43:EC:DF:F9:7A:37:90:B1:B5:0D:B4:04:B3:C9:45:57
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10; useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:3693806476 cname:tfRRsuMoa7r+AYND
a=ssrc:3693806476 msid:fGmW7VOqkF60FshlxShEAIg6ahntBItq0MIw
157a734e-da7c-499a-9e6e-1d1765f64ae2
a=ssrc:3693806476 mslabel:fGmW7VOqkF60FshlxShEAIg6ahntBItq0MIw
a=ssrc:3693806476 label:157a734e-da7c-499a-9e6e-1d1765f64ae2
m=video 43674 RTP/SAVPF 100 116 117 96
c=IN IP4 192.168.0.53
a=rtcp:49001 IN IP4 192.168.0.53
a=candidate:2991111282 1 udp 2122260223 192.168.0.53 43674 typ host
generation 0
a=candidate:2991111282 2 udp 2122260222 192.168.0.53 49001 typ host
generation 0
a=ice-ufrag:kBpDO36IJK7N0AY2
a=ice-pwd:n3nLejOAkfy2ZUBXWznqGkZy
a=fingerprint:sha-256
9D:58:90:CE:E7:21:91:B8:B3:0B:CE:C6:B6:D8:E5:19:43:EC:DF:F9:7A:37:90:B1:B5:0D:B4:04:B3:C9:45:57
a=setup:actpass
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=recvonly
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
m=application 60991 DTLS/SCTP 5000
c=IN IP4 192.168.0.53
a=candidate:2991111282 1 udp 2122260223 192.168.0.53 60991 typ host
generation 0
a=ice-ufrag:kBpDO36IJK7N0AY2
a=ice-pwd:n3nLejOAkfy2ZUBXWznqGkZy
a=fingerprint:sha-256
9D:58:90:CE:E7:21:91:B8:B3:0B:CE:C6:B6:D8:E5:19:43:EC:DF:F9:7A:37:90:B1:B5:0D:B4:04:B3:C9:45:57
a=setup:actpass
a=mid:data
a=sctpmap:5000 webrtc-datachannel 1024

Chrome on my Ubuntu Desktop (no webcam) WITHOUT the explicit audio/video
offers (fails, works on Bowser)
o=- 7246236476092860033 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio data
a=msid-semantic: WMS MQdFkTJZyLm7repktwTVxAPoKF7tLmrpxGtl
m=audio 9 RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:KQUcjkO8Y069+/rs
a=ice-pwd:w15r3fc4xsHpdCOgfGLKquRs
a=fingerprint:sha-256
9D:58:90:CE:E7:21:91:B8:B3:0B:CE:C6:B6:D8:E5:19:43:EC:DF:F9:7A:37:90:B1:B5:0D:B4:04:B3:C9:45:57
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10; useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:1706480669 cname:f8P2om/bI4ChENB8
a=ssrc:1706480669 msid:MQdFkTJZyLm7repktwTVxAPoKF7tLmrpxGtl
447bb470-55d8-49aa-ab35-0bed2ef397c2
a=ssrc:1706480669 mslabel:MQdFkTJZyLm7repktwTVxAPoKF7tLmrpxGtl
a=ssrc:1706480669 label:447bb470-55d8-49aa-ab35-0bed2ef397c2
m=application 9 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=ice-ufrag:KQUcjkO8Y069+/rs
a=ice-pwd:w15r3fc4xsHpdCOgfGLKquRs
a=fingerprint:sha-256
9D:58:90:CE:E7:21:91:B8:B3:0B:CE:C6:B6:D8:E5:19:43:EC:DF:F9:7A:37:90:B1:B5:0D:B4:04:B3:C9:45:57
a=setup:actpass
a=mid:data
a=sctpmap:5000 webrtc-datachannel 1024

Chrome on my Android Nexus 5 WITH the explicit audio/video offers (works)
o=- 2869945560636614785 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video data
a=msid-semantic: WMS
m=audio 9 RTP/SAVPF 111 103 9 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:HO7kZWNYAbh2AuYZ
a=ice-pwd:BoTGM8eW3lO26uGMkZ67wSWk
a=fingerprint:sha-256
A9:FE:2C:33:CE:D9:68:B1:A0:AB:7B:19:3E:1F:D4:95:8B:62:FF:56:04:91:80:43:67:0B:C7:AE:F2:4A:1E:18
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=recvonly
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10; useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
m=video 9 RTP/SAVPF 100 116 117 96
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:HO7kZWNYAbh2AuYZ
a=ice-pwd:BoTGM8eW3lO26uGMkZ67wSWk
a=fingerprint:sha-256
A9:FE:2C:33:CE:D9:68:B1:A0:AB:7B:19:3E:1F:D4:95:8B:62:FF:56:04:91:80:43:67:0B:C7:AE:F2:4A:1E:18
a=setup:actpass
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=recvonly
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
m=application 9 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=ice-ufrag:HO7kZWNYAbh2AuYZ
a=ice-pwd:BoTGM8eW3lO26uGMkZ67wSWk
a=fingerprint:sha-256
A9:FE:2C:33:CE:D9:68:B1:A0:AB:7B:19:3E:1F:D4:95:8B:62:FF:56:04:91:80:43:67:0B:C7:AE:F2:4A:1E:18
a=setup:actpass
a=mid:data
a=sctpmap:5000 webrtc-datachannel 1024

Chrome on my Android Nexus 5 WITHOUT the explicit audio/video offers
(fails, works on Bowser)
v=0
o=- 4916567557874506893 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS
m=application 42832 DTLS/SCTP 5000
c=IN IP4 192.168.0.100
a=candidate:2131708102 1 udp 2122194687 192.168.0.100 42832 typ host
generation 0
a=ice-ufrag:KR65a9BMBOzpGJtX
a=ice-pwd:e5MZwv10e8CexPQ1H0CZCrvL
a=fingerprint:sha-256
A9:FE:2C:33:CE:D9:68:B1:A0:AB:7B:19:3E:1F:D4:95:8B:62:FF:56:04:91:80:43:67:0B:C7:AE:F2:4A:1E:18
a=setup:actpass
a=mid:data
a=sctpmap:5000 webrtc-datachannel 1024

—
Reply to this email directly or view it on GitHub
#51 (comment)
.

[pantaoran]

This might be a follow up problem caused by the above:
On Bowser the onaddstream(event) callback is never invoked. I'm trying to solve this now, but so far no success. Other people sometimes seem to have solved this by sending the constraints, but as described above, I can't do that...

Edit: I now tried to work around onaddstream by calling getRemoteStreams on the connection repeatedly, but that always returns an empty array with no streams inside :-(
On Chrome I can also get the video stream this way.