webrtc-from-chat: addTransceiver: causes an extra video-offer/video-answer from callee

[space88man]

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 ===