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

["Martin Ekblom" <[e-mail]>]

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 interpreted 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