webrtc-from-chat: addTransceiver: causes an extra video-offer/video-answer from callee
space88man opened this issue · 0 comments
The updated signalling in webrtc-from-chat (specifically addTrack -> addTransceiver) causes onnegotiationneeded to be fired on the callee and another round-trip of video-offer/video-answer.
Is this behaviour expected and correct?
It seems expensive to require another round of video-offer/video-answer. Replacing addTransceiver with addTrack restores the old behaviour.
The difference is in the Answer SDP:
- addTrack puts
a=sendrecv - addTransceiver puts
a=recvonly
Presumably a=recvonly is the reason why the callee initiates the video-offer round-trip. I have seen recvonly mentioned in the posts on Advancing WebRTC; is this behaviour mandatory now?
Old signalling (addTrack)
caller: sends video-offer
callee: sends video-answer
=== call is connected ===
New signalling (addTransceiver)
caller: sends video-offer
callee: sends video-answer (call not connected yet)
callee: onnegotiationneeded is fired
callee: sends video-offer
caller: sends video-answer
=== call is connected ===