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

Eric Rescorla <> Tue, 17 January 2017 01:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF8B812994F for <>; Mon, 16 Jan 2017 17:15:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 oUBrWJI3SApE for <>; Mon, 16 Jan 2017 17:15:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 549EF12994E for <>; Mon, 16 Jan 2017 17:15:47 -0800 (PST)
Received: by with SMTP id j82so21832359ybg.1 for <>; Mon, 16 Jan 2017 17:15:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UY5zj/69JN/Ethnld32RAEimoahEYEBgaOIiHCxLpyw=; b=WJXS36BzfR6Bi/KYNzWob+Fkyg+k9loW6cQqGkpJhCcgUPTnq2ycjo7skXkTM6zq+C g0uuxLmpFFvg2Co9HtL4+rPmONGhGb0ygB1dhoUjOjXZt1jVGPdQ54U9FbTbl7kfvWyK k4XW4iMDzuuRDtLlriVRJdlWoNZPn0hOg19W8MX2/0jg57Ms56faCopaTyvvKrtJrHyh 3Pj+Zutwo3KFQHL1nlgIAuBDsjJA3xscVGX8OJRYnOoaTjALD85KdxUkLq8XTsPRnFQf bSsn9m7Y2YW1CqagITnHLAv+NI+l4mAzKibd2ButbSO31ZOm8e5L3/uJ5Tmb0V1ymjeD iKgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UY5zj/69JN/Ethnld32RAEimoahEYEBgaOIiHCxLpyw=; b=Ehm4yMUuk2+ci3/xSkdWicMN8EO5D2748GhHed4trHZCBzTQIXrNFCFPayjMCZFyFv gJL5k0tsLt43iyQ/NxSN9Kzj7r2gBWGYw59ZzQyTEWnBRsmXTNSrUEJUhQg16biw52Ks 8L/D55u3rF6UNFtx9PwAb5YwkzvCfC4nHSegNqw8aKeiW17WgbvMJqDljOEINdR9xg10 nc71cQrqhdot5UexJign9lyVxVdCrkROM+8PhcJ8GSTm0LstEnXPLvAhzJOeNAE+7FqE lINpA3RNvABxHfcxu0bRaJ/7rUJJsx6ea/CQktJX5YYK0rX7/BGj4XC3KPhgXEm28/xE syTQ==
X-Gm-Message-State: AIkVDXL9EOZzv/TTX4GtTIVovx7ssQq1IxbmdswJ6NlWB2ceI6xKgW7QX6zGgAbrIY3XnfpEoKMjCSDuvX2nSw==
X-Received: by with SMTP id t10mr24590875ybd.107.1484615746608; Mon, 16 Jan 2017 17:15:46 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 16 Jan 2017 17:15:06 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Mon, 16 Jan 2017 17:15:06 -0800
Message-ID: <>
To: Roman Shpount <>
Content-Type: multipart/alternative; boundary=f403045dc8583490b10546400ad7
Archived-At: <>
Cc: Magnus Westerlund <>, mmusic WG <>, Christer Holmberg <>
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, 17 Jan 2017 01:15:49 -0000

On Mon, Jan 16, 2017 at 4:53 PM, Roman Shpount <> wrote:

> For clarity, this is what I would suggest for JSEP:
> JSEP end point MUST send an offer with UDP/DTLS/SCTP and UDP/TLS/RTP/SAVPF.


If JSEP end point receives an offer with UDP/DTLS/SCTP or
> UDP/TLS/RTP/SAVPF, it MUST respond with the same proto


> and MUST include udp candidates (and use udp as a default candidate if
> JSEP endpoint is providing default candidates).

No, I don't agree with this. It should offer whatever candidates it wants
and/or are determined by policy. For example, if the implementation is set
to relay-only, it will be restricted to whatever the TURN relay will do.

If JSEP end point receives an offer with TCP/DTLS/SCTP or
> TCP/DTLS/RTP/SAVPF, it MUST respond with the same proto


> and MUST include tcp candidates (and use tcp as a default candidate if
> JSEP endpoint is providing default candidates).

No, I don't agree for the reasons above.

If non JSEP end point responds with a protocol that does not match the
> offer, this is considered an error regardless of the ICE candidate supplied
> in the answer.
> So, what I want is for JSEP not to generate offers with TCP/blah and not
> to generate answers were protocol does not match the protocol in the offer,


> or does not match ICE candidates provided. I think this will improve
> interop and can be satisfied by all existing implementations.

I don't think trying to match the candidates to the proto line is useful,
especially when you are doing trickle ICE.


Generic requirements for ICE outside of JSEP can be more complex since we
> need to explain what will happen when end point receives an offer with
> TCP/blah but does not support TCP candidates. Also, outside of JSEP, things
> like ICE mismatch come into play. This, of cause, can be discussed and
> decided elsewhere, not in JSEP.
> Regards,
> _____________
> Roman Shpount