964223 - Audio streams created with OfferToReceiveAudio=true without local audio stream remain recvonly after second createOffer with local audio stream

Status: RESOLVED FIXED

(Core :: WebRTC, defect)

Description

[Michael Froehlich]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.76 Safari/537.36

Steps to reproduce:

I could reproduce the following behavior with Firefox 26 on Mac and Firefox Nightly 29.0a1 (2014-01-26)

1. Created a WebRTC peer connection
2. I DID NOT add any local streams to the connection (thus receive-only mode)
3. Called createOffer with constraints OfferToReceiveAudio = true and OfferToReceiveVideo = true

At this point Firefox is able to receive audio and everything works as expected, but if I continue with:

4. getUserMedia to get a local audio stream (audio = true, video = false)
5. Call addStream with the created audio stream
6. call createOffer again, the audio stream remains RECVONLY.

I doesn't matter if I set the OfferToReceiveAudio constraint to false or remove it entirely from the set of constraints in the second createOffer call - the generated SDP does not provide the newly added audio stream.


Actual results:

The audio stream is still recvonly in the sdp.


Expected results:

The audio stream should have switched to sendrecv in the second createOffer call.

Comment 1

[Michael Froehlich]

To be more specific the SDP generated by createOffer is this:

v=0
o=Mozilla-SIPUA-26.0 2174 0 IN IP4 0.0.0.0
s=SIP Call
t=0 0
a=ice-ufrag:600e2855
a=ice-pwd:9af232903d9b84e855be73e664b6159c
a=fingerprint:sha-256 F3:66:9B:49:18:76:0E:5F:6B:1E:B6:CE:B9:C9:4F:87:FC:CA:AF:04:26:0E:C3:7A:77:15:D7:E2:D6:CC:7A:E1
m=audio 57689 RTP/SAVPF 109 0 8 101
c=IN IP4 10.1.132.28
a=rtpmap:109 opus/48000/2
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=recvonly
a=setup:actpass
a=candidate:0 1 UDP 2128609535 10.1.132.28 57689 typ host
a=candidate:0 2 UDP 2128609534 10.1.132.28 57690 typ host
a=rtcp-mux
a=setup:passive
a=candidate:0 1 UDP 2128609535 10.1.132.28 57689 typ host
a=candidate:0 2 UDP 2128609534 10.1.132.28 57690 typ host
a=rtcp-mux

I would expect it to look more like this:

v=0
o=Mozilla-SIPUA-26.0 18304 0 IN IP4 0.0.0.0
s=SIP Call
t=0 0
a=ice-ufrag:1b0b823e
a=ice-pwd:237cf98fdb55bf31a428b225b8140ddb
a=fingerprint:sha-256 C4:6E:1B:1A:6F:07:E5:5C:1A:86:14:31:BB:A0:DE:80:5B:74:3B:E8:62:46:DF:9A:76:4C:A8:17:6B:B6:8F:04
m=audio 54659 RTP/SAVPF 109 0 8 101
c=IN IP4 10.1.132.28
a=rtpmap:109 opus/48000/2
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=setup:actpass
a=candidate:0 1 UDP 2128609535 10.1.132.28 54659 typ host
a=candidate:0 2 UDP 2128609534 10.1.132.28 54660 typ host
a=rtcp-mux

Note the a=sendrecv vs. the generated a=recvonly.

Comment 2

[Michael Froehlich]

I see that this is probably related to bug 840728.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

This was a request for renegotiation, with landed in Firefox 38, and so should work now