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

[space88man]

trafficstars

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