Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-mmusic-sctp-sdp-23: (with DISCUSS)

"Mirja Kuehlewind (IETF)" <> Mon, 20 February 2017 11:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 29A0B129999 for <>; Mon, 20 Feb 2017 03:12:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5IjEF2_j0ZOD for <>; Mon, 20 Feb 2017 03:12:02 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1D05A1299AA for <>; Mon, 20 Feb 2017 03:12:00 -0800 (PST)
Received: (qmail 25854 invoked from network); 20 Feb 2017 12:05:18 +0100
Received: from ( by with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 20 Feb 2017 12:05:18 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: "Mirja Kuehlewind (IETF)" <>
In-Reply-To: <>
Date: Mon, 20 Feb 2017 12:05:37 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Roman Shpount <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: "" <>, "" <>, Ben Campbell <>, "" <>, The IESG <>, Christer Holmberg <>, "" <>
Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?=
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Feb 2017 11:12:03 -0000

Hi Roman,

I think the problem is that someone who would not want to use ICE would not look at RFC6544. This means at least this part of RFC6544 is missing as general guidance in this draft:

"For media streams that are not RTP-based and do not normally use 
   RFC4571, the agent treats the media stream as a byte stream and assumes
   that it has its own framing of some sort, if needed.  It then takes
   an arbitrary number of bytes from the byte stream and places that as
   a payload in the RFC 4571 frames, including the length."

Usually duplicating text is not recommendable. However it this case it might be the easiest solution if you want to keep the document generally applicable even if you don’t use ICE. 

Also I’m not sure if the ICE part is fully specified. In your previously mail you wrote

"As far as TCP/DTLS/SCTP transport tag is concerned, please note that ICE end points are supposed to send a re-INVITE after nomination process is completed with the selected candidate address in the m= line. So, if tcp candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP transport tag in the m= line. Also, any offers/answers after the ICE nomination is complete, are supposed to send the currently selected candidate in the m= line, which will also be TCP/DTLS/SCTP in case tcp candidate is selected.“

From what I understood from ekr, you might not in any case send an re-invite; but maybe I understood this wrongly. I guess that could also be further explained in the draft.


> Am 20.02.2017 um 10:49 schrieb Ben Campbell <>om>:
>> On Feb 19, 2017, at 5:46 PM, Roman Shpount <> wrote:
> [...]
>> We are happy to add any informational content to describe the implications of running SCTP on top of TCP, but we would prefer not to redefine how ICE operates (including framing used for ICE TCP) in this draft. I think, generic ICE procedures belong in ICE related drafts.
> I agree in principle; this draft is about signaling, not the media stream itself. But Mirja's comments suggest that the referenced specs may not fully describe how the stream works. Is there anything else we could reference (e.g.  RTCWEB data-channel or transports drafts) that would help clarify?  (Please feel free to argue that the referenced docs do in fact describe things sufficiently for the purposes of this draft, if you believe that to be true :-) )
> Thanks,
> Ben.