Re: [rtcweb] [MMUSIC] Default proto transport in JSEP

Roman Shpount <> Wed, 21 November 2018 01:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E046412896A for <>; Tue, 20 Nov 2018 17:25:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uqBNnMhzGqTN for <>; Tue, 20 Nov 2018 17:25:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 86379130E11 for <>; Tue, 20 Nov 2018 17:25:23 -0800 (PST)
Received: by with SMTP id x21-v6so2924939pln.9 for <>; Tue, 20 Nov 2018 17:25:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ip5GKlJK+Tvv3UFKISb/OTXCKx3eEfj7KBfBZfJCGzE=; b=B1JY3cSS4gMDA2Myv2lUAQh1habtsQdvDbD2Xm+KyiOc3Hxv1IRZSU1/Zt/oHv7frp I9N+LYesi5CFTvlEKtQgKHzpBB3ELE+TX2pCXArvhjq9FM1oc5x2fDLeWRF/jxIn+ukJ wb4dpO0OzIRGhkQx/djoFTkAHN9r+Xq4PhypAmqK+iOQkAcEA994rxe85fXtlTqp3umh 8+WMKIUyzXBpoVWl6onirK4t/qnnHbXaIv+rOg2up/3U0RpXoLIxmdIhMTpTQ6ZjU6Vc tUN0B0f5tm3V6HrNu8qU7jlEhrgTEergCYRuT+Q7WTXCkw6mVoQ72VmWDH62PUavV8lV +P2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ip5GKlJK+Tvv3UFKISb/OTXCKx3eEfj7KBfBZfJCGzE=; b=qk3xKZmhDre6xAAyd3P1DAkFgA921uQc8ojHpTHkuChgVWsvZem9z1Wrg8XPfpaWb/ FUiVBBoa6zUFcw/B/xjUOMWQ2T10H/CT+14JdNYP+jEG9OXEPfEZRXAvKgpyiua6rCsC 6sd8xpexU/oXhoLHp67m1pebJzL/y3ID4QrYhE0cpMI3QcPOImsVGef3yg94qjgeHs+a MbZlb+LNkTDOhL4unH7iCqnDLn01rrQH+6zUMQMZHjQTsAJVRKo0siSzMwezSiTrv9As i93IwNnI84I8sNRyfYjKH8AaUsD9SnRPOBbdjcIyICorKqRcjPwoR2wj/u1iXJc5DbB2 CMOw==
X-Gm-Message-State: AA+aEWZUVOw/uDxYRSwWVa78U70h5uYmJ2lGfChSKo7fcW2gUunPqOcT N0Ih/Uc4jdykeUa9In4AJsDEpjGcUS4=
X-Google-Smtp-Source: AFSGD/Ujp0vqjxzAohXxrA/0uq/LrBHwfarxOxfJxlVkI/JUpRI+HfB43WdmeolaXw4QyMlFPzpM3w==
X-Received: by 2002:a63:8c2:: with SMTP id 185mr4177162pgi.26.1542763522887; Tue, 20 Nov 2018 17:25:22 -0800 (PST)
Received: from ( []) by with ESMTPSA id l3sm50711091pga.92.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Nov 2018 17:25:21 -0800 (PST)
Received: by with SMTP id gn14so2932853plb.10; Tue, 20 Nov 2018 17:25:21 -0800 (PST)
X-Received: by 2002:a17:902:2f03:: with SMTP id s3mr4206945plb.277.1542763521468; Tue, 20 Nov 2018 17:25:21 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Roman Shpount <>
Date: Tue, 20 Nov 2018 20:25:11 -0500
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Cullen Jennings <>
Cc: RTCWeb IETF <>, mmusic WG <>
Content-Type: multipart/alternative; boundary="000000000000ab6d8a057b229f8c"
Archived-At: <>
Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Nov 2018 01:25:26 -0000

On Tue, Nov 20, 2018 at 7:10 PM Cullen Jennings <> wrote:

> Sounds like the ice-sip-sdp draft has not concerned itself much with
> working with the existing deployed endpoint which treat as a hold
> indicator. I think the JSEP solution will work much better in practice.
> This is discussed a bit in
I am familiar with IP4 hold and issues it has with ICE, DTLS-SRTP,
and recently trickle ICE. The ice-sip-sdp draft did not break anything new.
All of this was broken in RFC 5245. None of these new protocols work with
endpoints which treat as a hold indicator since all of them need
media addresses of both endpoints in order to work. End point cannot use to create a send only stream. Both addresses are still needed to
creat it. All of these new protocols assume that endpoints use
a=sendonly/a=inactive instead of This is not a major problem in
practice, since end points which use hold, do not use ICE or
DTLS-SRTP at the same time. These end points will put and will not
put candidate or fingerprint attributes for this m= line, which avoids the

If we are being pedantic, it was trickle ICE that decided to re-use
hold for other purposes. The ice-sip-sdp simply added that if default
candidate is set to and UDP port 9, ICE mismatch is never
triggered, which has no effect on using for hold. This language was
added to make ice-sip-sdp implementations to be compatible with future
trickle ICE implementations.

Also, if you are concerned with breaking changes, sdp-bundle changed using
port 0 for disabled m= lines, which will likely break a lot of B2BUA, since
B2BUA often drop all the attributes from disabled ports.

Roman Shpount