Why does addTransceiver() send SDP a=recvonly causing an extra signalling round-trip?
146 views
Skip to first unread message
Richard Chan
unread,
Aug 6, 2019, 11:01:38 AM8/6/19
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to dev-...@lists.mozilla.org
MDN have recently updated the WebRTC demo webrtc-from-chat
https://github.com/mdn/samples-server/commits/master to use addTransceiver. What is observed is that call setup requires an
extra roundtrip because the
answer SDP contains a=recvonly
Caller: video-offer
Callee: video-answer with a=recvonly
--- call not connected ---
Callee: onnegotiationneeded is fired
Callee: video-offer
Caller: video-answer
--- call is connected
Using addTrack() the flow is much simpler
Caller: video-offer
Callee: video-answer
--- call is connected ---
Is this now the canonical way to do call setup in WebRTC 1.0 with
transceivers?
Is there anyway to avoid the extra signalling round-trip?
Byron Campen
unread,
Aug 6, 2019, 11:27:59 AM8/6/19
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Richard Chan, dev-...@lists.mozilla.org
This is a rough part of the RTCRTPTransceiver specification. The
rules in the spec say that a transceiver created at the answerer does
not "pair up" with anything in an offer, _unless_ that transceiver was
created with addTrack:
+ If the m= section is sendrecv or recvonly, and there are
RtpTransceivers of the same type that were added to the
PeerConnection by addTrack and are not associated with any
m= section and are not stopped, find the first (according to
the canonical order described inSection 5.2.1 <https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-26#section-5.2.1>) such
RtpTransceiver.
+ If no RtpTransceiver was found in the previous step, create
one with a recvonly direction.
*snip*
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to mozilla-...@lists.mozilla.org
Thanks -that explains it!
Do you know of any good guides on when to use addTrack() vs addTransceiver()?
Byron Campen
unread,
Aug 7, 2019, 8:52:08 AM8/7/19
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to SPChan, mozilla-...@lists.mozilla.org
I recommend using addTrack at all times unless you care about the
particulars of how send/receive tracks are paired up, or unless you have to
set the sendEncodings on the transceiver (eg; you want to use simulcast).