Re: sendonly streams in the offer

On 4/3/13 2:00 PM, Cullen Jennings (fluffy) wrote:
>
> I agree with Suhas,
>
> But I think we should rethink this whole OfferToReceiveVideo thing.
> Say you wanted to receive 2 video stream but not offer any? How would
> one do that. I think the best way would be to create some tracks
> attached to a video element and add them to the PeerConnection. Or
> something along theses lines.

I'm not sure we need that kind of functionality. The current APIs are 
for the sender; so the sending app decides (what it adds to PeerConnection).

If a certain application would like the receiver to decide, it could use 
app internal signaling (the receiving app tells the sending app what it 
wants, and the sending app adds that to the PeerConnection).

>
>
> On Apr 2, 2013, at 2:29 AM, Suhas Nandakumar (snandaku)
> <snandaku@cisco.com> wrote:
>
>> 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>
>> 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 Wednesday, 3 April 2013 13:11:07 UTC