Send only / Receive only with WebRTC

[Pierrick Grasland]

Hello,

What is the best way to declare a peerconnection as sendonly / receiveonly.

I know that I can do that in SDP for each media line, but does getUserMedia offer a better API ?

Regards,

[Harald Alvestrand]

In theory, if you set the constraint offerToReceiveVideo=false and offerToReceiveAudio=false, you should get a sendonly peerconnection.

Conversely, if you set offerToReceiveVideo=true and offerToReceiveAudio=true, and attach no outgoing tracks, you should get a receiveonly peerconnection.

In practice, I doubt that this particular case has been tested. What's the use case in which it is important?

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Pierrick Grasland]

I will try this.

My use case is "look at this". I send an IM to a friend, and I can share in real time what is happening.

I just want to share the video, so send only.
He don't want to share his video, so receive only.

But, it's more a pretext to try some new setup with WebRTC :)

[Lorenzo Miniero]

I'm working on something similar as well, and trying to only receive something does not work.

Specifically, if I don't issue a getUserMedia (as I'm not interested in the user media) and set the OfferToReceiveAudio/Video contraints to true, no candidates are gathered and the onicecandidate callback is never called. Trying to generate the SDP anyway of course results in an invalid session description, as everything is there except what is really needed, that is the candidates themselves.

The same works in Firefox instead.

Lorenzo

[bryand...@gmail.com]

Harald -- I think that "Webinar" is a use case that should receive testing.  In a webinar, most people will only receive the presenter's transmission.  Do I understand correctly that uni-directional connections do not receive any testing?

Lorenzo - In my application, every PC is either send only (if you have the mic) or receive only (if you do not).  It seems to work well for me.  In my case, the offer comes from a MCU.  That offer has a single candidate.  So I never have to worry about candidate gathering on the browser side.  The browser just connects to the provided candidate.

Regarding send/recv only -- I have found that simply not adding a local stream will make the PC receive only.

[Brian Baldino]

If you don't call getUserMedia and attach any streams, then I believe you need to set OfferToReceiveAudio/Video to true to get anything.  I've got an app doing this (not attaching any local streams but setting OfferToReceiveAudio/Video to true) that is working fine in Chrome.

[Lorenzo Miniero]

Bryan -- that's the same with my MCU/gateway, with the problem being that the SDP the browser generates has no candidate at all, and ports in the media lines are set to 1, which makes me think media are not properly set up in the browser side.

To address Brian's point, actually I do set OfferToReceiveAudio/Video to true (bad wording in my last post I'm afraid). Setting them to true but not calling getUserMedia got me no candidates, but if you both say it's supposed to work it's likely I did something wrong in the JS code. Thanks for the heads-up, I'll dig deeper as soon as I get back to work.

Lorenzo

[bryand...@gmail.com]

Lorenzo -- I think I understand what you are saying.  It's just that I never looked in the answer SDP to get the port number.  I just wait for the stun binding request to arrive at the server and use the source IP/port of the packet.  Therefore, I never need to see candidates in the answer.

[Lorenzo Miniero]

The problem is that, if media are not properly set up in the browser, the browser won't even start sending connectivity checks towards the gateway. I've tried playing again with the JavaScript and I'm still getting the same: if I don't call getUserMedia, but directly go and create a RTCPeerConnection instance with the OfferToReceiveAudio and OfferToReceiveVideo constraints set to true, I get no error, but the onicecandidate callback is never called, which means the browser is not gathering candidates for the audio and media lines. If I try to force a createDescription anyway, I get an almost complete SDP, and I say almost because, as I anticipated a couple of days ago, there is no candidate to be seen (just ice-ufrag and ice-pwd attributes) and the ports in the media lines are set to 1.

As it is, this is a useless SDP, because the gateway wouldn't be able to do anything with it: no negotiation, no candidate pairing, no media.

I'm starting to think this is a bug in Chrome, because as I said this works as expected in Firefox. Brian and Bryan, are you sure it is working for both of you in the same scenario? that is, are you actually NOT calling getUserMedia either, or are you calling it anyway just in presence of no mic/webcam on the client side?

Thanks,

Lorenzo

[bryand...@gmail.com]

Yes, I'm certain that it works to receive media without calling getUserMedia.  OfferToReceive(Audio|Video) is not applicable since I am not asking the browser to create an offer, only an answer.  

Offer from MCU: contains m-lines with port(s), a=ssrc lines and single candidate

Answer from browser: capture/signal ice-ufrag, ice-pwd, and crypto|fingerprint. candidates are irrelevant. 

The important part here, I think, is that createOffer is never called by chrome or firefox.

[胡啟明]

hi, Bryan:

  Could you please share the source code???

  Very thank's

Bryan於 2013年9月17日星期二UTC+8上午12時16分47秒寫道：

[chinahu]

i also need do it. but i don't need do it in browser.

i can modify webrtc source code to complete it.

if you are interested it. you can contact me.

[Sun Flower]

If you not adding a local stream,How can you called createOffer???

在 2013年9月14日星期六 UTC+8上午12:00:58，Bryan写道：