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

Roman Shpount <> Wed, 28 November 2018 19:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27AF0130FC2 for <>; Wed, 28 Nov 2018 11:50:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.347
X-Spam-Status: No, score=-3.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 3ImZ4LCSB7ss for <>; Wed, 28 Nov 2018 11:50:22 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 95719130FBE for <>; Wed, 28 Nov 2018 11:50:22 -0800 (PST)
Received: by with SMTP id 17so9966162pgg.1 for <>; Wed, 28 Nov 2018 11:50:22 -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=bP2dV194ccrdauawcnoCOgNqP0BSnGYDfpb0AuF8q2E=; b=CqJDvWvLGA3VPaNAbH7o529xXD5rEDzug70RqJYnKThW/FADV+FPwSX8GCQ5bX/Ymo Lrv1ESG0PLDuR9K17P23ijPA+msmjge0LroUhlhVg9eAjJ8ey0DUY+Fmahj36k6M0eZx C+TxPuU5sj8koAr7UE4HsY60epXyBW2aZlWHwmtp7RmmaIBHsyl4os2PEnbmFskn028d Zimjf2FW0zZEQXM+wWZXecNPbeEomMsu/jxhBSIoEuvroOcOcZ4CwAteBpeiW7StjZU+ HDQJLwX4DE4OFStTe4FsJHof0bo+Vd2VQzj5Wz2UH1QSyac0c1Kt0ZKdJRXpkuF+wDAr rghw==
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=bP2dV194ccrdauawcnoCOgNqP0BSnGYDfpb0AuF8q2E=; b=Wt4jVOWlN5mOK/b1Bqg0Sp3d1lW8R48DyJO9t/AfhWheoISgs1Aig9JqNxXViMlQic zDonmPL8IuwJlRS8kke7AsLJNc90/LIviSdoHoDBavttQmWdNyIatpzSWEN23Ii7f+YI 0dc1UFElUNvFvTxFXv6b3b+YFcbtunxpM3UsiWq7SVSuXF3R7OZQ6I98vS+rROUTiFoH jeqflRhSJEf9YavJvkX33D/SHjsc6Qqzp/BudQEBDVz6Sq46NRygd+AYF5jZ1RUjQTqp tA3WhM1asHkvyz/XhZz7taUbjTxcSXbUi4/RQMWfDrh/BvdbZgKwXbHeNI7HttlXriwv YHVg==
X-Gm-Message-State: AGRZ1gKTkd91mO3C6xVlknN62Umu0XOkiaLBnmV9QzY6q9f201iXUOA5 Te7mdZmoKvsmS1jHF/HpBJCDLWeSVuI=
X-Google-Smtp-Source: AJdET5fTD7aZ8Y7dVBkVzrjK6eZRAXOuHeT1yQJWfrg+AO+jBbAZiAQnZ4uriPm0PCoWtfR6G+3OyQ==
X-Received: by 2002:a62:2e46:: with SMTP id u67mr38214023pfu.3.1543434621853; Wed, 28 Nov 2018 11:50:21 -0800 (PST)
Received: from ( []) by with ESMTPSA id 128sm13022642pfu.129.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Nov 2018 11:50:20 -0800 (PST)
Received: by with SMTP id x21-v6so17875669pln.9; Wed, 28 Nov 2018 11:50:20 -0800 (PST)
X-Received: by 2002:a17:902:8b88:: with SMTP id ay8mr38757038plb.55.1543434620502; Wed, 28 Nov 2018 11:50:20 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Roman Shpount <>
Date: Wed, 28 Nov 2018 14:50:09 -0500
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Justin Uberti <>
Cc: Adam Roach - SIPCORE Chair <>, RTCWeb IETF <>, mmusic WG <>
Content-Type: multipart/alternative; boundary="0000000000004a094f057bbee037"
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, 28 Nov 2018 19:50:25 -0000

On Wed, Nov 28, 2018 at 1:59 PM Justin Uberti <> wrote:

> Regarding the current conflict between 5.1.2 and 5.2.2, this is discussed
> in, and the editor team
> concluded that 5.2.2 should be brought in line with 5.1.2 by removing the
> need to match the protocol field. I think this change is important to make
> to avoid future confusion.
> This conclusion was a result of reviewing the prior discussion in
> where this topic was previously litigated. That email thread concluded with
> the message in
> where Roman seemed to be in agreement with the proposal.

The discussion you are referring to was about the initial ICE offer/answer
exchange. I agree that during offer/answer exchange which initiate ICE
restart, only UDP based protocols should be used in the m= line. For me,
this is what section 5.1.2 describes. When ice-sip-sdp and related
documents (sctp-sdp and fc4583bis) were written, this logic was slightly
"fine tuned" for offer/answer exchanges which do not initiate ICE restart.
For these exchanges, it was decided to use the protocol of the only ICE
candidate pair present. This was important for backwards compatibility with
RFC 5245, especially when signaling agent monitors values in c= and m=
lines and actually cares about the address and protocol used there.  This
is what JSEP section 5.2.2 is describing and what you want to change. I
agree this is not extremely important for JSEP use cases, but unlikely to
change in ice-sip-sdp, since it is important there. Because of this, we are
going to end up with two specifications, and ICE implementations, which are
slightly different for no reason. As an implementer, this is an extra
"flag" I need to set when instantiating my ICE library.

Second part of the problem for me are the values of address and port in the
c= and m= line when no candidates in session description match the protocol
in the m= line. I do not think it was discussed anywhere except during
trickle ICE, where it was specified to set c= to IN IP4 and m= line
port to 9 when no candidates are present. If this can be extended to the
case when ICE candidates are present but do not match the proto in the m=
line, I would be happy since this will prevent ICE mismatch with
ice-sip-sdp compliant implementations. If you do not want to update JSEP to
do this, it can be added in ice-sip-sdp. Just please do not put something
in JSEP which will force it to update c= and m= line with address and port
of mismatching candidate.

Roman Shpount