Re: [rtcweb] Followup to discussion of O/A and codecs from Friday session

[Taylor Brandstetter <[e-mail]>]

Actually, I see that Section 5.1 states:
>
> [T]he answerer MAY change formats in the middle of the session, making use of any of the formats listed [in the offer], without sending a new offer.
>
> So, does the combination of these statements imply that the answerer MUST
start by sending a format common to both the offer and the answer, but
later MAY switch to a format specific to the offer? That seems odd, but I
can't think of any other conclusion.

On Fri, Apr 8, 2016 at 3:36 PM, Taylor Brandstetter <[e-mail]>
wrote:

> I understand if that was the intent, but that's not what RFC 3264 seems to
> say. Both Section 6 and Section 8.3.2 state that the answer MUST send a
> codec listed in both the offer and the answer.
>
> So is RFC 3264 wrong? Or is my interpretation of the rule wrong?
>
> On Fri, Apr 8, 2016 at 3:27 PM, Roman Shpount <[e-mail]> wrote:
>
>>
>> On Fri, Apr 8, 2016 at 6:18 PM, Taylor Brandstetter <[e-mail]>
>> wrote:
>>
>>> In Section 6 of RFC 3264:
>>>
>>>> The answerer MUST send using a media format in the offer that is also listed in the answer
>>>>
>>>> So, if X offers A and B, and Y answers B, how would Y be able to send
>>> A? It's not in both the offer and the answer.
>>>
>>>
>> A does not have to be in both offer and answer. Offer/Answer is
>> declarative capability exchange with each side declaring what it is willing
>> to receive. It is not intended to pick a single codec. Negotiation is
>> considered successful if there is at least one common codec, but there are
>> no other requirements. Each party can send any codec remote party is
>> willing to receive and can switch between the codecs remote party supports
>> at any time. So in this example, Y can not only send A but can switch
>> between A and B at any time.
>>
>> Also, answer can include codecs which were not present in the offer, so
>> the whole situation can be reversed.
>> _____________
>> Roman Shpount
>>
>>
>
>