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

This indicates that the answer's omission of a codec does not allow the
offerer to deallocate resources that it has reserved for decoding that
type of stream (such as hardware).

Under this interpretation, if I reserve hardware for decoding VP8 and
H.264, and I get back an answer that indicates VP8 only, I cannot
deallocate my H.264 resources, since the answerer may choose to send me
H.264 anyway.

This contradicts something I think I've heard Cullen claim multiple
times, but I may have misunderstood Cullen.

On 04/08/2016 11:41 PM, Paul Kyzivat wrote:
> 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
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Surveillance is pervasive. Go Dark.