Subject: [MMUSIC] Resolving IESG issues with RFC4566bis-35: "a=type" impact on media direction default

From: Paul Kyzivat <[email-masked]>
Date: Thu, 6 Jun 2019 12:56:56 -0400

I've been working to resolve the IESG issues with RFC4566bis-35.
I think I have resolved most of them, but I have a couple where I feel I 
need input from the wg. This is one of those:

"a=type" impact on media direction default:

While I was resolving a comment on Section 6.9 (a=type) I noticed what I 
think may be a new issue. The text says:

    "recvonly" should be the default for "type:broadcast" sessions,
    "type:meeting" should imply "sendrecv", and "type:moderated" should
    indicate the use of a floor control tool and that the media tools are
    started so as to mute new sites joining the multimedia conference.

    Specifying the attribute "type:H332" indicates that this loosely
    coupled session is part of an H.332 session as defined in the ITU
    H.332 specification [ITU.H332.1998].  Media tools should be started
    "recvonly".

This seems to imply that the *default* media direction 
(sendonly/recvonly/...) will vary depending on the value of the type 
attribute. Yet it isn't written in a normative manner. (This language 
dates back to RFC2327.)

My first reaction to this is that while it is written oddly the intent 
is only that these are suggestions for what the creator of the SDP 
should use. But then I also found language about this in section 6.7 
(Media Direction Attributes):

    If none of the media direction attributes is present at either
    session level or media level, "sendrecv" SHOULD be assumed as the
    default for sessions that are not of the multimedia conference type
    "broadcast" or "H332" (see below).

This language was not in RFC2327 - it was added in RFC4566. (Probably by 
me!)

My current thinking is that this is messed up. At the time of the 
writing in RFC2327 the use case in mind was announcements via SAP. This 
really doesn't work right in an offer/answer context.

I'm inclined to take the language about type-specific directionality out 
in both places. Or, if that can't be done for reasons of backward 
compatibility, then perhaps qualify it as only applying in the case of 
announcements.

I need feedback here!

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 7 Jun 2019 18:23:15 -0400

Anybody? Especially old timers (Mark, Van, Colin, Magnus, Henning) from 
RFC2327 days?.

	Thanks,
	Paul

On 6/6/19 12:56 PM, Paul Kyzivat wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 8 Jun 2019 17:44:17 +0000

Hi,

In my opinion, the default direction value is always "sendrecv" - no matter what the type value is. Type values can NOT override core SDP default values, IMO.

If  "recvonly" is to be used with "type:broadcast", then the endpoints need to make sure they negotiate "recvonly".

Regards,

Christer

On 08/06/2019, 1.23, "mmusic on behalf of Paul Kyzivat" <[email-masked] on behalf of [email-masked]> wrote:

    	Thanks,
    	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Jun 2019 11:34:12 -0400

Once more, I'm looking for insight, especially old timers (Mark, Van, 
Colin, Magnus, Henning) from RFC2327 days. If I don't hear anything I'm 
going to change the text so this "type-specific" defaulting of 
directionality no longer appears to be normative.

	Thanks,
	Paul