Re: [MMUSIC] JSEP Issue #394: What appears in m= lines.

Paul Kyzivat <> Tue, 10 January 2017 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CF661297E8 for <>; Tue, 10 Jan 2017 11:27:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.899
X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8h4D0PvUzyv3 for <>; Tue, 10 Jan 2017 11:27:57 -0800 (PST)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 52F7C1297ED for <>; Tue, 10 Jan 2017 11:27:57 -0800 (PST)
Received: from ([]) by with SMTP id R25Mcg6yg9XRkR25McyEmO; Tue, 10 Jan 2017 19:27:56 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20161114; t=1484076476; bh=Fs7luZtmLSrv3qKK9nWCUwYWSFl2kErDvG9pVjCD79c=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=a8dI8LVTFHHmWTnNLNbUq/wwMcGJyF/DyfpAjvyZganjHcQjEP4t9F6J8lX6MZM1G b9XPZlhHLGHaiBdjGwZzhjAPbT+U+tcqvuThd8UsrQZFTIrdNtra1nbpzsjNnHUpqz QOZd4+7bI01/D4/Zk10aFfuDk9GJuI+D7AK0pSkd46hyP+lXN/yT8mG58sqYlUq0Ax NSQqJC777kxYWvTxltktEp5wGnlOYw9TC7lU/nYgK/Mkyzgl9BfaXe1TQ5mejhDjNq 8I86V1EKl8c0RsjGrGD+64fgnz3ekfQsGsSxVRaLQO4PHASwIcodiKa6lHxmlnFc1T AEFE98qtEXHxQ==
Received: from [] ([]) by with SMTP id R25LcKCf2OblgR25MchlyT; Tue, 10 Jan 2017 19:27:56 +0000
To: Roman Shpount <>
References: <> <> <> <> <> <>
From: Paul Kyzivat <>
Message-ID: <>
Date: Tue, 10 Jan 2017 14:27:55 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfELgr0ClBTk45LmbVIefwtVGI8gEFLEZG0UkoiytEhDdCG1bv/APYa1PPhks+8t/fXDgHF9q6hvyEM4ygxYJF9WP6T72u1WLslTYwAk28pT2EJW+DGs8 oyOyOD2Xm1nVleKH+c1WISnp5KOKM6pM5cQAg0MqTs+uYhNnHNTcoYiDmfSvYSIXfClLsTsagtWCRIpHwsnjuxMNJ/GrtM4E5Us=
Archived-At: <>
Cc: "" <>
Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines.
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: Tue, 10 Jan 2017 19:27:59 -0000

On 1/10/17 1:08 PM, Roman Shpount wrote:
> We can do the registration for ICE transport tag in ICE-SIP-SDP. ICE tag
> will indicate that ICE is required for this offer/answer exchange to
> succeed. When ICE transport tag is used, c= and m= SDP line would carry
> no address information and will contain "c=IN IP4" and port 9 in
> the m= line. Also, if ICE/ transport tag is used, we should remove the
> requirement for a re-INVITE after ICE nomination process is complete,
> since it serves no purpose when no address is specified in c= and m= lines.
> If we are not going to define ICE/ transport, then I propose the following:
> 1. When c= line is set to "IN IP4" and m= line is set to port 9,
> so that these lines carry no valid address information as it is
> specified in JSEP, protocol should be UDP/DTLS/SAVPF for RTP
> or UDP/DTLS/SCTP for data

To do this cleanly, IMO there should be no singling out of IP4. The fact 
is that in this case the c= line is not needed. (And this isn't the only 
case where it isn't. It also isn't needed for MSRP and for websockets - 
things that use URLs in attributes instead of c=.) So perhaps we should 
revise 4566bis to make c= optional for m= lines where it isn't needed. 
Or define a new addrtype for use in c= (e.g. simply "IP" or "IP4/6") and 
define a placeholder address value for this case. For example:

   c=IN IP -

> 2. When c= line and m= line carry valid address information, protocol
> should match the candidate specified in c= and m= lines.
> 3. In cases when c= line and m= line carry valid address
> information, when initial offer and answer are generated, they must
> include UDP candidates and UDP candidates must be used as defaults. Once
> ICE nomination process is complete, only the active candidate pair MUST
> be included in SDP, and the transport for the active pair must be used.

I think this could be handled by having different <proto> values:

ICE/DTLS      DTLS over either UDP or TCP

ICE/DTLS/RTP/SAVPF      Like above, but for RTP/SAVPF

So this allows restricting the type of candidates that are allowed, or 
not. And it avoids "lying" about the type that is to be used.