[MMUSIC] Review of 4566bis

Christer Holmberg <christer.holmberg@ericsson.com> Sun, 31 May 2015 13:38 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 5183E1A1BE9 for <mmusic@ietfa.amsl.com>; Sun, 31 May 2015 06:38:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id TOM1COxlIqfs for <mmusic@ietfa.amsl.com>; Sun, 31 May 2015 06:38:21 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F461A1BD1 for <mmusic@ietf.org>; Sun, 31 May 2015 06:38:20 -0700 (PDT)
X-AuditID: c1b4fb25-f79b66d000001131-71-556b0eccb051
Received: from ESESSHC011.ericsson.se (Unknown_Domain []) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 88.31.04401.CCE0B655; Sun, 31 May 2015 15:38:20 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([]) by ESESSHC011.ericsson.se ([]) with mapi id 14.03.0210.002; Sun, 31 May 2015 15:38:19 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: Review of 4566bis
Thread-Index: AdCUW7+SbP6HhSmGSPuNOkn7YTpkVg==
Date: Sun, 31 May 2015 13:38:19 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D873B05@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D873B05ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvre4ZvuxQg+l/ZCz+7U2ymLr8MYsD k8eSJT+ZPL5c/swWwBTFZZOSmpNZllqkb5fAlXG+Ib3g0A7Giu0L97M3MH6az9jFyMEhIWAi 0bDKp4uRE8gUk7hwbz1bFyMXh5DAUUaJIzffMkE4ixkl9rfdZAdpYBOwkOj+pw3SICKgLvF1 bw8ziM0s4Chx9tZ2JhBbWEBKYuOiJcwQNfIS7VuvsUDYehKdt7awgIxhEVCVuD7VAiTMK+Ar sfnJd3YQmxHohu+n1jBBjBSXuPVkPhPEbQISS/acZ4awRSVePv7HCmErSSy6/RmqPl9i8sku doiZghInZz5hmcAoPAvJqFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGEWL U4uTctONjPVSizKTi4vz8/TyUks2MQJj5+CW36o7GC+/cTzEKMDBqMTDq5CdFSrEmlhWXJl7 iFGag0VJnNezKyRUSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2Nxb3LdZt/YBs9KlVUTbjyt N4g4f37bDa/QE5c0ph99ucFNY3vwkjQRofkBPDtaXV0UGL+9+vxgn5oqw9E3ohdnyd07/nHy hB6rN6q895fO9F+ZG9S+diWv8w/pmTJzOl9qfF27rszTYtIR8S1ciYaFXP/ctEKDFn4WeNTP JRabubY5Qiyiw1eJpTgj0VCLuag4EQBbQ8cOfgIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/W82Ba0vOboPUqbfWiZ0yJZqZMTQ>
Cc: "mmusic-chairs@tools.ietf.org" <mmusic-chairs@tools.ietf.org>
Subject: [MMUSIC] Review of 4566bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 May 2015 13:38:26 -0000


Below is my review of the 4566bis-14 document.



There has been some discussions on the list whether we should remove some of the attributes which are either semantically unclear and/or nobody is using.


I think the draft should be checked for consistent terminology. For example, sometimes "SDP session description" is used, and sometimes only "session description".


The "Session Announcement Protocol" enhancement is needed only within the first occurrence. After that "SAP" is enough.

Section 4.1:


s/the transport protocol/the media transport protocol

Section 4.3:


My suggestion would be to remove the whole section. I can't remember any discussion where one would have used private vs public sessions. The Security Considerations should then cover encryption etc of SDP information.

Section 4.4:


The text says:

"A session description should convey enough information to decide whether or not to participate in a session."

I don't think that is true - at least not when SDP is used together with a protocol like SIP. SDP describes the media associated with the session - but there are many other properties which are used to determined whether to participate in a session.

Section 5.2:


The text says that the o= line contains the address of the host.

But, we've had discussions about not providing the host address once the initial SDP offer is sent, so I wonder whether some relaxing text would be needed here.

Section 5.4:

The text says:

"There MUST be at most one session-level "i=" field per session description, and at most one "i=" field per media."

...and later:

"A single "i=" field MAY also be used for each media definition."


In the first sentence, I guess it should say "field per media description/definition"?


Is the second sentence really needed? What is the difference from the first sentence?


Similar to e.g. the "c=" line, I guess it would be useful to say that, unless an media level "i=" line is defined, the session level "i=" line applies to that media description.

Section 5.5:


The text says:

"...but if it is present it MUST be specified before the first media field."

Is that text needed? Session level attributes are always specified before the first media field, aren't they?

Section 5.6:


The text says:

"Note that the previous version of SDP specified that either an email field or a phone field MUST be specified, but this was widely ignored. The change brings the specification into line with common usage."

In my opinion, any reference to the previous version of SDP, and the justification for change, should be covered in section 10, only in section 10, and nowhere else but in section 10 :)


The text, talking about the name of the person, says:

"This MUST be enclosed in parentheses if it is present."

But, then, when the text talk about the name quoting convention, the name is given without enclosed parentheses.

So, I think some re-wording would be needed.

Section 6:


In some of the sub-sections, there is text saying:

"This can be a session-level attribute or a media-level attribute."

I think such text can be removed, as it is already indicated in "Usage level".


In some of the sub-sections, it is indicated that a media-level attribute value overrides a session-level attribute value. As far as I know, that applies to all attributes (that can be present both on the session-level and media-level), so there should be a generic statement about that.

This is similar to the comment on the c= line.

Section 6.7:


The text says:

   "If any one of these appears in a media section then it applies for
   that media section.  If none appear in a media section then the one
   from session level, if any, applies to that media section."

There should be a general statement in the draft about session level information applying to the media level.

Section 6.7.4:


The text says:

"Note that an RTP-based system SHOULD still send RTCP, even if started inactive."

It should be clarified that this applies if RTCP is used to begin with.

Also, is there a reason why we couldn't use MUST instead of SHOULD?

Section 6.11:

The text says that the attribute "specifies the language" of the session description.

There has been some confusion about what that really means, so I think it would be good to clarify that it applies to any textual information that may be provided within the description.

It would also be good to explicitly indicate that the attribute is not related to languages used in the actual media streams.

Section 6.12:

The text says:

"...., in which case the order of the attributes indicates the order of importance of the various languages in the session or media, from most important to least important."

First, I thought that attribute order has no meaning.

Second, what does "importance of the various languages" really mean? The language is what it is, and the participants decide what is important.

Section 8.2.3:

The text says:

"Formats cover all the possible encodings that might want to be transported in a multimedia session."


I think the "might want to be transported" is confusion, and needs to be re-written.


The fmt does not contain the complete list for the session - only the list for the associated media description.