Re: [rtcweb] About the current JSEP-06 draft

[Justin Uberti <[e-mail]>]

To make sure I understand, can you verify the examples I give below?

1 MST + no options: (unchanged)
m=video X
a=sendrecv
a=msid:foo

1 MST + N=0: (new)
m=video X
a=sendonly
a=msid:foo

1 MST + N=1: (unchanged)
m=video X
a=sendrecv
a=msid:foo

1 MST + N=2: (unchanged)
m=video X
a=sendrecv
a=msid:foo
m=video Y
a=recvonly

Based on this, I would also change the meaning of OfferToReceiveVideo:true
to mean max(1, # of MSTs), since I think the N=1 behavior would be
unexpected in the 2 MST case.


On Wed, Jul 16, 2014 at 6:20 AM, Martin Ekblom <[e-mail]>
wrote:

> Hi Justin,
>
> I entirely agree with you. Each media stream will have it's own m= line
> and extra m= lines with recvonly directional attributes should be added for
> extra streams wanted. This allows for accepting more streams than sending,
> which is entirely in line with the SDP RFCs.
>
> However, the current JSEP draft misses one small fine point. Reversely, it
> should also (MUST if you read the relevant RFC) allow for sending more
> streams than it wants to receive, ie the opposite case of the above, and
> then send m= lines with the directional attribute set to sendonly. RFC 3264
> is very clear with this: 'If the offerer wishes to only send media on a
> stream to its peer, it MUST mark the stream as sendonly with the
> "a=sendonly" attribute.'
>
> Also as part of the SDP offer/answer exchange the medias that both agents
> agree not to use should have the m= line set to inactive, ie when the
> offerer states that it wants to receive a media stream with directional
> attribute recvonly and the answerer indicates that it is unable to send
> that media by setting the directional attribute to inactive (this media
> stream will not be sent in any direction). The ordering and the number of
> media lines should not change during the offer/answer exchange.
>
> Thus I suggest the following changes. Add an item to the list in 4.1.2
> (preferably in the middle):
>
>
>
> *To convey the intention of sending a media type which is not
> expected in return (e.g., a video presentation which does not wish      to
> receive video).*
>
> Section 5.2.3.2. would be changed as follows:
>
> If the "OfferToReceiveVideo" constraint is specified, with a value of
>    "N", the offer MUST include N non-rejected m= sections with media
>    type "video", even if fewer than N video MediaStreamTracks have been
>    added to the PeerConnection. This allows the offerer to receive
>    video, including multiple independent streams, even when not sending
>    it; accordingly, the directional attribute on the video m= sections
>    without associated MediaStreamTracks MUST be set to recvonly. If
>    this constraint is specified in the case where at least N video
>    MediaStreamTracks have already been added to the PeerConnection, or N
>    non-rejected m= sections with media type "video" would otherwise be
>    generated,
>
> *the offer MUST set the directional attribute to sendonly    for the
> MediaStreamTracks in the video m= section for the remaining
> MediaStreamTracks of type video beyond N.* The directional attribute
>    for MediaStreamTracks of type video not set to sendonly or recvonly
>    SHOULD be set to sendrecv unless inactive. For backwards compatibility,
>    a value of "true" is interpreted as equivalent to N=1
> *and a value of   * *"false" is i**nterpreted as equivalent to N=0.*
>
> The change in the paragraph above is mostly clarifying what previously was
> left unexplained with the words "*it has no effect*" and not touching on
> how to interpret a value of false. Section 5.2.3.1. would need to be
> changed in a similar way.
>
> These changes would be make it comply with RFC 3264 and 4566 and also be
> in line with the somewhat unclear w3c spec on WebRTC.
>
>
> Regards,
> Martin Ekblom
> Front-end Developer
> www.icewarp.com
>
>
> ------------------------------
> -----Original Message-----
> From: "Justin Uberti" <[e-mail]>
> To: [e-mail], [e-mail]
> Date: 14/07/2014 04:20
> Subject: About the current JSEP-06 draft
>
>
>
>
> Adding [e-mail], the right mailing list for this.
>
> This behavior (of OfferToReceiveAudio/Video) was added to be conformant
> with Unified Plan, where each media stream requires its own m= line, and
> therefore the offerer needs the ability to advertise additional m= lines if
> it needs to receive more media streams than it is offering.
>
> I agree that the w3c spec's handling of this topic could be clarified.
>
>
> On Wed, Jul 2, 2014 at 2:37 AM, Martin Ekblom <[e-mail]>
> wrote:
>
>> Hi,
>>
>> I believe there is a conceptual misunderstanding in section 5.2.3.1. and
>> 5.2.3.2. It seems to contradict the requirements of RFC 3264 / 4566 (SDP
>> offers and answers) and not be in line with the WebRTC draft. I would like
>> to contribute to improve or clarify this section, or in case I'm mistaken
>> confirm this.
>>
>> Is this the appropriate mailing list to disuss this?
>>
>> Regards,
>> Martin Ekblom
>> Front-end Developer
>> www.icewarp.com
>>
>>
>>
>
>
>
>
>
>
>
>
>
>