Re: OfferToReceive in CreateAnswer

On 10/28/2012 07:49 AM, Cullen Jennings (fluffy) wrote:
> On Oct 26, 2012, at 13:47 , Harald Alvestrand <> wrote:
>> Wearing my implementor's hat, reporting on a discussion:
>> The text in section 11.1 about OfferToReceiveAudio and OfferToReceiveVideo talks about offers, but doesn't say what should be done with answers. If the language was interpreted exactly as it stands, the result of doing a CreateAnswer without adding any streams would be to create an SDP that rejected the Audio and Video m-lines - which doesn't make much sense.
>> A reasonable interpretation should be this (all refer to the responding RTCPeerConnection):
>> - When no OfferToReceive* is present, and no streams are added, all m= lines from sender are accepted. (Query: should they be accepted in a=recvonly mode?)
>> - When OfferToReceive* is nandatory false, and no streams are added, the corresponding m= line is rejected (by setting the port number to 0).
>> - I don't think we can add m= lines in an answer, so when the incoming offer has no video line, and the OfferToReceiveVideo is true, the answerer fires negotiationneeded immediately after returning to the no-outstanding-offer state, so that the answerer can offer an upgrade to add video.
>> Does this make sense? If so, can it be added?
>>               Harald
> What other ways could we expire to solve this than using OfferToReceive?
The problem raised is what OfferToReceive means when you're in answer 
mode..... the absolutely simplest resolution is to say "OfferToReceive* 
is meaningless when you answer and has no effect".

But the text should be clear about what the effect is.


Received on Sunday, 28 October 2012 07:48:08 UTC