W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2013

Re: sendonly streams in the offer

From: Suhas Nandakumar (snandaku) <snandaku@cisco.com>
Date: Tue, 2 Apr 2013 08:29:52 +0000
To: mehmet ozisik <mehmetzsk@gmail.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <03FAA6AA-1418-4E3A-A5DC-54CD98EF9A2C@cisco.com>
If OfferToReceiveVideo is false, I would expect the offer to be sendonly.


Sent from my iPad

On Apr 2, 2013, at 12:44 AM, "mehmet ozisik" <mehmetzsk@gmail.com<mailto:mehmetzsk@gmail.com>> wrote:


I would like to ask one question regarding starting the session as sendonly.
In the offer I was setting OfferToReceiveVideo to false (it is true for getUserMedia),
then I was checking the outgoing sdp but I was seeing the m=video line as sendrecv, I was expecting to see as sendonly according to your spec and sdp standart.

This is an enum type constraint that can take the values "true" and "false". The default is a non mandatory "true" for an RTCPeerConnection object that has a video stream at the point in time when the constraints are being evaluated and is non mandatory "false" otherwise.

In some cases, an RTCPeerConnection may wish to receive video but not send any video. The RTCPeerConnection needs to know if it should signal to the remote side whether it wishes to receive video or not. This constraint allows an application to indicate its preferences for receiving video when creating an offer.

this is some info from RFC 3264 :

5.1 Unicast Streams

   If the offerer wishes to only send media on a stream to its peer, it
   MUST mark the stream as sendonly with the "a=sendonly" attribute.

I have asked this issue to google developpers, but  was informed that it is not clear and suggested to ask this question to you.

Could you please inform me what would the correct behaviour be in such case?

PS : this is the issue created within google's issue tracker :



Received on Tuesday, 2 April 2013 08:30:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:33 UTC