Undefined 'transceiver' object used in 'dispatch a receiver' steps

[adam-be]

Step 7 in https://w3c.github.io/webrtc-pc/archives/20160215/webrtc.html#dispatch-receiver

[alvestrand]

@pthatcherg this is a place where the transceiver concept isn't integrated. Can you take a look?

[mparis]

Hello,
I do not know if we should discuss this here or in #623.

My team and I decided to implement the next solution:
if there is not any transceiver to manage a remote MediaStreamTrack, an event is triggered to notify the developer if he wants to create a new transceiver to manage the incoming media.

This event is like an asynchronous way of adding a new transceiver [1-addTransceiver].
For now, in our implementation the event only asks asks for a RTCRtpTransceiverInit:

• If it is NULL, the media will be rejected
• If not, it will be accepted and managed

It is working, but In next iterations we will take into account the info of RTCRtpTransceiverInit (RTCRtpTransceiverInit .receive], RTCRtpTransceiverInit .send, etc.) to reject the remote media, accept only for receiving, etc.

I hope this info can help us make a decision on this issue ;).

Best regards!!

Refs
[1-addTransceiver] https://w3c.github.io/webrtc-pc/archives/20160215/webrtc.html#widl-RTCPeerConnection-addTransceiver-RTCRtpTransceiver-MediaStreamTrack-DOMString-trackOrKind-RTCRtpTransceiverInit-init

[alvestrand]

This seems like a wrong approach to me. The required owning transceivers should be created by the platform before the MediaStreamTrack is made visible to the application, and there definitely shouldn't be two ways to do it (when the transceivers and tracks are the result of setRemoteDescription, only one thing should happen).

This needs to be made clear. Tagging @pthatcherg @taylor-b .

[stefhak]

I agree to Harald here. The transceivers should be created by the platform.

[mparis]

Yes, in my proposal the transceiver is created by the platform (not by the developer), but it asks the developer if he wants to accept the media (so the transceiver is created) and also asks for the configuration (RTCRtpTransceiverInit) to create the transceiver, if not how the platform knows which configuration to apply?

[taylor-b]

JSEP already talks pretty thoroughly about how transceivers are created as a result of setRemoteDescription. If possible, an existing one created by addTrack will be used; otherwise one will be created with an inactive RtpSender and active RtpReceiver. And if you want to modify the properties after-the-fact, I was pretty sure we planned to have a direction attribute knob somewhere. Or you can call stop on the new RtpTransceiver to reject the media entirely.

So, I don't think we need to define any new logic, we just need to clean up this section and reference JSEP.

[jcaden]

@taylor-b Following your example, in case you create just a RtpSender (no RtpRecevier), how is the user notified about its existence? I mean, if you get an active RrpReceiver, you will receive an ontrack event, but for the inactive RtpSender I can't see any notification. This means that the developer could not be aware of this sender to add a track to it. Is there some way to get this sender without having to pool for all the senders?

[taylor-b]

A sender will only be created in this way as a result of setRemoteDescription. So you could check the list of transceivers before and after setRemoteDescription completes and see if one was added; no need for polling.

I agree though, it would be useful to have an independent ontransceiver callback for convenience, similar to ontrack.

[jcaden]

Thanks for the reply.

+1 for ontransceiver callback It's more efficient that having to compare the lists every time you call setRemoteDescription

[alvestrand]

Seems that we're clear on expected behavior.
If people feel that ontransceiver is a good thing to add, please add a new bug asking for it.