Bowser ICE offer SDP cannot be parsed by server?

[pantaoran]

We are building a server that does some video processing on the video that clients send to it via WebRTC. It works well with Chrome on desktops and on Android, but we can't get it to work on Bowser...

The server side webrtc implementation complains when receiving the first ICE offer:

[000:943] Ignored line: c=IN IP4 0.0.0.0
[000:944] Ignored line: c=IN IP4 192.168.0.124
[000:944] Ignored line: c=IN IP4 192.168.0.124
[000:945] Error(webrtcsdp.cc:371): Failed to parse: "". Reason: Failed to AddTransportInfo with content name: audio

This is running on an iPad Air 2 which is a 64bit device. I installed Bowser from the App store, I don't have access to an ios development environment so I cannot build it myself...

When looking over the offer I can't see anything that might trigger this, have you guys ever seen something like this before? It fails to parse an empty string, but where, how, why? For completeness here is the offer SDP (with empty lines between blocks for readability):

v=0
o=- 1442288273838514200 1 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic:WMS 0bUMqllvZ+38dekVJb9fOu/YyeMlSpOf+SLC

m=audio 1 RTP/SAVPF 111 8 0
c=IN IP4 0.0.0.0
a=rtcp-mux
a=sendrecv
a=rtpmap:111 OPUS/48000/2
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=ssrc:76579041 cname:user2965996170@host-17fe929f
a=ssrc:76579041 msid:0bUMqllvZ+38dekVJb9fOu/YyeMlSpOf+SLC WtrAwG2WrzvMpe+xmPNkSGcErzI2Q7q7xzVV
a=ice-ufrag:Pw3J
a=ice-pwd:aViTPywUvC8FiK7tmZcfrv
a=candidate:37 1 UDP 2013266431 fe80::e864:66ff:fe5c:5f54 57970 typ host
a=fingerprint:sha-256 1D:67:82:2E:1D:35:12:1C:CC:47:F0:A6:35:44:F6:F2:26:34:93:5B:95:98:25:2C:35:44:9A:5F:7E:7F:05:37
a=setup:actpass

m=video 59119 RTP/SAVPF 103 100 120
c=IN IP4 192.168.0.124
a=rtcp:57967 IN IP4 192.168.0.124
a=rtcp-mux
a=sendrecv
a=rtpmap:103 H264/90000
a=rtpmap:100 VP8/90000
a=rtpmap:120 RTX/90000
a=fmtp:103 packetization-mode=1
a=fmtp:120 apt=100;rtx-time=200
a=rtcp-fb:100 nack
a=rtcp-fb:103 nack pli
a=rtcp-fb:100 nack pli
a=rtcp-fb:103 ccm fir
a=rtcp-fb:100 ccm fir
a=ssrc:4154056881 cname:user2965996170@host-17fe929f
a=ssrc:4154056881 msid:0bUMqllvZ+38dekVJb9fOu/YyeMlSpOf+SLC o/3Q6yktomtKq9Uns+4vi0JukCwPk5506HxT
a=ice-ufrag:9XcU
a=ice-pwd:HAmvUFKb78nWxjso2GaHtG
a=candidate:28 1 UDP 2013266431 fe80::e864:66ff:fe5c:5f54 52997 typ host
a=candidate:29 1 TCP 1019216383 fe80::e864:66ff:fe5c:5f54 9 typ host tcptype active
a=candidate:30 1 TCP 1015022079 fe80::e864:66ff:fe5c:5f54 63721 typ host tcptype passive
a=candidate:31 1 UDP 2013266431 192.168.0.124 59119 typ host
a=candidate:32 1 TCP 1019216383 192.168.0.124 9 typ host tcptype active
a=candidate:33 1 TCP 1015022079 192.168.0.124 63723 typ host tcptype passive
a=candidate:34 1 UDP 2013266431 fe80::886:2c8a:72d3:b27e 57968 typ host
a=candidate:35 1 TCP 1019216383 fe80::886:2c8a:72d3:b27e 9 typ host tcptype active
a=candidate:36 1 TCP 1015022079 fe80::886:2c8a:72d3:b27e 63725 typ host tcptype passive
a=candidate:28 2 UDP 2013266430 fe80::e864:66ff:fe5c:5f54 52998 typ host
a=candidate:29 2 TCP 1019216382 fe80::e864:66ff:fe5c:5f54 9 typ host tcptype active
a=candidate:30 2 TCP 1015022078 fe80::e864:66ff:fe5c:5f54 63722 typ host tcptype passive
a=candidate:31 2 UDP 2013266430 192.168.0.124 57967 typ host
a=candidate:32 2 TCP 1019216382 192.168.0.124 9 typ host tcptype active
a=candidate:33 2 TCP 1015022078 192.168.0.124 63724 typ host tcptype passive
a=candidate:34 2 UDP 2013266430 fe80::886:2c8a:72d3:b27e 57969 typ host
a=candidate:35 2 TCP 1019216382 fe80::886:2c8a:72d3:b27e 9 typ host tcptype active
a=candidate:36 2 TCP 1015022078 fe80::886:2c8a:72d3:b27e 63726 typ host tcptype passive
a=fingerprint:sha-256 1D:67:82:2E:1D:35:12:1C:CC:47:F0:A6:35:44:F6:F2:26:34:93:5B:95:98:25:2C:35:44:9A:5F:7E:7F:05:37
a=setup:actpass

m=audio 60502 RTP/SAVPF 111 8 0
c=IN IP4 192.168.0.124
a=rtcp:52994 IN IP4 192.168.0.124
a=rtcp-mux
a=recvonly
a=rtpmap:111 OPUS/48000/2
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=ssrc:2025735048 cname:user2965996170@host-17fe929f
a=ice-ufrag:Zhfy
a=ice-pwd:T3PIjicvPuz14iBOosmbTF
a=candidate:19 1 UDP 2013266431 fe80::e864:66ff:fe5c:5f54 63127 typ host
a=candidate:20 1 TCP 1019216383 fe80::e864:66ff:fe5c:5f54 9 typ host tcptype active
a=candidate:21 1 TCP 1015022079 fe80::e864:66ff:fe5c:5f54 63715 typ host tcptype passive
a=candidate:22 1 UDP 2013266431 192.168.0.124 60502 typ host
a=candidate:23 1 TCP 1019216383 192.168.0.124 9 typ host tcptype active
a=candidate:24 1 TCP 1015022079 192.168.0.124 63717 typ host tcptype passive
a=candidate:25 1 UDP 2013266431 fe80::886:2c8a:72d3:b27e 52995 typ host
a=candidate:26 1 TCP 1019216383 fe80::886:2c8a:72d3:b27e 9 typ host tcptype active
a=candidate:27 1 TCP 1015022079 fe80::886:2c8a:72d3:b27e 63719 typ host tcptype passive
a=candidate:19 2 UDP 2013266430 fe80::e864:66ff:fe5c:5f54 63128 typ host
a=candidate:20 2 TCP 1019216382 fe80::e864:66ff:fe5c:5f54 9 typ host tcptype active
a=candidate:21 2 TCP 1015022078 fe80::e864:66ff:fe5c:5f54 63716 typ host tcptype passive
a=candidate:22 2 UDP 2013266430 192.168.0.124 52994 typ host
a=candidate:23 2 TCP 1019216382 192.168.0.124 9 typ host tcptype active
a=candidate:24 2 TCP 1015022078 192.168.0.124 63718 typ host tcptype passive
a=candidate:25 2 UDP 2013266430 fe80::886:2c8a:72d3:b27e 52996 typ host
a=candidate:26 2 TCP 1019216382 fe80::886:2c8a:72d3:b27e 9 typ host tcptype active
a=candidate:27 2 TCP 1015022078 fe80::886:2c8a:72d3:b27e 63720 typ host tcptype passive
a=fingerprint:sha-256 1D:67:82:2E:1D:35:12:1C:CC:47:F0:A6:35:44:F6:F2:26:34:93:5B:95:98:25:2C:35:44:9A:5F:7E:7F:05:37
a=setup:actpass

m=video 62024 RTP/SAVPF 103 100 120
c=IN IP4 192.168.0.124
a=rtcp:63124 IN IP4 192.168.0.124
a=rtcp-mux
a=recvonly
a=rtpmap:103 H264/90000
a=rtpmap:100 VP8/90000
a=rtpmap:120 RTX/90000
a=fmtp:103 packetization-mode=1
a=fmtp:120 apt=100;rtx-time=200
a=rtcp-fb:100 nack
a=rtcp-fb:103 nack pli
a=rtcp-fb:100 nack pli
a=rtcp-fb:103 ccm fir
a=rtcp-fb:100 ccm fir
a=ssrc:608919872 cname:user2965996170@host-17fe929f
a=ice-ufrag:kTRX
a=ice-pwd:eBqB/vmye8ly/Xnt1ItgjD
a=candidate:10 1 UDP 2013266431 fe80::e864:66ff:fe5c:5f54 54108 typ host
a=candidate:11 1 TCP 1019216383 fe80::e864:66ff:fe5c:5f54 9 typ host tcptype active
a=candidate:12 1 TCP 1015022079 fe80::e864:66ff:fe5c:5f54 63709 typ host tcptype passive
a=candidate:13 1 UDP 2013266431 192.168.0.124 62024 typ host
a=candidate:14 1 TCP 1019216383 192.168.0.124 9 typ host tcptype active
a=candidate:15 1 TCP 1015022079 192.168.0.124 63711 typ host tcptype passive
a=candidate:16 1 UDP 2013266431 fe80::886:2c8a:72d3:b27e 63125 typ host
a=candidate:17 1 TCP 1019216383 fe80::886:2c8a:72d3:b27e 9 typ host tcptype active
a=candidate:18 1 TCP 1015022079 fe80::886:2c8a:72d3:b27e 63713 typ host tcptype passive
a=candidate:10 2 UDP 2013266430 fe80::e864:66ff:fe5c:5f54 54109 typ host
a=candidate:11 2 TCP 1019216382 fe80::e864:66ff:fe5c:5f54 9 typ host tcptype active
a=candidate:12 2 TCP 1015022078 fe80::e864:66ff:fe5c:5f54 63710 typ host tcptype passive
a=candidate:13 2 UDP 2013266430 192.168.0.124 63124 typ host
a=candidate:14 2 TCP 1019216382 192.168.0.124 9 typ host tcptype active
a=candidate:15 2 TCP 1015022078 192.168.0.124 63712 typ host tcptype passive
a=candidate:16 2 UDP 2013266430 fe80::886:2c8a:72d3:b27e 63126 typ host
a=candidate:17 2 TCP 1019216382 fe80::886:2c8a:72d3:b27e 9 typ host tcptype active
a=candidate:18 2 TCP 1015022078 fe80::886:2c8a:72d3:b27e 63714 typ host tcptype passive
a=fingerprint:sha-256 1D:67:82:2E:1D:35:12:1C:CC:47:F0:A6:35:44:F6:F2:26:34:93:5B:95:98:25:2C:35:44:9A:5F:7E:7F:05:37
a=setup:actpass

m=application 54106 DTLS/SCTP 5000
c=IN IP4 192.168.0.124
a=sendrecv
a=ice-ufrag:h55z
a=ice-pwd:LT2SfJ9lrsrYD6XfjFe5gJ
a=candidate:1 1 UDP 2013266431 fe80::e864:66ff:fe5c:5f54 65164 typ host
a=candidate:2 1 TCP 1019216383 fe80::e864:66ff:fe5c:5f54 9 typ host tcptype active
a=candidate:3 1 TCP 1015022079 fe80::e864:66ff:fe5c:5f54 63706 typ host tcptype passive
a=candidate:4 1 UDP 2013266431 192.168.0.124 54106 typ host
a=candidate:5 1 TCP 1019216383 192.168.0.124 9 typ host tcptype active
a=candidate:6 1 TCP 1015022079 192.168.0.124 63707 typ host tcptype passive
a=candidate:7 1 UDP 2013266431 fe80::886:2c8a:72d3:b27e 54107 typ host
a=candidate:8 1 TCP 1019216383 fe80::886:2c8a:72d3:b27e 9 typ host tcptype active
a=candidate:9 1 TCP 1015022079 fe80::886:2c8a:72d3:b27e 63708 typ host tcptype passive
a=fingerprint:sha-256 1D:67:82:2E:1D:35:12:1C:CC:47:F0:A6:35:44:F6:F2:26:34:93:5B:95:98:25:2C:35:44:9A:5F:7E:7F:05:37
a=setup:actpass
a=sctpmap:5000 webrtc-datachannel 1024

[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 notifications@github.com 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 notifications@github.com 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 stefhak@gmail.com 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 notifications@github.com
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 notifications@github.com
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.