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

[Paul Kyzivat <[e-mail]>]

During the rtcweb session today, while discussing (I think) JSEP issue 
#247 (Document what should happen when there are no matching codecs in 
answer), there was a question about happens in a particular case. I 
think it was:

- X offers codecs A and B (sendrecv)
- Y answers codec B (sendrecv)

The question was whether Y may use codec A when sending to X. Jonathan 
gave an answer I disagreed with and we had a chat about it. He got an 
action item to follow up afterwords, then he asked if I would do it.

As I read RFC3264, the answer is:

Yes, in the above case Y may send A to X.

Then a subsequent scenario came up: what would happen if Y has a need to 
send a (re)offer? Wouldn't this result in an inability to send using A? 
(Let's assume that Y is unable/unwilling to *receive* A but can send it, 
even though this is a weird case.)

- Y offers codec B (sendrecv)
- X answers codec B and A (sendrecv)

This *is* permitted by 3264. And in this case Y will be allowed to 
continue sending using codec A.

Relevant pieces of 3264 supporting this interpretation:

- section 5.1 (Generating the Initial Offer/Unicast Streams):

    ... If multiple formats are listed, it
    means that the offerer is capable of making use of any of those
    formats during the session.  In other words, the answerer MAY change
    formats in the middle of the session, making use of any of the
    formats listed, without sending a new offer.

- section 6.1 (Generating the Answer/Unicast Streams):

    ... For streams marked as sendrecv in the answer,
    the "m=" line MUST contain at least one codec the answerer is willing
    to both send and receive, from amongst those listed in the offer.
    The stream MAY indicate additional media formats, not listed in the
    corresponding stream in the offer, that the answerer is willing to
    send or receive (of course, it [the answerer] will not be able to
    send them at this time, since it was not listed in the offer).

- section 8.3.2 (Changing the Set of Media Formats):

    The list of media formats used in the session MAY be changed.  To do
    this, the offerer creates a new media description, with the list of
    media formats in the "m=" line different from the corresponding media
    stream in the previous SDP.  This list MAY include new formats, and
    MAY remove formats present from the previous SDP.  ...

    The corresponding media stream in the answer is formulated as
    described in Section 6, and may result in a change in media formats
    as well.  Similarly, as described in Section 6, as soon as it sends
    its answer, the answerer MUST begin sending media using any formats
    in the offer that were also present in the answer, and SHOULD use the
    most preferred format in the offer that was also listed in the answer
    (assuming the stream allows for sending), and MUST NOT send using any
    formats that are not in the offer, even if they were present in a
    previous SDP from the peer.  Similarly, when the offerer receives the
    answer, it MUST begin sending media using any formats in the answer,
    and SHOULD use the most preferred one (assuming the stream allows for
    sending), and MUST NOT send using any formats that are not in the
    answer, even if they were present in a previous SDP from the peer.

I'm not too clear on how this relates to issue #247, but at least I hope 
we can agree on what 3264 says.

	Thanks,
	Paul