[rtcweb] partial review of draft-ietf-rtcweb-sdp-01

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 30 May 2016 22:14 UTC

Return-Path: <prvs=39581f7060=pkyzivat@alum.mit.edu>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id ABE5212D695 for <rtcweb@ietfa.amsl.com>; Mon, 30 May 2016 15:14:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nQ5QxQNo0U7y for <rtcweb@ietfa.amsl.com>; Mon, 30 May 2016 15:14:47 -0700 (PDT)
Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu []) by ietfa.amsl.com (Postfix) with ESMTP id 463E012D147 for <rtcweb@ietf.org>; Mon, 30 May 2016 15:14:45 -0700 (PDT)
X-AuditID: 12074413-473ff700000008c7-e1-574cbb557bc6
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU []) by (Symantec Messaging Gateway) with SMTP id F3.7F.02247.55BBC475; Mon, 30 May 2016 18:14:45 -0400 (EDT)
Received: from Paul-Kyzivats-MacBook-Pro.local (c-73-218-51-154.hsd1.ma.comcast.net []) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u4UMEiVf007621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <rtcweb@ietf.org>; Mon, 30 May 2016 18:14:44 -0400
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <fe9c0380-1c43-9737-830d-747e986389a1@alum.mit.edu>
Date: Mon, 30 May 2016 18:14:53 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHIsWRmVeSWpSXmKPExsUixO6iqBu62yfcoPktp8Xaf+3sDoweS5b8 ZApgjOK2SUosKQvOTM/Tt0vgzujsnsVcMFezYvWkFtYGxp0KXYycHBICJhLnd/1j6mLk4hAS 2MooceTqRUYI5zeTxK9jN5lAqkQE1CUuP7zADmKzCWhJzDn0nwXEFhYwlpi65h9QAwcHr4C9 xO2v5iBhFgFVifUNn9lAbFGBNImz104wg9i8AoISJ2c+AWtlFjCTmLf5ITOELS+x/e0c5gmM PLOQlM1CUjYLSdkCRuZVjHKJOaW5urmJmTnFqcm6xcmJeXmpRbrmermZJXqpKaWbGCFhI7yD cddJuUOMAhyMSjy8DJ0+4UKsiWXFlbmHGCU5mJREeVtLgUJ8SfkplRmJxRnxRaU5qcWHGCU4 mJVEeC/vAsrxpiRWVqUW5cOkpDlYlMR51Zao+wkJpCeWpGanphakFsFkZTg4lCR4G0AaBYtS 01Mr0jJzShDSTBycIMO5pESKU/NSUosSS0sy4kGRFF8MjCWQFA/Q3jNge4sLEnOBohCtpxgV pcR5r+8ESgiAJDJK8+DGwpLBK0ZxoC+Feb+AVPEAEwlc9yugwUxAg+MzwAaXJCKkpBoY17Qf uLvlytbdZecffLVcbPmkegnn0jbn8iPWO45aKDakXjx9dV5Q1P0dIknv720UbtlzQnWdwQSz rljx3b4rLwe//n5ssc3Pf+Z31sUaN03vN786r3z7PJslqu5ny+onM3xx4PPLYfnxsyyA5d3B VecDXDaHznxzZZPtB3+OchbtK56Pa62KMpRYijMSDbWYi4oTAVaJD13hAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/iWNbUwusQmdbVRmKtBNh5P_lMMw>
Subject: [rtcweb] partial review of draft-ietf-rtcweb-sdp-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 May 2016 22:14:50 -0000

Ted asked if I would do a review of draft-ietf-rtcweb-sdp-01. I started, 
but it is taking a long time. I'm sending what I have so far to give you 
something to consider/work on.

In order to simplify this review for both me and readers, I will in 
general only mention an issue once, the first time I find it, and be 
silent on future occurrences of the same issue.

* In general in the examples it would be very helpful if you would 
include a blank line prior to each m-line. When reading these it is 
currently hard to find the m-lines, which is something needed when 
trying understand and compare things.

* Section 3:

I realize this is for a webrtc oriented reader, so I am trying to 
understand it from that perspective. Even so, I have trouble with 
classifying a=ice* as "Security Descriptions". Given the existing 
categories I would think they better belong in "Stream Description".

* Section 5.1:

    o  The term "Session" is used rather loosely in this document to
       refer to either a "Communication Session" or a "RTP Session" or a
       "RTP Stream" depending on the context.

This seems like a bad idea. It may be forgivable to mix communication 
session and RTP session in examples where a single bundle is used for 
all media, or there is only one m-line. But not if multiple m-lines 
aren't bundled, and not with RTP Stream.

OTOH, so far I haven't noticed any place where this is an issue.

* Section 5.2.1:

The SDP line-wrapping convention described in 5.1 isn't being used in 
the example.

Is there a reason for including the IP address in the a=rtcp line, when 
it is the same as the address in the c= line, which is the default?

Is there any expectation that a=ptime:60 only applies to opus? IIUC this 
should be interpreted ad applying to all codecs mentioned in the m-line. 
(There is no order-dependence among attributes within a single media 
section. AFAIK there is no way of specifying a separate ptime for 
individual codecs in an m-line.)

Use of sha-1 in a=fingerprint is about to become incorrect according to 
draft-ietf-mmusic-4572-update-03. That work is being driven by rtcweb, 
so I would think you would want to reflect it here.

The way tables are formatted in RFC format can make the examples 
confusing to readers: the label for table 1 falls exactly between the 
bottom of the table it describes and the following table. When viewed on 
a screen it is difficult to tell what each table is. I suggest tweaking 
the contents of the tables to make this clearer. E.g.,

    | SDP Contents - Offer             | RFC#/Notes                     |

In Table 2, the o-line has two spaces after the "-". It should only be one.

* Section 5.2.3:

Table 5 has ice and fingerprint attributes prior to the first m-line.

The m-line and associated attributes for the data channel is 
inconsistent with draft-ietf-mmusic-sctp-sdp-16. I think it ought to be 
(more or less):

m=application 56966 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4

If you really want to negotiate the usage of channel 1, then it also 
needs to include:

a=dcmap:1 subprotocol="chat";label="channel 1"

(Note: this presumes that "chat" is a registered subprotocol. It isn't!)

* Section 5.2.4:

This seems fine if Bob intends to send audio (e.g. MoH). If not then it 
would be better to answer a=inactive.

* Section 5.2.5:

Has there been any discussion of pros/cons of having DTMF on a separate 
m-line and a separate ssrc? If one or both ends actually think of DTMF 
as being part of another audio stream then this might present problems. 
This could especially be true for interoperation with telephony devices.

Is there anything in rtcweb that prevents having these on the same 
m-line and ssrc?

* Section 5.2.7:

Note that the BAS concept has been removed from Bundle, so you at least 
shouldn't refer to it. (You can still do the O/A if you want.)

In Table 14 (answer), why are ice attributes and fingerprints given 
separately (and differently) for the two m-lines? (Even though the ports 
and addresses are the same.) This is contrary to current bundle (-29) 

In the 2nd (BAS) offer there is a gratuitous change in ordering of 
several of the attributes. (Makes it difficult to see what has changed.) 
I also don't understand the other differences between the ice and 
fingerprints in audio and video, and between this and the first offer.

* Section 5.2.8:

This example *assumes* bundle support, and so uses the same addr/port 
for bundled m-lines. But this will fail badly if the assumption turns 
out to be wrong. When making this assumption you ought to use 
bundle-only in the initial offer to ensure nothing bad happens if the 
assumption of bundle support by answerer turns out to be wrong. AFAIK 
there is no downside to doing this.

Again this doesn't follow current bundle rules.


That's as far as I have gotten. (Slow going.) I'll try to get you more