Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?

Christer Holmberg <> Sat, 18 February 2017 09:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 032971294EE for <>; Sat, 18 Feb 2017 01:29:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C0HbfQD8t-ib for <>; Sat, 18 Feb 2017 01:29:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 414641294D3 for <>; Sat, 18 Feb 2017 01:29:22 -0800 (PST)
X-AuditID: c1b4fb25-55bff70000001738-33-58a813eef5a3
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 82.30.05944.EE318A85; Sat, 18 Feb 2017 10:29:20 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Sat, 18 Feb 2017 10:29:17 +0100
From: Christer Holmberg <>
To: Roman Shpount <>, Ben Campbell <>
Thread-Topic: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?
Thread-Index: AQHSiGuZ0ghkIgIFz0iRXtxKyN1pOqFrt7kAgAAhoiD///XmgIAABf+AgAARKfD///H8AIAAEY/QgAGCcoCAAAjKgIABC/zw
Date: Sat, 18 Feb 2017 09:29:17 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4C0075FDESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7me4H4RURBhM6hS3md55mt5i6/DGL xYwLU5kdmD2WLPnJ5DFr5xMWj1tTCgKYo7hsUlJzMstSi/TtErgyDp3YxV7worji07lzbA2M Nwq6GDk5JARMJOY2djGC2EIC6xglpp2V6GLkArIXM0pcX7CHqYuRg4NNwEKi+582SI2IgKtE 1/fpYPXMAvISF5asYQKxhQWcJN68v8oKUeMsce5GEyOEnScxd8VfdhCbRUBV4srGl2A2r4Cv xP07D9ghdi1ilTi3bTozyC5OgUCJOR/iQWoYBcQkvp+CmM8sIC5x68l8JoibBSSW7DnPDGGL Srx8/I8VwlaSWLH9EtRt+RK7uvdB7RKUODnzCcsERpFZSEbNQlI2C0nZLKArmAU0Jdbv0oco UZSY0v2QHcLWkGidM5cdWXwBI/sqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMAoO7jlt+oO xstvHA8xCnAwKvHwfuBfHiHEmlhWXJl7iFGCg1lJhHeCwIoIId6UxMqq1KL8+KLSnNTiQ4zS HCxK4rxmK++HCwmkJ5akZqemFqQWwWSZODilGhjbdc+rnluZLfW3tThWW1RUqtz9UT1XjYDS 7/W/Nv06LVY+oZbtQa/50m93WHPOBnBVtq/0LdK8Zau3696jj5F8qndZJjeaL/H6ffxUwzJO /cvynlfcjN+4OKVn1c1uVM4rTW7YvVXuWMBO/uNedYUtv545XHpT9OhTdo7WtJ0Rc/reJy3x 01JiKc5INNRiLipOBAB+7Y4ArgIAAA==
Archived-At: <>
Cc: mmusic WG <>
Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?
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: Sat, 18 Feb 2017 09:29:24 -0000


I agree with Ben and Roman.

(Also, not too long ago we did discuss what is removed and what is kept in, and the draft reflects that discussion.)



From: Roman Shpount []
Sent: 17 February 2017 20:27
To: Ben Campbell <>
Cc: Christer Holmberg <>om>; mmusic WG <>
Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?

On Fri, Feb 17, 2017 at 12:55 PM, Ben Campbell <<>> wrote:
While it's the chairs' prerogative to judge consensus, it seems to me that the discussion has been somewhere between "we do need TCP/DTLS/SCTP" and "we might need it". Since the draft has already been approved by the IESG, we shouldn't make a material change unless we have a really good reason. I propose leaving it in.

As you have probably noticed I am strongly for leaving TCP/DTLS/SCTP in the draft, since things will break otherwise and draft will require substantial editing to recover.

On 16 Feb 2017, at 11:54, Christer Holmberg wrote:
Once nomination process is completed, it should be the selected, not the default >candidate.

When session is established or during ICE restart, multiple candidates are sent >in offer/answer and DEFAULT candidate must be used in the m= line.

Once nomination process is completed, only the currently selected candidate is >sent in offer/answer and this would be the candidate in the m= line. Resources >associated with other candidates, such as network ports or TURN allocations, >are typically released at that point, so there is no point to include them any >more.

Well, then we need to clarify the text (or remove the text completely, and simply refer to the ICE spec), because the ICE considerations section talks about offers and answers in general.

To be clear, are you talking about clarifying text in _this_ draft, or elsewhere?

Christer is talking about section 12.2 of the draft-ietf-mmusic-sctp-sdp. As the language stands right now, it is not incorrect, but is slightly confusing, since it is talking about default candidates for all ICE related offer/answer exchanges.  After ICE nomination process is completed, there is only one candidate left, so there is no default. In session descriptions that describe the session after ICE nomination is complete only one candidate is present, so there is typically no confusion about what goes into the m= line, but this is not spelled out in the draft. I will submit the PR and Christer can merge and resubmit the draft when he is back.

Roman Shpount