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:
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-26#section-5.10
*snip*
+ 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*
Best regards,
Byron Campen
On 8/6/19 10:01 AM, Richard Chan wrote:
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?
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
