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

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.

On Fri, Apr 8, 2016 at 3:01 PM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> 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.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>