- 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. ./Suhas Sent from my iPad On Apr 2, 2013, at 12:44 AM, "mehmet ozisik" <mehmetzsk@gmail.com<mailto:mehmetzsk@gmail.com>> wrote: Hi, 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. OfferToReceiveVideo 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 : https://code.google.com/p/webrtc/issues/detail?id=1553&thanks=1553&ts=1364545330 Regards Mehmet
Received on Tuesday, 2 April 2013 08:30:32 UTC