Closed Bug 1397756 Opened 7 years ago Closed 7 years ago

a=ssrc is added in an recvonly answer

Categories

(Core :: WebRTC: Signaling, defect)

Product:
Core
Component:
WebRTC: Signaling
Version:
55 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: work, Unassigned)

Details

(Whiteboard: [needinfo 2017-09-12 drno] ) 

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36

Steps to reproduce:

Create a peerconnection from chrome to firefox where chrome is a sendonly and firefox is a recvonly


Actual results:

Chrome sent a sendonly sdp and firefox replied with a recvonly sdp.
Firefox also added an a=ssrc for each m=audio and m=video


Expected results:

Is this correct? shouldn't be any a=ssrc since this is a recv only peerconnection?

For more details: https://github.com/webrtc/adapter/issues/674
Component: Untriaged → WebRTC
Product: Firefox → Core
:drno, what do you think about this?
Component: WebRTC → WebRTC: Signaling
Flags: needinfo?(drno)
Whiteboard: [needinfo 2017-09-12 drno]
This is valid, yes. Signaling the recvonly SSRC is important because that appears in receiver reports, and we want to be able to demux those when using bundle.
Once everyone is supporting RTP MID, we won't need to signal this, or any other SSRC for that matter.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Flags: needinfo?(drno)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.