From nobody Tue Jan 15 08:04:08 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861A2124B0C for ; Tue, 15 Jan 2019 08:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdmYC-fncTcg for ; Tue, 15 Jan 2019 08:04:04 -0800 (PST) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3AA130E84 for ; Tue, 15 Jan 2019 08:04:03 -0800 (PST) Received: by mail-vs1-xe2a.google.com with SMTP id v205so1958171vsc.3 for ; Tue, 15 Jan 2019 08:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Ozi/zwL9S8Yb4WehaP4Fo43sHZEgHGveBTU3tiDoMtY=; b=IdS/OlPzymsJdqCJ86ij/clQCLSktW8E2CXKh9EZ7JRy/daxre3fmfFqLULeA6BNcp ZaZ8MouLpBDhEIQGmAFCQEvTmMkBoEKd6RvHnI1bnyqlLrbVmdbekMtL0mPrnxwFEnol EolkkVJzGu3LMDFbC4QRnQy+ZaVBU/mDl7k/2XgBzybf/5a8/PgXXW4fZmvBm9FWVWEf pCYupZZeDaOsyi4rlpA0HQAUGIwpCS9+JfONF4M1IziLSpd9P6v47S7cWD2mLx5x2D6U fLdJs5co/P1Clh4XNWGsh8VvkdC5z1/S+ypHY15YRUr4HjJ/tI2qrFFAmhVxDjlk2xc1 GeBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Ozi/zwL9S8Yb4WehaP4Fo43sHZEgHGveBTU3tiDoMtY=; b=nm5A+fBU++dUSMW9ZkXNKm9yY4TYGv/yJVE25kJAFpvEqgicTzDMdrsCeu8Fs6/MAa 7KVUDtrPEtatZoN7yE3P5RzuFvAqr8d6rS2GgC7dB+Bsq65ZUXuannJzx3PmiSGCc9aJ 8jEo88uVH5L2BNiKGN59UF/6a5911mSlwIex4v6dCHzCADeeyIwMoeq7Fa7h+4HGs2Ez dIVyosFj+b4RRFWvkEHyswVeIFC/IpHvN+qDhHM6mqp9BHtPr4OYgzK40navfZVgG/50 8uvJ2cEBff2niaHUoSNFDv1FxIxNSa8WCpjigngBWLujpjuNLiOSyOjAYU1NHRJyaaTe a2cw== X-Gm-Message-State: AJcUukdT+MugmZFOQL+bAbo1x29utrw6EHyovZaaYwflmq+LA/771t62 u+cZ91fCayDPJD0PXLfmLh1XWILeCJlC7OevV4CyqGRm X-Google-Smtp-Source: ALg8bN4mgJg6aCBUXKYHn/SCYMZCWn7v7+IYp01tvr7Iue2mPIYjRdclGkZ95CN5qKRA4dwY/fwMEN8lxgupTHbcKtM= X-Received: by 2002:a67:42c7:: with SMTP id p190mr1957608vsa.82.1547568241950; Tue, 15 Jan 2019 08:04:01 -0800 (PST) MIME-Version: 1.0 From: Bernard Aboba Date: Tue, 15 Jan 2019 08:03:50 -0800 Message-ID: To: RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000053c675057f814faa" Archived-At: Subject: [rtcweb] RID syntax inconsistencies X-BeenThere: rtcweb@ietf.org 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: Tue, 15 Jan 2019 16:04:07 -0000 --00000000000053c675057f814faa Content-Type: text/plain; charset="UTF-8" An issue has been raised about inconsistencies in the RID syntax between draft-ietf-mmusic-rid and draft-ietf-avtext-rid . According to https://tools.ietf.org/html/draft-ietf-mmusic-rid-15 , we have: rid-id = 1*(alpha-numeric / "-" / "_") According to: https://tools.ietf.org/html/draft-ietf-avtext-rid-09#section-3 : As with all SDES items, RtpStreamId and RepairedRtpStreamId are limited to a total of 255 octets in length. RtpStreamId and RepairedStreamId are constrained to contain only alphanumeric characters. For avoidance of doubt, the only allowed byte values for these IDs are decimal 48 through 57, 65 through 90, and 97 through 122. --00000000000053c675057f814faa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --00000000000053c675057f814faa-- From nobody Tue Jan 15 08:26:03 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E108712D4E9 for ; Tue, 15 Jan 2019 08:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.853 X-Spam-Level: X-Spam-Status: No, score=-8.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=abW2bvIH; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=ericsson.com header.b=OYZ0DBpQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc-3YL03M1ne for ; Tue, 15 Jan 2019 08:25:59 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11BF4124C04 for ; Tue, 15 Jan 2019 08:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1547569557; x=1550161557; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=APCzhJu4hrlgANADOKrn8dmI6dQgBd1n+Gdh5mgLaHg=; b=abW2bvIH9VzjjYf4Fw3exRyJZOyR30G2VjtA2cU4J4b6WPL7BRVN6IGl0LMrnzxl u3FzC/Of8So0mRv/eQ0/Ml4PjA3AYQTYDoMmcDn6H5D6WHQrDxlMQzYbgLgmxl+H 83PkCwtGJ1w93NMleaKFoF6oAI5L+lG2/ccUPj5R/SY=; X-AuditID: c1b4fb30-41b3a9e00000355c-46-5c3e09959b9b Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1E.F8.13660.5990E3C5; Tue, 15 Jan 2019 17:25:57 +0100 (CET) Received: from ESESBMR503.ericsson.se (153.88.183.135) by ESESBMB503.ericsson.se (153.88.183.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 15 Jan 2019 17:25:54 +0100 Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESBMR503.ericsson.se (153.88.183.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 15 Jan 2019 17:25:54 +0100 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 15 Jan 2019 17:25:54 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZjZaU3F0C/M7UrpJe3kbaqqsFVc95K00nS9+qgGaWpU=; b=OYZ0DBpQLcMMsj5elHrwsYTRQt2IB4UUlmG6/vCkBB+yQk45WIWzHcFuzm7CTC++y7UeHMa7JtyM07DrtzA1Sr1307BkQ/i+c1FMG3ISH+/UwBwI0DW+EHxfIdPs2qJ3d6ugMOZB6ACP+7m7urNmkTrqScViAiupVzwF6+P3DrA= Received: from DB7PR07MB4988.eurprd07.prod.outlook.com (20.178.42.222) by DB7PR07MB5371.eurprd07.prod.outlook.com (20.178.45.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.19; Tue, 15 Jan 2019 16:25:53 +0000 Received: from DB7PR07MB4988.eurprd07.prod.outlook.com ([fe80::59db:b1cc:5d05:1f08]) by DB7PR07MB4988.eurprd07.prod.outlook.com ([fe80::59db:b1cc:5d05:1f08%3]) with mapi id 15.20.1537.018; Tue, 15 Jan 2019 16:25:53 +0000 From: Magnus Westerlund To: "bernard.aboba@gmail.com" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] RID syntax inconsistencies Thread-Index: AQHUrOv6sFdjXi6aPk29hhA+tAN8oqWwgWpw Date: Tue, 15 Jan 2019 16:25:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7PR07MB5371; 6:tu51dRMm/9BFWy/82UJvG/GyL0QwRjs/EI5aCLvMXgQpBKGMaL+a4sCF8jjVRrHWh7ewxsQoD6ch6rZSnLUf6VQSMohLxzrsRVm3K+VnQqy4FoxbIcbL0oX+v77sQrVsio+vQ+AGLduOCCKtcSAjNgw7/tIN4fBZdmLwRypyroXUK+7sUpT+Ul7FpteNHAEx9H3dOiIDMoOttWQo1p35bGtHgHelHfz5XY/B2o8ZbOH0G8Gdzxgy4B3bJQyfOgti2SBTSlFdd3BvOX6cGdzap9jxrHL4rD3U/cF/o3p81zY4qKrH3J1odKvgqrqv3EiwLL8vfkKQou7B0dN1IWjBP2h1lfhTea5s0zdeuaLR3ow867nR2NT87M9NlW5cTR40FoWgtHKo7Z9HihojADzKmHVDRXufCRtFCy79YdQ0cQqxEmcSCZgk758Yh/xOSF7EgUuJ33QLrgZ0lHo783d8TQ==; 5:PHD+eRpdoMjbL7ztLHq39mPRMsXlTsk1TRm78TUou+3k3zlCk0jMMC+uT0F+Be7ChG9uYcuE5P2IEg6/sBtt7p7eOuVOMM6+IXIedN+a9286nTxKOJY+I7b1QXcB2BrA1ytzgsFRgijOojblaYZadA3HI9w7W37Bs9dAtREcoYFR/bBsTFlfwQEC/LV7/0Qmv7Ut298A2DJ94lV8sB0Q3g==; 7:EXftAcRdeI9Pe1k2M2Rgy4dQp5YoFXbZwOOMcx4sPfbfKPgTg/a71tFKujSZCUyjn1goZGAHHH2YsxaDsWWR3HbppM4IYBQZwMfeZ0EeKwgwX8h5C8VGuyUmJSljYJAP/MjfUxzQeN05CqZ2b91OsQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 89e099b1-63b6-4604-1644-08d67b061e80 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:DB7PR07MB5371; x-ms-traffictypediagnostic: DB7PR07MB5371: x-microsoft-antispam-prvs: x-forefront-prvs: 0918748D70 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(366004)(346002)(396003)(376002)(199004)(189003)(55016002)(6436002)(9686003)(25786009)(81156014)(8676002)(7736002)(606006)(6116002)(8936002)(3846002)(966005)(76176011)(256004)(7696005)(99936001)(39060400002)(81166006)(790700001)(54896002)(6306002)(236005)(14454004)(229853002)(478600001)(53936002)(6246003)(106356001)(316002)(105586002)(71190400001)(71200400001)(53546011)(110136005)(97736004)(446003)(186003)(66066001)(86362001)(26005)(486006)(44832011)(74316002)(476003)(11346002)(5660300001)(33656002)(99286004)(2501003)(6506007)(68736007)(2906002)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5371; H:DB7PR07MB4988.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: US6Pb8FzjXjvavhPSnYo/1ANLN90/UAZFEn6fgyTHQymKW+GXtq4YI2NMCyOYjDEckcCcToWofT7sy8mY5ipkiFwYCfoOVTZ25aiGK5M/V8akuU6DaWNzzA0wr4fRwVzVqoNJ7/fcwOQK9Fc55LBKZm+0XBg1LcQHIf7r7DHV873bS4JmO/BQGy9wUbaY5NwPkFy2Gq6x74QcdHrXHKRnlGAcd43GIDp3AQ4l3SPCZ2ZNeAgvELdFYXAKE9GB8KYAr3IDB+uaK3wleVSi4yY+R7OoZJ9XzDM0aKfM27ywlMwgt0cBgeUOHL43Zzd47g3y39AzBZrA+Lkzvb91M3rpwkVKhAgcWK6x5QkRz6PEtkKo5V4WIN3coMBZPzP5F2McReQzf6TM5SP9uji7PEE2PfFtKfetB1RGrShQo/fl8c= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003B_01D4ACF7.592FA020" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 89e099b1-63b6-4604-1644-08d67b061e80 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2019 16:25:53.0124 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5371 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA2WSa0iTURjHO+/77mYNjlPxyRJtZJjm0qHgB2+JgRCB1RezUc58UVE32dZI oZyJCfOSSl62yEupdMG0TSm/KGlepoQXWuowbaaZSdGwTNE03Tsj6Nvv+T+/55zzwOGSgmWW BzdNpqIVMmmGkO1E6eJfqAIqeRGSwBKTa2hb1zYZ2rJVyIkiYjv17zmxjY3rRByR4BSWTGek qWnFyYhEp9TBmhVW1p0SdH35YbwGdeQjLeJxAQfDhH6I1CInrgC/RlBrKEdMsYrAkl/G/ltU 9C9STNFIwNuaDrtG4TIS1szNjpkKAtbHNh3aHALru1r27jVsHApTa3l2dsWXYVDbbmcXHAjl P1Y5TB4EDZ0dJMNiGPlpszsU9oGZvm1il/lYAtW1xfZcgONgtvcDa5d5+BzUGFvtOcKeMPtr htplEruDZb6OYFZ1BevYMJthN1j6uMVifClM5i04HG/4UqRxOJ4wXldk3wzwLQ7MmR84GgHw vbKSZPgs1NSNcBjJgsA0+JzFNPzgtsVEMZwOWlubY+AwGEfGCWYgjw2jeg1ZhkT6f16r3+mR uBxBSdV9pLev7Qwm3TzFSJfgXouGxbA/lFgL0B43NyyTDPvBG/ME5/88HD4PzTryI3C3yOrg EFjus6F6tP8JclPSyqTMFLFYRCvSriqVcplIRqsMaOfbvWrfCHyJlhZP9SDMRcIDfPG+CImA JVUrszN70NGdc+bano4iD0oml9FCV746Okwi4CdLs3NohfyK4loGrexBh7iU0J2/KXCWCHCK VEWn03QWrdjrElyehwYlfBvIbrVVJXGPQ5N4uPyGlyRf/Sl5q/L3o1B/HT6mEU20d12wTfdP T9s2ut2F4RmCmNzqBW/DaIyPR7BvwddS80a9S3I0Mid6RbUYH3fXhxtVTYW+B09EytVT53sj O+dXcrQyUfPNUqK4qWnSZtDlXqTGn8lCTgfNDpxJ7RZSylRpkB+pUEr/AJ9Py6V+AwAA Archived-At: Subject: Re: [rtcweb] RID syntax inconsistencies X-BeenThere: rtcweb@ietf.org 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: Tue, 15 Jan 2019 16:26:02 -0000 ------=_NextPart_000_003B_01D4ACF7.592FA020 Content-Type: multipart/alternative; boundary="----=_NextPart_001_003C_01D4ACF7.592FA020" ------=_NextPart_001_003C_01D4ACF7.592FA020 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, =20 So the main point is the missing =E2=80=9D-=E2=80=9D and = =E2=80=9D_=E2=80=9D i.e. dec 45 and 95 in ASCII.=20 =20 Are any of these characters used by actual implementations?=20 =20 If not isn=E2=80=99t the easiest to restrict the MMUSIC RID to the set = AVTEXT RID defines?=20 =20 I guess we should also address the limitation of 255 characters, i.e. = change syntax in MMUSIC-RID to: =20 rid-id =3D 1*255(alpha-numeric) =20 Cheers =20 Magnus Westerlund =20 =20 From: rtcweb On Behalf Of Bernard Aboba Sent: den 15 januari 2019 17:04 To: RTCWeb IETF Subject: [rtcweb] RID syntax inconsistencies =20 An issue has been raised about inconsistencies in the RID syntax between = draft-ietf-mmusic-rid and draft-ietf-avtext-rid .=20 =20 According to = https://tools.ietf.org/html/draft-ietf-mmusic-rid-15 , we have: rid-id =3D 1*(alpha-numeric / "-" / "_") =20 According to: = = https://tools.ietf.org/html/draft-ietf-avtext-rid-09#section-3 : As with all SDES items, RtpStreamId and RepairedRtpStreamId are limited to a total of 255 octets in length. RtpStreamId and RepairedStreamId are constrained to contain only alphanumeric characters. For avoidance of doubt, the only allowed byte values for these IDs are decimal 48 through 57, 65 through 90, and 97 through 122. =20 =20 =20 ------=_NextPart_001_003C_01D4ACF7.592FA020 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

So the main point is the missing = =E2=80=9D-=E2=80=9D and =E2=80=9D_=E2=80=9D i.e. dec 45 and 95 in ASCII. =

 

Are any of these characters used by = actual implementations?

 

If not isn=E2=80=99t the easiest to = restrict the MMUSIC RID to the set AVTEXT RID defines? =

 

I guess we should also address the = limitation of 255 characters, i.e. change syntax in MMUSIC-RID = to:

 

rid-id =3D = 1*255(alpha-numeric)

 

Cheers

 

Magnus = Westerlund

 

 

From: rtcweb = <rtcweb-bounces@ietf.org> On Behalf Of Bernard = Aboba
Sent: den 15 januari 2019 17:04
To: RTCWeb = IETF <rtcweb@ietf.org>
Subject: [rtcweb] RID syntax = inconsistencies

 

An = issue has been raised about inconsistencies in the RID syntax between = draft-ietf-mmusic-rid and draft-ietf-avtext-rid = . 

 

According to https://tools.ietf.org/html/draft-ietf-mmusic-rid= -15 , we have:

rid-id =3D 1*(alpha-numeric / = "-" / = "_")

 


As with all SDES items, RtpStreamId and = RepairedRtpStreamId are
limited to a total of 255 octets in length. = RtpStreamId and
RepairedStreamId are constrained to contain only = alphanumeric
characters. For avoidance of doubt, the only allowed = byte values for
these IDs are decimal 48 through 57, 65 through 90, = and 97 through
122.  

 

 

------=_NextPart_001_003C_01D4ACF7.592FA020-- ------=_NextPart_000_003B_01D4ACF7.592FA020 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVdjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGBzCCA++gAwIBAgIQ C0ZtzXB7bjBlrrZreXF57TANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMjE1 MDcyMjIzWhcNMjAxMjE1MDcyMjIyWjBwMREwDwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRTWFn bnVzIFdlc3Rlcmx1bmQxLTArBgkqhkiG9w0BCQEWHm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbTEQMA4GA1UEBRMHZXJhbXN3ZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALCp R2bwd07JixA7T0ohRSgIe90tsAKbfpWqoOXl06qJ6p80/cpBBi9ncfZgU/tlmYiCsaOMNrIrFZdx BGE6l05HLabq+3DdvYCwvBd7SRxiNrFFaTvQMKVazflLhxFXrR7e4XcVvbmHdCySfEz+v8BpCHwB WmcZWVJ+/TtnhxJX4odYlSIk2Vy3BHtawSbc4VDUR1oDptr0JQyeLAqYoBhaucPl0kb4hEDJEGUb 8NQkJm9+UEvwv09+qIMyERw7gHZKEmolDmP0tnS6eB5MLzjoPrQA6Wh5K23ZnZ4yhq2EpyYoJscN eKSboMS/1W9hHlXIKQH1VbLey5uDzj0SPPsCAwEAAaOCAcQwggHAMEgGA1UdHwRBMD8wPaA7oDmG N2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmww gYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNv bTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5s aW5kaXZpZHVhbGNhdjMuY2VyMCkGA1UdEQQiMCCBHm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYI KwYBBQUHAwIwHQYDVR0OBBYEFOYr7oaVOdVuFIQQwVsH/F7FPN+2MB8GA1UdIwQYMBaAFBx7GZ6X nHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAZ9BSrpIN NFDf3PxEqcUiGmE67HfJYhxzLuay6TgTTmnKRjQTBjYFAw7eEIoYaEEd3L4WFwqwDOfTU78NBzZY Kh2aBHlWO2JySWJyVwwi1H5CuQ59vBN0K88pJBeoIlDlw8hfZoVmG0gJCcsdGI9F3PHp98GDcqBW BKo5SrWa3VdKXIBcxHl1S0vA1q80su/in1LQzhIjOh98zt57KvvigZrDokipFp+KGBEWYOShJRAB 4rPWr/tyiGhD5zgLfEEVkaRXxmeHfPRdeqhbxJbqeZ+5fOuBasZwtn64g6OIS0GOhDWjmmCIoV4W 5dlGMQBg5PPWiZv0uaWMqu8M5viityHFJetK5nPEiZbekFysNMFxDhNTLm2rmCjLGndrPIw/qxJF 6fmoE0ZfrHs1mkcRwacblCg3ejIcA4oN0mYtaj+w/w7OFfiSyI41CXNuZfbbzBgvfpaiND/rzCN2 cq6LtDTX2+ebi0GqtfDvuwWfCr+47xXcWMlIG8UNEjxIsocpXCxwJiXiwkGomR5gkRAZAiykn9Du JRNk61c3Tg9/MI87kNu1N1HXVQg/REN7Re6OhFYacSSVJQesXv9lFsMuGZWu9XSi1IWpHVazeWm8 8ahVr8zgE/ZwWth82FQbaW3Luihoe9mCfjO/X2vYiJHEAoFJ8N4CAHlnf/5+GG2NkIQwggbCMIIE qqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlh U29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloX DTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC CgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5no rG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05ZrJldk UgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o58IZ YzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57HBKH MgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWIXwM6 kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw1wup 5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOdgdgS 3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1c5Gs xuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9v Y3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnku dHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQI MAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6 Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6 aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNy bDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQW BBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjAN BgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUB D0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr 0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBdK/aj dbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0RoGzIC fsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CCKEZc dAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i7IBd Loo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+RzPTo mgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKkveBJ zqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBl rrZreXF57TAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xOTAxMTUxNjI1NDVaMCMGCSqGSIb3DQEJBDEWBBQevoCTwQgIw6xj7bSI6NvTCXuP njBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBl rrZreXF57TBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5 cXntMA0GCSqGSIb3DQEBAQUABIIBAJXODJGbiTzwOSRUAvc1Rat4hRzsre87m1fnf+h5sNSnjVlF KniMGNbYD/ms+6KzsZn8gd4GgF5pGAbQPTSycpr5pym4pmZtT0NpaSDOYNflisI7+TQu58zC58a8 Aye6tX8Qu6C4iIFBss9YWhgKYg7VHrrcAA1HYFIXzStIP0EQmJ8xUFzM5Xc0gPhAh+cA2vsmG/jN FH8MS6BwrCrXFKFNADr+8WCpX2FqsWektTByBVfPbhwvSYMlqWluln2AETFARRxuVMmrnNlAoK23 /ddrWEplkqJSf7j37l6dy8V5qP/QVltl590a9gRHq6W5Dwuh6xLQUkXDsQXq+XBxTLQAAAAAAAA= ------=_NextPart_000_003B_01D4ACF7.592FA020-- From nobody Tue Jan 15 09:54:29 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27107130EDF for ; Tue, 15 Jan 2019 09:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voHNAr3RRIEt for ; Tue, 15 Jan 2019 09:54:14 -0800 (PST) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8DC130DCB for ; Tue, 15 Jan 2019 09:54:14 -0800 (PST) Received: by mail-vs1-xe2f.google.com with SMTP id v205so2203074vsc.3 for ; Tue, 15 Jan 2019 09:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uldHeWxVX9r1g4J7hy1Lw5tIMJjvxifHhoc5UhldaBk=; b=oTp5+rhp6r9WlQ5BS2+j1hmnh0mqXlkOgEUb/FuXdGbq48Hwt/mU0FWhwFIBWwzmjC SJmaQCKJhejwMPB+KZ1/ciHYVkIyzS1K8CnaB3EhHtLhKhlFUc5+45LEctW1z1dlwYkO EPL2E9GYPS3HQ5Prvd7O+9FjYvsrzWQwPytYsig46m0fSsign0woELmYx0bGy6DTE9e9 oxsxbUcroAqE9WcVhxlbTElxttD3vO0Rk/NgDxHiz5C/XT04ONrLLUK/GC8bh+xm/UNZ yb3mESC03uldCOT9B3i5iTz7UC4S98hWRzhvC5yG2TD1NjpDgvt5lAF0j3yvRpJ5PzZQ U/6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uldHeWxVX9r1g4J7hy1Lw5tIMJjvxifHhoc5UhldaBk=; b=pYrfoDIjSXe7pTXQgSQiU97Df8VXOnYKBako/lJrtJ+89dvbMWnONPFuTVlFzkc6CU 0xg98xc+Qjzb+uhLKPiV3lMhQglQzK/tgopuAhfjTGD+9qDrgrm9S4KB39A5q/E8Wlhs 5AWjZOjJ2FuySlNDA9Urg72F9y6jtkeuVuNbbYhqydjGah+iP2ATMHaQ2DRREAvvvOHB ti6PVQGIildnd7ttGLfiVTj44y2jwKHcf7fqc3pWPC1i/qo6cH+EI8xZHWqkjv8jMxMq 1heFnEP1R6ZrPSGsQn9WTcAoxmch408oktyYONlNiBtQjyKfX+hFAYotRTFJEcDE9roS OAuA== X-Gm-Message-State: AJcUukfK8etraJi03xEY+NVUYCLIKlX8fq2nB7hY4vcfhxuOGcwgn52G +hEr09S1lp4NAd8Uj2ep/niEbraqh+6GcVO+BKmHwQ== X-Google-Smtp-Source: ALg8bN78NInUkSw2z6U7RdqCnp4C9z46CNoUYbcNTbSCA+wnMNAf+xH25oNlBpmPuUfG6CC/6tVipxq1P5nEYWFFo1s= X-Received: by 2002:a67:7106:: with SMTP id m6mr2148255vsc.67.1547574852886; Tue, 15 Jan 2019 09:54:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 15 Jan 2019 18:54:01 +0100 Message-ID: To: Magnus Westerlund Cc: "bernard.aboba@gmail.com" , "rtcweb@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] RID syntax inconsistencies X-BeenThere: rtcweb@ietf.org 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: Tue, 15 Jan 2019 17:54:28 -0000 On Tue, 15 Jan 2019 at 17:26, Magnus Westerlund wrote: > So the main point is the missing =E2=80=9D-=E2=80=9D and =E2=80=9D_=E2=80= =9D i.e. dec 45 and 95 in ASCII. > Are any of these characters used by actual implementations? This is funny because I'm working on this right now and, somehow, I wish to create RID values as follows: "rid1.0" "rid1.1" "rid1.2" I may use "-" instead of ".", of course, but somehow I'd like to be able to write a "separator" char. --=20 I=C3=B1aki Baz Castillo From nobody Fri Jan 18 15:54:45 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6CC130EFA; Fri, 18 Jan 2019 15:54:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk CC: ted.ietf@gmail.com, adam@nostrum.com, rtcweb-chairs@ietf.org, Ted Hardie , draft-ietf-rtcweb-fec@ietf.org, rtcweb@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <154785567757.17402.18049734957096090069.idtracker@ietfa.amsl.com> Date: Fri, 18 Jan 2019 15:54:37 -0800 Archived-At: Subject: [rtcweb] Last Call: (WebRTC Forward Error Correction Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 18 Jan 2019 23:54:38 -0000 The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'WebRTC Forward Error Correction Requirements' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-02-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides information and requirements for how Forward Error Correction (FEC) should be used by WebRTC implementations. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jan 24 11:12:19 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0C21313A4 for ; Thu, 24 Jan 2019 11:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yrelu5aVO94U for ; Thu, 24 Jan 2019 11:12:16 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B5D1313A3 for ; Thu, 24 Jan 2019 11:12:16 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0OJCDiu061426 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 24 Jan 2019 13:12:15 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1548357135; bh=2viefE1rMVVFVFw/BeREflV2Mz/98EekDHfP3bVcKfU=; h=To:From:Subject:Date; b=ES20z8rg5BHkrKyY7QziY6yT89+EeLs94IkxDH2DdpBpU/enXCWeb0tZPLOD6w81M 3GBaofAYSl+uiZVi8EMvTeSY89ZSMgKi8534s9wkH+VJUME870XEJf7LuwAdm/+sm3 aw1dO8a40AAzYjYmw4SgWcyNsWhCZ/waejILmpJk= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: "rtcweb@ietf.org" From: Adam Roach Message-ID: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> Date: Thu, 24 Jan 2019 13:12:08 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Thu, 24 Jan 2019 19:12:18 -0000 Based on conversations in MMUSIC, as well as several offline conversations with interested parties, I've put together a proposed change to JSEP that, if accepted, will allow publication of the Cluster 238 documents to move forward. Note that this new text has no impact on existing implementations (at least, as far as I am able to discern), which do not currently have the capability of producing media sections consisting of exclusively TCP candidates. From that perspective, the change makes existing implementations no less compliant with JSEP than they were before. What this change does provide is both on-paper and in-the-future compatibility between WebRTC implementations once they finalize TCP candidate handling (and candidate handling in general for mid-session offers).   https://github.com/rtcweb-wg/jsep/pull/862/files The key insight here is that JSEP's use of ICE completely discards any meaning associated with the transport parameter, while SIP's use of ICE does not. The trivial change that I propose, which bears only on future WebRTC implementations -- that is, which has no as-built specification to point to -- allows JSEP to continue to ignore the value of the transport parameter, while specifying that it says the right thing for SIP implementations to function properly. /a From nobody Thu Jan 24 12:59:10 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A57A12DDA3 for ; Thu, 24 Jan 2019 12:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR0F_sVxe4qf for ; Thu, 24 Jan 2019 12:59:05 -0800 (PST) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6D212875B for ; Thu, 24 Jan 2019 12:59:05 -0800 (PST) Received: by mail-ot1-x335.google.com with SMTP id g16so2534832otg.11 for ; Thu, 24 Jan 2019 12:59:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t8I5Ec0f9yGbWt01KnMJiW13THdX9MKlgvmWFFOUb5Y=; b=FSgVIM2qgakDwYuZmMuv20RG47XwjhYg2pep8edVgFgEZJs88crQUUD707of+E+6fa 2VBGzZRoIEdeBIgWWnM7YliDGys4dpTkWsM1rD7s2ONSaPHYG6xt4dVFLemQDuH05sI8 Wbkj/fAekmxugBKVz85orvGOFaOebYkWxjMyDR17E9fW46eHzzlBIqL1z9H/F6yDzIcz 1hd/6vqrozJ6NGgSxawqjJfi8U8nvgKhZpz5y4JJn7YVxj66aNA7v9S8wZg3tQWtnuKt E37RyQpPVKmhFpVq95TsVopxa36peCuLflXQHK1F2RvR3MAPbUnAn3bje2f6VEQJqXn7 Q+8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t8I5Ec0f9yGbWt01KnMJiW13THdX9MKlgvmWFFOUb5Y=; b=okM6dOIE+64WKOY06SD5R4BinWJslr50uzBCnTiHKgiFYyAFE2A30v763OYXDn+NR8 OmYZ7w7CQMN9FixX/xMcQuiN107ynGbAYwlblTq9okf+zvnU7O0PViyHtPZn6RQcTXOp XXBcqhDnKTNthriaIojAynRcBUBhZuYalwmHd33xYjM74OkDS7r2jv4Qv+TIO/jpfjWS nFT1VDGXxvD4SMXcCKI27oKJNKORbCs7xx7EZemoEJNfl1DxGk7ZCesLnC4ZstPhuJUo ZUsE1UwfA2iGa0ewrN5b4rpJILsoUMA80HkqKvY2PUUACo2jyDhojsoGPdyYVx74C1Hs SR+w== X-Gm-Message-State: AJcUukfLSMwtecV24zNywP7SYi259w6H0jSkS2v2RdbZP6HRJjIzjPDC odNh/3wM8w4vbi/ITpwj6pnh5cxwS7E5LVpe4+kAGg== X-Google-Smtp-Source: ALg8bN4m3nM5gGhZuTT9NJUIZa7kY7UuPV5vWFkbVucN0sRE7dGSjf74RFI3SEtfiQ7fSEnaqT4OsZf4tslsMd13Q/g= X-Received: by 2002:a9d:27e3:: with SMTP id c90mr5296789otb.21.1548363544299; Thu, 24 Jan 2019 12:59:04 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> In-Reply-To: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> From: Ted Hardie Date: Thu, 24 Jan 2019 12:58:38 -0800 Message-ID: To: Adam Roach Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000a8d3f05803a7b1c" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Thu, 24 Jan 2019 20:59:08 -0000 --0000000000000a8d3f05803a7b1c Content-Type: text/plain; charset="UTF-8" For what it is worth, I think this way forward should work reasonably well. It doesn't create a conflict for the current implementations, but does leave the breadcrumbs needed so that any implementations in the future that do add support for this will do so interoperably. If folks can review the PR (it's quite short) and comment, I would appreciate it. Assuming we get consensus, I think a quick re-spin is all that's necessary to move forward. thanks, Ted On Thu, Jan 24, 2019 at 11:12 AM Adam Roach wrote: > Based on conversations in MMUSIC, as well as several offline > conversations with interested parties, I've put together a proposed > change to JSEP that, if accepted, will allow publication of the Cluster > 238 documents to move forward. > > Note that this new text has no impact on existing implementations (at > least, as far as I am able to discern), which do not currently have the > capability of producing media sections consisting of exclusively TCP > candidates. From that perspective, the change makes existing > implementations no less compliant with JSEP than they were before. > > What this change does provide is both on-paper and in-the-future > compatibility between WebRTC implementations once they finalize TCP > candidate handling (and candidate handling in general for mid-session > offers). > > https://github.com/rtcweb-wg/jsep/pull/862/files > > The key insight here is that JSEP's use of ICE completely discards any > meaning associated with the transport parameter, while SIP's use of ICE > does not. The trivial change that I propose, which bears only on future > WebRTC implementations -- that is, which has no as-built specification > to point to -- allows JSEP to continue to ignore the value of the > transport parameter, while specifying that it says the right thing for > SIP implementations to function properly. > > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000000a8d3f05803a7b1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For what it is worth, I think this way forward should= work reasonably well.=C2=A0 It doesn't create a conflict for the curre= nt implementations, but does leave the breadcrumbs needed so that any imple= mentations in the future that do add support for this will do so interopera= bly.

If folks can review the PR (it's quite sh= ort) and comment, I would appreciate it.=C2=A0 Assuming we get consensus, I= think a quick re-spin is all that's necessary to move forward.

thanks,

Ted
<= br>
On Thu,= Jan 24, 2019 at 11:12 AM Adam Roach <adam@nostrum.com> wrote:
Based on conversations in MMUSIC, as well as several offl= ine
conversations with interested parties, I've put together a proposed change to JSEP that, if accepted, will allow publication of the Cluster 238 documents to move forward.

Note that this new text has no impact on existing implementations (at
least, as far as I am able to discern), which do not currently have the capability of producing media sections consisting of exclusively TCP
candidates. From that perspective, the change makes existing
implementations no less compliant with JSEP than they were before.

What this change does provide is both on-paper and in-the-future
compatibility between WebRTC implementations once they finalize TCP
candidate handling (and candidate handling in general for mid-session
offers).

=C2=A0=C2=A0 https://github.com/rtcweb-wg/jsep/pull/= 862/files

The key insight here is that JSEP's use of ICE completely discards any =
meaning associated with the transport parameter, while SIP's use of ICE=
does not. The trivial change that I propose, which bears only on future WebRTC implementations -- that is, which has no as-built specification
to point to -- allows JSEP to continue to ignore the value of the
transport parameter, while specifying that it says the right thing for
SIP implementations to function properly.

/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000000a8d3f05803a7b1c-- From nobody Thu Jan 24 13:02:12 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58E9128CE4 for ; Thu, 24 Jan 2019 13:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwQG7VdKChhP for ; Thu, 24 Jan 2019 13:02:09 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4CF12875B for ; Thu, 24 Jan 2019 13:02:09 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0OL26L2079637 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 24 Jan 2019 15:02:08 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1548363729; bh=S9CKrsmuW5xa3fGhFQ1Y6lS4Hx4kQ6oNJ0QSQBornAs=; h=From:Subject:To:References:Date:In-Reply-To; b=fycLZpbOc9ZqBEd4jS06YWxVyUWzFIH/ehX2gGk+JfEM0RI/K0+nrOtTnBtIV8OBm w/7i2a1aNsmJD6Uvrlf0LBk7TonpebVj2Aws20+IWmYsoExLHnA/0EF/6yOY16CkdY 7rLaq+nGRqxLo85sXAsBzV2Mm1vb2RE1ESnqpX1Y= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local From: Adam Roach To: Roman Shpount , "rtcweb@ietf.org" References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> Message-ID: <8a06e138-964a-251d-43bf-7eee3a2e67dc@nostrum.com> Date: Thu, 24 Jan 2019 15:02:01 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Thu, 24 Jan 2019 21:02:11 -0000 On 1/24/19 1:39 PM, Roman Shpount wrote: > Would you prefer to reply to you directly with my comments or as a > comment on the Github? Here for discussion, there for specific text change proposals. > > The text you are proposing is slightly ambiguous due to trickle-ice. > Theoretically, during trickle ICE candidate collection SDP might > contain only TCP candidates but UDP candidates can be added at some > point in the future. Based on the proposed text proto will start of as > TCP/DTLS/RTP/SAVP and then change when UDP candidates are collected. I don't think that's true -- the way JSEP specifies trickle ice, offers for trickle ice will always start with zero candidates, and so the trickling will always use UDP/DTLS/RTP/SAVPF from the start. > Also, for consistency, the next paragraph, which is talking about > UDP/DTLS/SCTP should be updated as well to use TCP/DTLS/SCTP when > offer does not initiate ICE restart and only TCP candidates are present. I'm okay if we require applications that use WebRTC data channels to have to do things the WebRTC way. /a From nobody Thu Jan 24 13:03:37 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AA112DDA3 for ; Thu, 24 Jan 2019 13:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSiV9I-RqFFQ for ; Thu, 24 Jan 2019 13:03:35 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 492CB12875B for ; Thu, 24 Jan 2019 13:03:35 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0OL3WVR079848 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 24 Jan 2019 15:03:34 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1548363814; bh=vmupKdg58Zn+6bLf4d2pRjIwyG6lbbLktFrZBPsa2QY=; h=Subject:From:To:References:Date:In-Reply-To; b=cX+/C8xe94j4KIMRbgpUSIUb3TwaOGxdZ03Hx6+Vi7Q6nGlpOxsO1o06yOlQQzdaO XAqZ44NdupgjVJa4c7Afgqsnz6VolKbsZ4z98CkoKW1/I9CWsqGyIw4AJpO59Ig4sA VtrobCG720SCouAIfB2JrF0SL8VcKHFHkZKiHsf0= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local From: Adam Roach To: Roman Shpount , "rtcweb@ietf.org" References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <8a06e138-964a-251d-43bf-7eee3a2e67dc@nostrum.com> Message-ID: Date: Thu, 24 Jan 2019 15:03:27 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <8a06e138-964a-251d-43bf-7eee3a2e67dc@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Thu, 24 Jan 2019 21:03:36 -0000 On 1/24/19 3:02 PM, Adam Roach wrote: > I don't think that's true -- the way JSEP specifies trickle ice, > offers for trickle ice will always start with zero candidates, and so > the trickling will always use UDP/DTLS/RTP/SAVPF from the start. Of course, I meant "UDP/TLS/RTP/SAVPF" /a From nobody Thu Jan 24 13:14:07 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE780131182 for ; Thu, 24 Jan 2019 13:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReqfODljuwMa for ; Thu, 24 Jan 2019 13:14:03 -0800 (PST) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE53F13117F for ; Thu, 24 Jan 2019 13:14:03 -0800 (PST) Received: by mail-vs1-xe32.google.com with SMTP id x28so4410131vsh.12 for ; Thu, 24 Jan 2019 13:14:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PmIGoy7EtMfjz9hbaqbUQc3St6UsipPRzhtgX8qbwmM=; b=kKnNVF2jvdOaf2aHQiwJzATuP+mZmAmB3rbnAlnCvH4jjpWzHvyIO1xya+Jnqrmu8n A4ZlppQPtg6AtvkXhnmGfhYgssAJxyBLO5DMSqmk/f2aeXAtfm922AAsH2CBfoTln3ql RJDb4B5gSx42bZUfiyKSfFkmw+ygH1/aGXFgPXfGgQrGdsB5fUncc+csWjmO25m4e6Su hJZl5uOalrQjJ56ypayikpwegpMSVdof4WT0JMT0rqXomv9/DmDIb1vwFrvBECnX1zeV B5XxabP0+HIUxwWRjqlpe9a8SpSUrm+wdCxm7UTlN/v2vl4llwh6HXnPKnreUeWwQP04 CHPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PmIGoy7EtMfjz9hbaqbUQc3St6UsipPRzhtgX8qbwmM=; b=Sln9ta/LYfRe4ZbPP1CeR47fHjR+FrVE/uh/a9tk0XJQHjOBp/1xWOvVCYAxSLi6MH vOncqjoMfYFnPoJIJMH5/uJPMJUIMmY9Xp8C8QTZ5Mvi7an8DrLr6ErwVyq1EFb+qAlP JhtGTyDfUMLXLXFA7/+u8n1chGHW8XbltPmfM+vwanR66DQmL+5LcaLiiFRqPqTVy5aj mUGAVgx4WBr6wpAVMjKXSgx22vFZpErApYMjRO3k3furGiYQuBGuk5MLUlx9mhEVjgkk GvB+lRMwSeNmb9KbZE+ruL/LvQTqerw6BCuSoWPU/udNfvHnP7XH/cOsGMYsLo4Stt9m ZLFQ== X-Gm-Message-State: AJcUukdu8uRB2Gty8zCztwF6ijK0YEqTvomx12iI9xenWrNUu+ZuwiIt PYy9uGcP1qiTCuhlP3keszP6apTQJKnLboGcxh9Ndw== X-Google-Smtp-Source: ALg8bN7B+SCuegamzE2tMZjivPua59NSYdhF22cR2u4d2ZWAhJ3EVpQNUSDhE3TP1akZtc5IbN9JogsZXSBwX6pGZnU= X-Received: by 2002:a67:820f:: with SMTP id e15mr3396500vsd.156.1548364442747; Thu, 24 Jan 2019 13:14:02 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <8a06e138-964a-251d-43bf-7eee3a2e67dc@nostrum.com> In-Reply-To: From: Suhas Nandakumar Date: Thu, 24 Jan 2019 13:13:52 -0800 Message-ID: To: Adam Roach Cc: Roman Shpount , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="00000000000097c7e105803ab001" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Thu, 24 Jan 2019 21:14:06 -0000 --00000000000097c7e105803ab001 Content-Type: text/plain; charset="UTF-8" Thanks Adam for the proposal. I do feel this is a reasonable way forward Thanks Suhas On Thu, Jan 24, 2019 at 1:03 PM Adam Roach wrote: > On 1/24/19 3:02 PM, Adam Roach wrote: > > I don't think that's true -- the way JSEP specifies trickle ice, > > offers for trickle ice will always start with zero candidates, and so > > the trickling will always use UDP/DTLS/RTP/SAVPF from the start. > > > Of course, I meant "UDP/TLS/RTP/SAVPF" > > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00000000000097c7e105803ab001 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Adam for the proposal. I do feel this is a re= asonable way forward=C2=A0

Thanks
Suhas

=
On Thu, Jan 24, 2019 at 1:03 PM Adam Roach <adam@nostrum.com> wrote:
On 1/24/19 3:02 PM, Adam Roach wrote:
> I don't think that's true -- the way JSEP specifies trickle ic= e,
> offers for trickle ice will always start with zero candidates, and so =
> the trickling will always use UDP/DTLS/RTP/SAVPF from the start.


Of course, I meant "UDP/TLS/RTP/SAVPF"

/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--00000000000097c7e105803ab001-- From nobody Thu Jan 24 13:48:41 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B7C1311CD for ; Thu, 24 Jan 2019 13:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8OiSWvzHVNI for ; Thu, 24 Jan 2019 13:48:37 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A991311D7 for ; Thu, 24 Jan 2019 13:48:37 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0OLmXVB087252 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 24 Jan 2019 15:48:35 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1548366515; bh=kX789OzA+Y8M5+aBNcY1lZz5GvF9iRZinPA27YZ81h0=; h=Subject:To:References:From:Date:In-Reply-To; b=m09SIQDH+DgsdulPWIJaf6cBuEiBOep1/Fon6L8TKRJCu9nuhPX3qposdEtY5kaRg 3LJA/bwT7cJ0qtBR50qJcB6ZZzBZ1kqvZboyhLlxsvQmnh/bv2oeKn8Yh/WTEMvQ5S iw7EEaf4EZ72WmK6cSzx1q8/BoNcf4bwv6xfLDDk= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Nils Ohlmeier , "rtcweb@ietf.org" References: From: Adam Roach Message-ID: <10f85b51-8ed3-3dcd-0d9b-a76d5625b7da@nostrum.com> Date: Thu, 24 Jan 2019 15:48:28 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4B6EF78E004CE9163E50C74E" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] [rtcweb-wg/jsep] Patch 1 (#862) X-BeenThere: rtcweb@ietf.org 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: Thu, 24 Jan 2019 21:48:39 -0000 This is a multi-part message in MIME format. --------------4B6EF78E004CE9163E50C74E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 1/24/19 3:30 PM, Nils Ohlmeier wrote: > > *@nils-ohlmeier* approved this pull request. > > In general this looks like a reasonable path forward. Ideally I would > like to see some clarity added for trickle ICE implementations (see > comment below). > > ------------------------------------------------------------------------ > > In draft-ietf-rtcweb-jsep.xml > : > > > @@ -1799,9 +1799,27 @@ candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host > > For media m= sections, JSEP implementations MUST support > the "UDP/TLS/RTP/SAVPF" profile specified in > - , and MUST indicate this > - profile for each media m= line they produce in an offer. For > - data m= sections, implementations MUST support the > + . Implementations MUST indicate this > + profile for each media m= line they produce in an offer unless the > + media section contains only TCP candidates; if all candidates use TCP as a > > Ideally it would be a little bit more clear what this sentence > translates to for trickle ICE implementations. I would expect that a > trickle ICE implementation should start with "UDP/TLS/RTP/SAVPF". But > I can see how someone could mis-read this in the way he/she thinks the > implementation needs to wait for trickle ICE gathering to be finished > to decide which protocol to use in the m= line. And thus would void > the trickle ICE benefits for the purpose of obeying to this sentence. > Because trickling in RTCWEB always starts with no candidates in the SDP, I think the behavior here is reasonably clear (see section 5.2.1). That said, if you'd like to propose specific language to address your concern, please do so. /a --------------4B6EF78E004CE9163E50C74E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 1/24/19 3:30 PM, Nils Ohlmeier wrote:

@nils-ohlmeier approved this pull request.

In general this looks like a reasonable path forward. Ideally I would like to see some clarity added for trickle ICE implementations (see comment below).

In draft-ietf-rtcweb-jsep.xml:

> @@ -1799,9 +1799,27 @@ candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host
 
           <t>For media m= sections, JSEP implementations MUST support
           the "UDP/TLS/RTP/SAVPF" profile specified in
-          <xref target="RFC5764"></xref>, and MUST indicate this
-          profile for each media m= line they produce in an offer. For
-          data m= sections, implementations MUST support the
+          <xref target="RFC5764"></xref>. Implementations MUST indicate this
+          profile for each media m= line they produce in an offer unless the
+          media section contains only TCP candidates; if all candidates use TCP as a

Ideally it would be a little bit more clear what this sentence translates to for trickle ICE implementations. I would expect that a trickle ICE implementation should start with "UDP/TLS/RTP/SAVPF". But I can see how someone could mis-read this in the way he/she thinks the implementation needs to wait for trickle ICE gathering to be finished to decide which protocol to use in the m= line. And thus would void the trickle ICE benefits for the purpose of obeying to this sentence.


Because trickling in RTCWEB always starts with no candidates in the SDP, I think the behavior here is reasonably clear (see section 5.2.1). That said, if you'd like to propose specific language to address your concern, please do so.

/a

--------------4B6EF78E004CE9163E50C74E-- From nobody Sat Jan 26 09:23:51 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE22130F3A for ; Sat, 26 Jan 2019 09:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qz904zRHl0a5 for ; Sat, 26 Jan 2019 09:23:47 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD48130E5F for ; Sat, 26 Jan 2019 09:23:47 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id c19-v6so10889423lja.5 for ; Sat, 26 Jan 2019 09:23:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bKm28GVEJdsn2Lbz/tHHwRKD/Q3kxvvppVqHmfHs6NQ=; b=sXjDhK10hs8KJlioLqZnZ7X6TCh7eDNQsuFpNnwcHGtPgV9U5vcpBraP3/ZPzhuQfn 6KCKQ71D+lB7WDiPrQM3pSLMMD9VcKIOJuapcP+KJa1Ih9ZnGMkmwWF6iIe0e1nSoRDs 4LdTvdw6R0VLgcoER/iR5WH0P1TafDiaKxNTq+txaHydsMxr2vEkbaXjk1a2W+vf70VW dWFe2u3Wjui8AzkokvkdXCty+Zvi2zdrcLKzUm40blJ8APxT2JtVzItnnaM0veOtMxsU R3yp6MYDhPLxX5Lngc6X8J8uLP03cvKVlLHyiu0OHMspWEQsTbRTiP9RV88H9Si+6LtW 8zMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bKm28GVEJdsn2Lbz/tHHwRKD/Q3kxvvppVqHmfHs6NQ=; b=of8HFYoeXwQ1tOq3mgvOzZQrLXUvwzItRUVbPjO1l8kkbCkWBE/aOYQV71sDQWuH2q J1IpDd7scHyaKfKXzS7zh3CQs3F2DC6/y2070eqsydcDcQvJX0GpK268Xmir090HDCT2 25KjJVOITsiHEL2+HkEWSXXOTbgtteA3C66SCwcK3+nV6hgPvUAFVJt/JQlSKF7Gov11 lIyvPs9h8H1iPefzP/+SWpwa8aVlltHjlLR2sIIU7TJlWQswTMWOW79L27mRrabqMDpB OZeAImdzVfvKoO5SiP+GxqnBhOWMQfJySD9dYG+C9BWSyOUPQVaPB5r5IWIzlTE6ObuI J8cA== X-Gm-Message-State: AJcUukeaeOBcbzTJaF+Od3DJFv7CngXuUwC03pKdKTU88bqqe9MeShmL /rsr1+ZDp8fA8NVRCak20WIGTTsBwyAb7ZY61fJ36DCE X-Google-Smtp-Source: ALg8bN4FbIBa9rYYyvvdDehI0y41nlsUAd/h8hkdRrbQwuAfyYvvk1BsY/BjUq7oAia8UkNyN3HI2YRt2aYB1gTe5BQ= X-Received: by 2002:a2e:e02:: with SMTP id 2-v6mr12348972ljo.10.1548523425605; Sat, 26 Jan 2019 09:23:45 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> In-Reply-To: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> From: Eric Rescorla Date: Sat, 26 Jan 2019 09:23:08 -0800 Message-ID: To: Adam Roach Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b5dd6005805fb409" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Sat, 26 Jan 2019 17:23:50 -0000 --000000000000b5dd6005805fb409 Content-Type: text/plain; charset="UTF-8" I'm not yet persuaded this is needed. The alleged need here is that there are some ICE-implementing endpoints which will choke if they see a profile that doesn't match any actual candidate. I recognize that this is required by 5245, but that doesn't mean anyone ever did it. Can you please point me to a client which would interoperate with a WebRTC endpoint with this change that would not if you just always sent the same profile as JSEP currently requires. -Ekr On Thu, Jan 24, 2019 at 11:12 AM Adam Roach wrote: > Based on conversations in MMUSIC, as well as several offline > conversations with interested parties, I've put together a proposed > change to JSEP that, if accepted, will allow publication of the Cluster > 238 documents to move forward. > > Note that this new text has no impact on existing implementations (at > least, as far as I am able to discern), which do not currently have the > capability of producing media sections consisting of exclusively TCP > candidates. From that perspective, the change makes existing > implementations no less compliant with JSEP than they were before. > > What this change does provide is both on-paper and in-the-future > compatibility between WebRTC implementations once they finalize TCP > candidate handling (and candidate handling in general for mid-session > offers). > > https://github.com/rtcweb-wg/jsep/pull/862/files > > The key insight here is that JSEP's use of ICE completely discards any > meaning associated with the transport parameter, while SIP's use of ICE > does not. The trivial change that I propose, which bears only on future > WebRTC implementations -- that is, which has no as-built specification > to point to -- allows JSEP to continue to ignore the value of the > transport parameter, while specifying that it says the right thing for > SIP implementations to function properly. > > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000b5dd6005805fb409 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not yet persuaded this is needed. The alleged= need here is that there are some ICE-implementing endpoints which will cho= ke if they see a profile that doesn't match any actual candidate. I rec= ognize that this is required by 5245, but that doesn't mean anyone ever= did it. Can you please point me to a client which would interoperate with = a WebRTC endpoint with this change that would not if you just always sent t= he same profile as JSEP currently requires.

-E= kr



=
On Thu, Jan 24, 2019 at 11:12 AM Adam= Roach <adam@nostrum.com> wro= te:
Based on con= versations in MMUSIC, as well as several offline
conversations with interested parties, I've put together a proposed change to JSEP that, if accepted, will allow publication of the Cluster 238 documents to move forward.

Note that this new text has no impact on existing implementations (at
least, as far as I am able to discern), which do not currently have the capability of producing media sections consisting of exclusively TCP
candidates. From that perspective, the change makes existing
implementations no less compliant with JSEP than they were before.

What this change does provide is both on-paper and in-the-future
compatibility between WebRTC implementations once they finalize TCP
candidate handling (and candidate handling in general for mid-session
offers).

=C2=A0=C2=A0 https://github.com/rtcweb-wg/jsep/pull/= 862/files

The key insight here is that JSEP's use of ICE completely discards any =
meaning associated with the transport parameter, while SIP's use of ICE=
does not. The trivial change that I propose, which bears only on future WebRTC implementations -- that is, which has no as-built specification
to point to -- allows JSEP to continue to ignore the value of the
transport parameter, while specifying that it says the right thing for
SIP implementations to function properly.

/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000b5dd6005805fb409-- From nobody Sat Jan 26 17:45:35 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AB712896A for ; Sat, 26 Jan 2019 17:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.642 X-Spam-Level: X-Spam-Status: No, score=-17.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouGVkqdxEsKh for ; Sat, 26 Jan 2019 17:45:31 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A1B1288BD for ; Sat, 26 Jan 2019 17:45:31 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id f4so10744559ion.2 for ; Sat, 26 Jan 2019 17:45:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=81GfJHQrZSkyEC9kobI9SuGuozXsuIFPt25QTdFUERE=; b=fXe0hU5q/oHfM3+ff7ceBmgZ4wks9ss+wrBnOS0jyFTBNYWfLnD+nICJI3PQll2OkT 8l91DWJ1S9gPGzGAt5QiosdIughBNkI9Uw0agkNIG5sKkM0t1uRKPH351xQSiQmJ2K5K PhdAwFMO2Vw+cdRNVUF2UAqNzob3jSeNnENQYMmRyto8qhlIMvoiXrU5xQ7u8uOS98F+ NdD6yHH25ccBLcYc2Xtu/fkrGH5wpeh+D+xQASl9KXAU/f3PO5NuJ5pgMxPFJE7Clq7U WWY7gt3Z1g5AKUh1Vv3zrLLHvkmL7ojKKuZhq/GINHIsV5EN21c9vvRHrD5DG/mHOvIm 9lrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=81GfJHQrZSkyEC9kobI9SuGuozXsuIFPt25QTdFUERE=; b=qqvry4iVRk/IgAPlKlmsR9cKitf8BGqpm4n8yTOlSZMDLQfam/gJwrt8rvbbgNgysZ l0jb7+0bC8T4SURuhdCyCRBeUayVWNFN9wA2hShrkBN3q808ck/FYEWqEL88aaGAgAH7 mwcb18YVQH0hnuKCNheYyzGOFVL4OqNDEzAB3aKbdItrb3BIH+wPlGnQDnWy9UUMrT5o MvUUz7yRKSfrJIUVYIEmUNZZZOkoFzCiNzEidUrbCU53+Tvc287bN8C781UHZvNCRuLf EscZtFLsi9pRRJLOCVEFMjMkDVuHqaTQ+esI+cozo8qqhqus+bUkws1ZURA6c/BnF0Rg 4K8Q== X-Gm-Message-State: AJcUukdN4Obu4Oxl2lu3qQc2jglc9UcjKIxXP3ZNgaXd3o7pVfSlXSo0 oSl5892OsebZ5vBhKh2cMt+IWZltGbRXJEWhlM2Evw== X-Google-Smtp-Source: ALg8bN4v/uZZ41zqCd+Ck6imp/fYSHDMyTJHCtKQ1pn+8CTdBHwNy2MePsJxk594cMutQxqa2MJaTEEH/MjrpBj+hfE= X-Received: by 2002:a6b:da10:: with SMTP id x16mr9640511iob.101.1548553530746; Sat, 26 Jan 2019 17:45:30 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> In-Reply-To: From: Justin Uberti Date: Sat, 26 Jan 2019 17:45:17 -0800 Message-ID: To: Eric Rescorla Cc: Adam Roach , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001e0b29058066b7f8" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Sun, 27 Jan 2019 01:45:34 -0000 --0000000000001e0b29058066b7f8 Content-Type: text/plain; charset="UTF-8" I agree with Eric, but in the interest of moving forward, I am willing to live with the relatively straightforward solution of using TCP in the m= line when the default candidate is a TCP candidate. On Sat, Jan 26, 2019 at 9:23 AM Eric Rescorla wrote: > I'm not yet persuaded this is needed. The alleged need here is that there > are some ICE-implementing endpoints which will choke if they see a profile > that doesn't match any actual candidate. I recognize that this is required > by 5245, but that doesn't mean anyone ever did it. Can you please point me > to a client which would interoperate with a WebRTC endpoint with this > change that would not if you just always sent the same profile as JSEP > currently requires. > > -Ekr > > > > On Thu, Jan 24, 2019 at 11:12 AM Adam Roach wrote: > >> Based on conversations in MMUSIC, as well as several offline >> conversations with interested parties, I've put together a proposed >> change to JSEP that, if accepted, will allow publication of the Cluster >> 238 documents to move forward. >> >> Note that this new text has no impact on existing implementations (at >> least, as far as I am able to discern), which do not currently have the >> capability of producing media sections consisting of exclusively TCP >> candidates. From that perspective, the change makes existing >> implementations no less compliant with JSEP than they were before. >> >> What this change does provide is both on-paper and in-the-future >> compatibility between WebRTC implementations once they finalize TCP >> candidate handling (and candidate handling in general for mid-session >> offers). >> >> https://github.com/rtcweb-wg/jsep/pull/862/files >> >> The key insight here is that JSEP's use of ICE completely discards any >> meaning associated with the transport parameter, while SIP's use of ICE >> does not. The trivial change that I propose, which bears only on future >> WebRTC implementations -- that is, which has no as-built specification >> to point to -- allows JSEP to continue to ignore the value of the >> transport parameter, while specifying that it says the right thing for >> SIP implementations to function properly. >> >> /a >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000001e0b29058066b7f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Eric, but in the interest of moving forward, = I am willing to live with the relatively straightforward solution of using = TCP in the m=3D line when the default candidate is a TCP candidate.
On Sat, = Jan 26, 2019 at 9:23 AM Eric Rescorla <e= kr@rtfm.com> wrote:
I'm not yet persuaded this is needed. = The alleged need here is that there are some ICE-implementing endpoints whi= ch will choke if they see a profile that doesn't match any actual candi= date. I recognize that this is required by 5245, but that doesn't mean = anyone ever did it. Can you please point me to a client which would interop= erate with a WebRTC endpoint with this change that would not if you just al= ways sent the same profile as JSEP currently requires.

-Ekr



On Thu, Jan 24, 2019 at 11:12 AM Adam Roach <adam@nostrum.com> wrote:
Based on conversations in MMUS= IC, as well as several offline
conversations with interested parties, I've put together a proposed change to JSEP that, if accepted, will allow publication of the Cluster 238 documents to move forward.

Note that this new text has no impact on existing implementations (at
least, as far as I am able to discern), which do not currently have the capability of producing media sections consisting of exclusively TCP
candidates. From that perspective, the change makes existing
implementations no less compliant with JSEP than they were before.

What this change does provide is both on-paper and in-the-future
compatibility between WebRTC implementations once they finalize TCP
candidate handling (and candidate handling in general for mid-session
offers).

=C2=A0=C2=A0 https://github.com/rtcweb-wg/jsep/pull/= 862/files

The key insight here is that JSEP's use of ICE completely discards any =
meaning associated with the transport parameter, while SIP's use of ICE=
does not. The trivial change that I propose, which bears only on future WebRTC implementations -- that is, which has no as-built specification
to point to -- allows JSEP to continue to ignore the value of the
transport parameter, while specifying that it says the right thing for
SIP implementations to function properly.

/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000001e0b29058066b7f8-- From nobody Sun Jan 27 03:22:05 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E580C12870E for ; Sun, 27 Jan 2019 03:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.853 X-Spam-Level: X-Spam-Status: No, score=-8.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Lu4T1V+S; dkim=pass (1024-bit key) header.d=ericsson.com header.b=cSFgrzJg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zjWdnsoKPAu for ; Sun, 27 Jan 2019 03:22:02 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0A712D4ED for ; Sun, 27 Jan 2019 03:22:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1548588118; x=1551180118; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HV26EyP7CVhlbCWR7yYkDhrs8Q1ZacGsxabNCCksSIU=; b=Lu4T1V+SJO1yd0wWCXjAJ5Y0198bF9/bsRp6xSdHoafxT2h1VEaPEXnYFsYn3gnT 4VWrAfZuKWGjNk3b1cNBJ8b86Wnup6WLxxmZpYStdBkMsmdBevLn/32RssqcFKoE 4YGdUvBzCO4st7+WE46T7b73BRtKQIXyUk4lZoeWC00=; X-AuditID: c1b4fb2d-d9dff7000000062f-27-5c4d9456d666 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 05.A4.01583.6549D4C5; Sun, 27 Jan 2019 12:21:58 +0100 (CET) Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sun, 27 Jan 2019 12:21:58 +0100 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sun, 27 Jan 2019 12:21:58 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HV26EyP7CVhlbCWR7yYkDhrs8Q1ZacGsxabNCCksSIU=; b=cSFgrzJgeI9oRVHNzRszXm+9/YFtEzdk84742rg4//Uv6uZc75aupTQzNo+WJsueojMtmoqbVFngCtik8+BiGxcxE96QQZXCaVYsfXGPDJELrpNNyUYanILzLJNlnFJUlkTZkkK9KI4QE9HVcNBA7nY/QjBuMXZDCDmUD2SCfWU= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4171.eurprd07.prod.outlook.com (20.176.166.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.12; Sun, 27 Jan 2019 11:21:57 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0%4]) with mapi id 15.20.1580.012; Sun, 27 Jan 2019 11:21:57 +0000 From: Christer Holmberg To: Eric Rescorla , Adam Roach CC: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Proposal to break the ICE impasse Thread-Index: AQHUtCoOCID4ifgvbk+6P/h8fwfLKaXBz0cAgAEnOzc= Date: Sun, 27 Jan 2019 11:21:56 +0000 Message-ID: References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [2001:14bb:43:4680:198e:d12e:31d:2a55] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB4171; 6:4zfH8WzLisEK40JtMCt32wDy4prCawzAFm5gBoMVcjvUw1tJDk/pV0iY/vCvZIYTtecgjYVtWBglM/du3dxRz6g9D84xE2ZEI3kTQuLVXKwGXHXMGx8IjucGpE/+oweBYDQQwwuVWHbmFxutz/qJYeEJ+oGecN1ozVltkL+lECYMOaYrk5qyLtZObj0+kA9Tc5P/EygA+BIvhRSXNNvhKJiVx8unGQ2qX3nQAz1fDHpXz/o1mGbtDEdsKYhdb1pXkGXdjAPRr7iaq/HhnVUqyHMbGD56rShqoP4pa6fu4nFCR7HTiY7Sl23dq9Twn8JpUN4b2MBOncuA8tEF1bczH45Vc2hy4B9ExXHGQn8oPROBQG5FNY9ASsHneYy1Gfi+vZmYfjaUvC//38SrxO68kG6ONIr78T2waB40ybP5rvlbENdpnVzNbc2MA8fQmAqJoaiOTteAdetS/6snUyu8gQ==; 5:ppbU40qABIbg4lmpOtLeLsuBLsXAZu9wpz2yT3kn3brzgHZRlzvkvt19htayaY1RWetlL1qJ0dOI5Uf1x9IdZ/GODRlp9QwIf7IM+uOfxsaBJC+JhnQuz52GY2iSgID0cSCaLe45qhN82xcC+leyhrZFPv+Bi01XXO7PurHB74XcFUtZHCSDTwy988ci63Lpqd3g146UjHSLAY2dRutftg==; 7:h5w6PRpvlQM0weU+KfDo04khtCMlhRDCeZ0cZKsNnz3+RABpYkHMvygJf31aWFO8W9cg91ys0tW/Ei4pKVosX3Xav2bZmHliLDTuIUni7kZaKtI3imbzewnzT0hAz/bY4a/JsodXEWVrriFmKI0zjw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 80e7946d-85c7-4048-2ee4-08d68449a5f0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4171; x-ms-traffictypediagnostic: HE1PR07MB4171: x-microsoft-antispam-prvs: x-forefront-prvs: 0930AAFAD9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(136003)(366004)(396003)(189003)(199004)(7736002)(966005)(102836004)(19627405001)(6436002)(1015004)(186003)(74316002)(11346002)(476003)(446003)(44832011)(486006)(110136005)(229853002)(6246003)(97736004)(316002)(6116002)(68736007)(6606003)(6506007)(105586002)(53546011)(86362001)(46003)(53936002)(106356001)(9686003)(54896002)(33656002)(236005)(6306002)(99286004)(71200400001)(55016002)(71190400001)(81166006)(81156014)(478600001)(606006)(256004)(2906002)(8676002)(76176011)(14454004)(7696005)(14444005)(8936002)(4326008)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4171; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: yX4giLS8VGr2VAIYaOA/ri0e6GJryJVrx49rJM0i7aKcXFm0c+EYoRUEqVAF7eqChA7QTb0hIBwKv3IwpRwUShv/G6oknsnp5K7xEGbr9hxMEfjFU5FL0duzhGfkwayhz9r8eV5xecXS2bWSrD5VaQg+IZ5sQvAyKWSnMVFOyrXsWnEbpmuLljlV/oNOwuiWYKmg9QiszWZDRAQ7QWYBRw3VUERPIm0R76nEbv/7nht6TLeXYewp3GeJY5toDbNNy5Ahqw3637rgb5bH/dpmanPlX0inoABxl2DL4YRzm1MlPZOUs+Rs+dbsFbkVaIsPy5uro5+XIE+hFX95mCjqzzuQlynbv+Hs4VumHtbOiMCEnnYXhZi4mKPeq9DaGdJm1H+btLUnYh2zVtYmXVw4oAjlanRWK/GULyK0JALTjPc= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3161B0F1D2B5AC9DA72DDFAD93950HE1PR07MB3161eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 80e7946d-85c7-4048-2ee4-08d68449a5f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2019 11:21:56.9172 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4171 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA03SfUiTQRwH8G7Ps+1xNTqX5g/NPxr0ps3SIpeJbyANbL4UhMYgh3uYpk7b szSDQNJSZjDRWWqZZUvETE0Ds4x0+IImLi3LrD9MTRExBMMyc+W8Bf73uft97353xzGUpInv yaToDKxep06TCkR0RXxbtuysWak63NwslXes1QjldfNDQvkTe4EwjFJYLCs8RWX7NK0onbpB xVLnRMEaNi0li9UfCkkUJReU9PAz74ZdfllSLMxFt48ZEcMAPgp5nawRuTAS3I2g9XeqEYnW vYygcfEDRQYWHky/mUOOFI2LKRgvFJBCKQ9aOkYRGUwi6MnvQ45tBVgORXZfxwI3HAqDvXm0 wxTeB18eDgkdkR04EEaaDpKIHJbfG2niIHhR1U2RXnugYeGW0GExVkFfRaezVR6CqdG1jYIL jgPT05kNI7wTfg408EgvDxifrt4wYAyWDhtF7A5zU3Y+yavhdf2Ec14Oi4XlNLE3jFQXIeJr QjB/jCaWwWJZmTOvBFvrlNOfECy3BxL7wKPCEQFxKix1D/CJd0F57gzfcQHAc3x4ZWngFyNZ 5aazVq6/C4UzwDieXblxZ1for5imScQPxsrMAmJfqH0wTxHLoNxupTfP30fCeuTOsRyXrg04 4sfqU5I4LkPnp2MNLWj9G3U9W5U9R4/nw60IM0i6TTxcolRJ+OosLifdioChpG5iFxylkog1 6pwrrD7jvP5SGstZkRdDSz3EfySuKgnWqg1sKstmsvr/VR7j4pmLUpVb5hNaZ0MGo30MzOl8 /35z7QIXytkm7mka94fXxdSITMGK1cDIO3Gm2JakGPkF5d64ya/+5d674xcuXv38wxO9+/sr 3nQ9OTHgTMJNVVvrUoR/fbOtSiM6EdV76nsQ4xU1PNsSWbAycdx0Uqsd2+rp1RVZtV2xVGh7 e0D7LUJKc8lqfx9Kz6n/AZIhEqpCAwAA Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Sun, 27 Jan 2019 11:22:04 -0000 --_000_HE1PR07MB3161B0F1D2B5AC9DA72DDFAD93950HE1PR07MB3161eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, > I'm not yet persuaded this is needed. The alleged need here is that there= are some ICE-implementing endpoints which will choke if > they see a profile that doesn't match any actual candidate. I recognize t= hat this is required by 5245, but that doesn't mean anyone > ever did it. Can you please point me to a client which would interoperate= with a WebRTC endpoint with this change that would not > if you just always sent the same profile as JSEP currently requires. I don't think it is ok to *specify* that discarding a MUST is ok as long as= nobody can show an implementation that would break by doing so. Having said that, in order to prevent an RTCWEB shutdown I am generally ok = with Adam's approach. I would like my pull request comments to be addressed= , though, that is related to separation between the JSEP API and an applica= tion using it: an application should be allowed to act according to 5245/dr= aft-ice-sdp and update the c/m line if it wishes to, but due to the way the= JSEP API works such applications might sometimes always include the same v= alue in the c/m- line. I also think it shall be explicitly written that JSEP does not update 5245/= draft-ice-sdp, but rather deviates when it comes to the c/m- line. Regards, Christer On Thu, Jan 24, 2019 at 11:12 AM Adam Roach > wrote: Based on conversations in MMUSIC, as well as several offline conversations with interested parties, I've put together a proposed change to JSEP that, if accepted, will allow publication of the Cluster 238 documents to move forward. Note that this new text has no impact on existing implementations (at least, as far as I am able to discern), which do not currently have the capability of producing media sections consisting of exclusively TCP candidates. From that perspective, the change makes existing implementations no less compliant with JSEP than they were before. What this change does provide is both on-paper and in-the-future compatibility between WebRTC implementations once they finalize TCP candidate handling (and candidate handling in general for mid-session offers). https://github.com/rtcweb-wg/jsep/pull/862/files The key insight here is that JSEP's use of ICE completely discards any meaning associated with the transport parameter, while SIP's use of ICE does not. The trivial change that I propose, which bears only on future WebRTC implementations -- that is, which has no as-built specification to point to -- allows JSEP to continue to ignore the value of the transport parameter, while specifying that it says the right thing for SIP implementations to function properly. /a _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_HE1PR07MB3161B0F1D2B5AC9DA72DDFAD93950HE1PR07MB3161eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

> I'm not yet persuaded this is needed. The alleged need here is th= at there are some ICE-implementing endpoints which will choke if 
> they see a profile that doesn't match any actual candidate. I recogniz= e that this is required by 5245, but that doesn't mean anyone 
> ever did it. Can you please point me to a client which would interoper= ate with a WebRTC endpoint with this change that would not 
> if you just always sent the same profile as JSEP currently requir= es.

I don't think it is ok to *specify* that discarding a MUST is ok as lo= ng as nobody can show an implementation that would break by doing so.

Having said that, in order to prevent an RTCWEB shutdown I am generall= y ok with Adam's approach. I would like my pull request comments to be addr= essed, though, that is related to separation between the JSEP API and an ap= plication using it: an application should be allowed to act according to 5245/draft-ice-sdp and update the c/= m line if it wishes to, but due to the way the JSEP API works such applicat= ions might sometimes always include the same value in the c/m- line. <= /div>

I also think it shall be explicitly written that JSEP does not update = 5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line.

Regards,

Christer




On Thu, Jan 24, 2019 at 11:12 AM Ad= am Roach <adam@nostrum.com> wrote:
Based on conversations in MMUSIC, as well as several offline
conversations with interested parties, I've put together a proposed
change to JSEP that, if accepted, will allow publication of the Cluster 238 documents to move forward.

Note that this new text has no impact on existing implementations (at
least, as far as I am able to discern), which do not currently have the capability of producing media sections consisting of exclusively TCP
candidates. From that perspective, the change makes existing
implementations no less compliant with JSEP than they were before.

What this change does provide is both on-paper and in-the-future
compatibility between WebRTC implementations once they finalize TCP
candidate handling (and candidate handling in general for mid-session
offers).

   https://github.com/rtcweb-wg/jsep/pull/862/files

The key insight here is that JSEP's use of ICE completely discards any
meaning associated with the transport parameter, while SIP's use of ICE does not. The trivial change that I propose, which bears only on future WebRTC implementations -- that is, which has no as-built specification
to point to -- allows JSEP to continue to ignore the value of the
transport parameter, while specifying that it says the right thing for
SIP implementations to function properly.

/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--_000_HE1PR07MB3161B0F1D2B5AC9DA72DDFAD93950HE1PR07MB3161eurp_-- From nobody Mon Jan 28 11:39:18 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1A41311BE for ; Mon, 28 Jan 2019 11:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pek6gjRlU2De for ; Mon, 28 Jan 2019 11:39:14 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579581311B3 for ; Mon, 28 Jan 2019 11:39:14 -0800 (PST) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0SJdCbF014337 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 28 Jan 2019 13:39:13 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1548704353; bh=rjEK+qbBkcqwBrtqTQwGrmVo+quCK++tYDE6tlScfVY=; h=Subject:To:References:From:Date:In-Reply-To; b=JW3wAXlsKDwyRc5bMwWgQCEu9YcprfTXIuVy4hbMctxGaGN8RNWOEsLLEWbpvfN0J CgjFs9d3Zlq6vhoOzipK5HOO3Ipj5GsKw+zNtOyzsJNbc8n1ue9OLyiYepyiuhA8NJ sNV4TkonbfsmnNkfeYKUG6EPLzPbTTILfdef6zTc= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: "rtcweb@ietf.org" , Roman Shpount References: From: Adam Roach Message-ID: Date: Mon, 28 Jan 2019 13:39:06 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1C6B608D2BD2E18DE5F2A215" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] [rtcweb-wg/jsep] JSEP says that subsequent offers need to specify the ICE protocol (#854) X-BeenThere: rtcweb@ietf.org 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: Mon, 28 Jan 2019 19:39:17 -0000 This is a multi-part message in MIME format. --------------1C6B608D2BD2E18DE5F2A215 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Taking it back to the RTCWEB mailing list. This seems like a better formulation than the text that I put together, and it is a similarly minimal change that has no impact on any current WebRTC implementations (at least, that I know of). Justin -- if you're willing to craft text that captures this, you'll probably do a better job of doing it in a style that matches the rest of JSEP than I can. /a On 1/28/19 1:33 PM, Roman Shpount wrote: > My proposal was to use TCP/DTLS/blah whenever the default candidate is a > TCP candidate and *ICE nomination is complete*. If TCP candidate become > default candidate after ICE nomination is complete, both end points should > support TCP/DTLS based protocol. In all other cases, candidates are > either still being collected or UDP candidate should be present and > used as > default. > > In the initial offer, when ICE nomination is in progress, when ICE restart > is initiated, end points must still use UDP based proto, since we do not > want them to send TCP based offer if remote does not support it or change > the proto during the ICE negotiation. > > Regards, > _____________ > Roman Shpount > > > On Sat, Jan 26, 2019 at 8:29 PM Justin Uberti > wrote: > > > Path in #862 seems to be to > > use TCP/DTLS/blah whenever the default candidate is a TCP candidate. As > > discussed in #394 , this > > will break endpoints that don't understand the TCP/DTLS/RTP/SAVPF proto > > name, but at this point such endpoints should be rare. > > > > — > > You are receiving this because you commented. > > Reply to this email directly, view it on GitHub > > > , > or mute > > the thread > > > > > . > > > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > , > or mute the thread > . > --------------1C6B608D2BD2E18DE5F2A215 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+CiAgPC9oZWFkPgogIDxib2R5IHRl eHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPgogICAgPGRpdiBjbGFzcz0ibW96LWNp dGUtcHJlZml4Ij5UYWtpbmcgaXQgYmFjayB0byB0aGUgUlRDV0VCIG1haWxpbmcKICAgICAg bGlzdC48L2Rpdj4KICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+PGJyPgogICAg PC9kaXY+CiAgICA8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPlRoaXMgc2VlbXMgbGlr ZSBhIGJldHRlciBmb3JtdWxhdGlvbgogICAgICB0aGFuIHRoZSB0ZXh0IHRoYXQgSSBwdXQg dG9nZXRoZXIsIGFuZCBpdCBpcyBhIHNpbWlsYXJseSBtaW5pbWFsCiAgICAgIGNoYW5nZSB0 aGF0IGhhcyBubyBpbXBhY3Qgb24gYW55IGN1cnJlbnQgV2ViUlRDIGltcGxlbWVudGF0aW9u cwogICAgICAoYXQgbGVhc3QsIHRoYXQgSSBrbm93IG9mKS48L2Rpdj4KICAgIDxkaXYgY2xh c3M9Im1vei1jaXRlLXByZWZpeCI+PGJyPgogICAgPC9kaXY+CiAgICA8ZGl2IGNsYXNzPSJt b3otY2l0ZS1wcmVmaXgiPkp1c3RpbiAtLSBpZiB5b3UncmUgd2lsbGluZyB0byBjcmFmdAog ICAgICB0ZXh0IHRoYXQgY2FwdHVyZXMgdGhpcywgeW91J2xsIHByb2JhYmx5IGRvIGEgYmV0 dGVyIGpvYiBvZiBkb2luZwogICAgICBpdCBpbiBhIHN0eWxlIHRoYXQgbWF0Y2hlcyB0aGUg cmVzdCBvZiBKU0VQIHRoYW4gSSBjYW4uPC9kaXY+CiAgICA8ZGl2IGNsYXNzPSJtb3otY2l0 ZS1wcmVmaXgiPjxicj4KICAgIDwvZGl2PgogICAgPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJl Zml4Ij4vYTxicj4KICAgIDwvZGl2PgogICAgPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4 Ij48YnI+CiAgICA8L2Rpdj4KICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24g MS8yOC8xOSAxOjMzIFBNLCBSb21hbiBTaHBvdW50CiAgICAgIHdyb3RlOjxicj4KICAgIDwv ZGl2PgogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIKICAgICAgY2l0ZT0ibWlkOnJ0Y3dl Yi13ZyUyRmpzZXAlMkZpc3N1ZXMlMkY4NTQlMkY0NTgyNjk4NjRAZ2l0aHViLmNvbSI+CiAg ICAgIDxtZXRhIGh0dHAtZXF1aXY9ImNvbnRlbnQtdHlwZSIgY29udGVudD0idGV4dC9odG1s OyBjaGFyc2V0PVVURi04Ij4KICAgICAgTXkgcHJvcG9zYWwgd2FzIHRvIHVzZSBUQ1AvRFRM Uy9ibGFoIHdoZW5ldmVyIHRoZSBkZWZhdWx0CiAgICAgIGNhbmRpZGF0ZSBpcyBhPGJyPgog ICAgICBUQ1AgY2FuZGlkYXRlIGFuZCAqSUNFIG5vbWluYXRpb24gaXMgY29tcGxldGUqLiBJ ZiBUQ1AgY2FuZGlkYXRlCiAgICAgIGJlY29tZTxicj4KICAgICAgZGVmYXVsdCBjYW5kaWRh dGUgYWZ0ZXIgSUNFIG5vbWluYXRpb24gaXMgY29tcGxldGUsIGJvdGggZW5kCiAgICAgIHBv aW50cyBzaG91bGQ8YnI+CiAgICAgIHN1cHBvcnQgVENQL0RUTFMgYmFzZWQgcHJvdG9jb2wu IEluIGFsbCBvdGhlciBjYXNlcywgY2FuZGlkYXRlcwogICAgICBhcmU8YnI+CiAgICAgIGVp dGhlciBzdGlsbCBiZWluZyBjb2xsZWN0ZWQgb3IgVURQIGNhbmRpZGF0ZSBzaG91bGQgYmUg cHJlc2VudAogICAgICBhbmQgdXNlZCBhczxicj4KICAgICAgZGVmYXVsdC48YnI+CiAgICAg IDxicj4KICAgICAgSW4gdGhlIGluaXRpYWwgb2ZmZXIsIHdoZW4gSUNFIG5vbWluYXRpb24g aXMgaW4gcHJvZ3Jlc3MsIHdoZW4gSUNFCiAgICAgIHJlc3RhcnQ8YnI+CiAgICAgIGlzIGlu aXRpYXRlZCwgZW5kIHBvaW50cyBtdXN0IHN0aWxsIHVzZSBVRFAgYmFzZWQgcHJvdG8sIHNp bmNlIHdlCiAgICAgIGRvIG5vdDxicj4KICAgICAgd2FudCB0aGVtIHRvIHNlbmQgVENQIGJh c2VkIG9mZmVyIGlmIHJlbW90ZSBkb2VzIG5vdCBzdXBwb3J0IGl0IG9yCiAgICAgIGNoYW5n ZTxicj4KICAgICAgdGhlIHByb3RvIGR1cmluZyB0aGUgSUNFIG5lZ290aWF0aW9uLjxicj4K ICAgICAgPGJyPgogICAgICBSZWdhcmRzLDxicj4KICAgICAgX19fX19fX19fX19fXzxicj4K ICAgICAgUm9tYW4gU2hwb3VudDxicj4KICAgICAgPGJyPgogICAgICA8YnI+CiAgICAgIE9u IFNhdCwgSmFuIDI2LCAyMDE5IGF0IDg6MjkgUE0gSnVzdGluIFViZXJ0aQogICAgICA8YSBj bGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86bm90aWZpY2F0aW9u c0BnaXRodWIuY29tIj4mbHQ7bm90aWZpY2F0aW9uc0BnaXRodWIuY29tJmd0OzwvYT48YnI+ CiAgICAgIHdyb3RlOjxicj4KICAgICAgPGJyPgogICAgICAmZ3Q7IFBhdGggaW4gIzg2Mgog ICAgICA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJodHRwczovL2dp dGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAvcHVsbC84NjIiPiZsdDtodHRwczovL2dpdGh1Yi5j b20vcnRjd2ViLXdnL2pzZXAvcHVsbC84NjImZ3Q7PC9hPiBzZWVtcyB0byBiZSB0bzxicj4K ICAgICAgJmd0OyB1c2UgVENQL0RUTFMvYmxhaCB3aGVuZXZlciB0aGUgZGVmYXVsdCBjYW5k aWRhdGUgaXMgYSBUQ1AKICAgICAgY2FuZGlkYXRlLiBBczxicj4KICAgICAgJmd0OyBkaXNj dXNzZWQgaW4gIzM5NAogICAgICA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBo cmVmPSJodHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAvaXNzdWVzLzM5NCI+Jmx0 O2h0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cvanNlcC9pc3N1ZXMvMzk0Jmd0OzwvYT4s IHRoaXM8YnI+CiAgICAgICZndDsgd2lsbCBicmVhayBlbmRwb2ludHMgdGhhdCBkb24ndCB1 bmRlcnN0YW5kIHRoZQogICAgICBUQ1AvRFRMUy9SVFAvU0FWUEYgcHJvdG88YnI+CiAgICAg ICZndDsgbmFtZSwgYnV0IGF0IHRoaXMgcG9pbnQgc3VjaCBlbmRwb2ludHMgc2hvdWxkIGJl IHJhcmUuPGJyPgogICAgICAmZ3Q7PGJyPgogICAgICAmZ3Q7IOKAlDxicj4KICAgICAgJmd0 OyBZb3UgYXJlIHJlY2VpdmluZyB0aGlzIGJlY2F1c2UgeW91IGNvbW1lbnRlZC48YnI+CiAg ICAgICZndDsgUmVwbHkgdG8gdGhpcyBlbWFpbCBkaXJlY3RseSwgdmlldyBpdCBvbiBHaXRI dWI8YnI+CiAgICAgICZndDsKPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJl Zj0iaHR0cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13Zy9qc2VwL2lzc3Vlcy84NTQjaXNzdWVj b21tZW50LTQ1Nzg4MDg2NiI+Jmx0O2h0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cvanNl cC9pc3N1ZXMvODU0I2lzc3VlY29tbWVudC00NTc4ODA4NjYmZ3Q7PC9hPiwKICAgICAgb3Ig bXV0ZTxicj4KICAgICAgJmd0OyB0aGUgdGhyZWFkPGJyPgogICAgICAmZ3Q7CjxhIGNsYXNz PSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9ub3Rp ZmljYXRpb25zL3Vuc3Vic2NyaWJlLWF1dGgvQUVoNVNoQS1fRjcwSE13RUNzSENhSHRfa0hj SlB4QmhrczV2SFFENmdhSnBaTTRYNVN2dyI+Jmx0O2h0dHBzOi8vZ2l0aHViLmNvbS9ub3Rp ZmljYXRpb25zL3Vuc3Vic2NyaWJlLWF1dGgvQUVoNVNoQS1fRjcwSE13RUNzSENhSHRfa0hj SlB4QmhrczV2SFFENmdhSnBaTTRYNVN2dyZndDs8L2E+PGJyPgogICAgICAmZ3Q7IC48YnI+ CiAgICAgICZndDs8YnI+CiAgICAgIDxwCiAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZTpzbWFs bDstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6bm9uZTtjb2xvcjojNjY2OyI+4oCUPGJyPgog ICAgICAgIFlvdSBhcmUgcmVjZWl2aW5nIHRoaXMgYmVjYXVzZSB5b3UgYXJlIHN1YnNjcmli ZWQgdG8gdGhpcwogICAgICAgIHRocmVhZC48YnI+CiAgICAgICAgUmVwbHkgdG8gdGhpcyBl bWFpbCBkaXJlY3RseSwgPGEKaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13Zy9q c2VwL2lzc3Vlcy84NTQjaXNzdWVjb21tZW50LTQ1ODI2OTg2NCIKICAgICAgICAgIG1vei1k by1ub3Qtc2VuZD0idHJ1ZSI+dmlldyBpdCBvbiBHaXRIdWI8L2E+LCBvciA8YQpocmVmPSJo dHRwczovL2dpdGh1Yi5jb20vbm90aWZpY2F0aW9ucy91bnN1YnNjcmliZS1hdXRoL0FDMWto RmlLWlNfV213dnU3RmZaMk5NZ0EtaHpzZjlsa3M1dkgxQ05nYUpwWk00WDVTdnciCiAgICAg ICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPm11dGUgdGhlIHRocmVhZDwvYT4uPGltZwpz cmM9Imh0dHBzOi8vZ2l0aHViLmNvbS9ub3RpZmljYXRpb25zL2JlYWNvbi9BQzFraERQOWNh M0lHNU9yXzAyQjVwUmxhbkFhdGhIcGtzNXZIMUNOZ2FKcFpNNFg1U3Z3LmdpZiIKICAgICAg ICAgIGFsdD0iIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIHdpZHRoPSIxIiBoZWlnaHQ9IjEi PjwvcD4KICAgICAgPHNjcmlwdCB0eXBlPSJhcHBsaWNhdGlvbi9qc29uIiBkYXRhLXNjb3Bl PSJpbmJveG1hcmt1cCI+eyJhcGlfdmVyc2lvbiI6IjEuMCIsInB1Ymxpc2hlciI6eyJhcGlf a2V5IjoiMDVkZGU1MGYxZDFhMzg0ZGQ3ODc2N2M1NTQ5M2U0YmIiLCJuYW1lIjoiR2l0SHVi In0sImVudGl0eSI6eyJleHRlcm5hbF9rZXkiOiJnaXRodWIvcnRjd2ViLXdnL2pzZXAiLCJ0 aXRsZSI6InJ0Y3dlYi13Zy9qc2VwIiwic3VidGl0bGUiOiJHaXRIdWIgcmVwb3NpdG9yeSIs Im1haW5faW1hZ2VfdXJsIjoiaHR0cHM6Ly9naXRodWIuZ2l0aHViYXNzZXRzLmNvbS9pbWFn ZXMvZW1haWwvbWVzc2FnZV9jYXJkcy9oZWFkZXIucG5nIiwiYXZhdGFyX2ltYWdlX3VybCI6 Imh0dHBzOi8vZ2l0aHViLmdpdGh1YmFzc2V0cy5jb20vaW1hZ2VzL2VtYWlsL21lc3NhZ2Vf Y2FyZHMvYXZhdGFyLnBuZyIsImFjdGlvbiI6eyJuYW1lIjoiT3BlbiBpbiBHaXRIdWIiLCJ1 cmwiOiJodHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAifX0sInVwZGF0ZXMiOnsi c25pcHBldHMiOlt7Imljb24iOiJQRVJTT04iLCJtZXNzYWdlIjoiQHJzaHBvdW50IGluICM4 NTQ6IE15IHByb3Bvc2FsIHdhcyB0byB1c2UgIFRDUC9EVExTL2JsYWggd2hlbmV2ZXIgdGhl IGRlZmF1bHQgY2FuZGlkYXRlIGlzIGFcblRDUCBjYW5kaWRhdGUgYW5kICpJQ0Ugbm9taW5h dGlvbiBpcyBjb21wbGV0ZSouIElmIFRDUCBjYW5kaWRhdGUgYmVjb21lXG5kZWZhdWx0IGNh bmRpZGF0ZSBhZnRlciBJQ0Ugbm9taW5hdGlvbiBpcyBjb21wbGV0ZSwgYm90aCBlbmQgcG9p bnRzIHNob3VsZFxuc3VwcG9ydCAgVENQL0RUTFMgIGJhc2VkIHByb3RvY29sLiBJbiBhbGwg b3RoZXIgY2FzZXMsIGNhbmRpZGF0ZXMgYXJlXG5laXRoZXIgc3RpbGwgYmVpbmcgY29sbGVj dGVkIG9yIFVEUCBjYW5kaWRhdGUgc2hvdWxkIGJlIHByZXNlbnQgYW5kIHVzZWQgYXNcbmRl ZmF1bHQuXG5cbkluIHRoZSBpbml0aWFsIG9mZmVyLCB3aGVuIElDRSBub21pbmF0aW9uIGlz IGluIHByb2dyZXNzLCB3aGVuIElDRSByZXN0YXJ0XG5pcyBpbml0aWF0ZWQsIGVuZCBwb2lu dHMgbXVzdCBzdGlsbCB1c2UgVURQIGJhc2VkIHByb3RvLCBzaW5jZSB3ZSBkbyBub3Rcbndh bnQgdGhlbSB0byBzZW5kIFRDUCBiYXNlZCBvZmZlciBpZiByZW1vdGUgZG9lcyBub3Qgc3Vw cG9ydCBpdCBvciBjaGFuZ2VcbnRoZSBwcm90byBkdXJpbmcgdGhlIElDRSBuZWdvdGlhdGlv bi5cblxuUmVnYXJkcyxcbl9fX19fX19fX19fX19cblJvbWFuIFNocG91bnRcblxuXG5PbiBT YXQsIEphbiAyNiwgMjAxOSBhdCA4OjI5IFBNIEp1c3RpbiBVYmVydGkgXHUwMDNjbm90aWZp Y2F0aW9uc0BnaXRodWIuY29tXHUwMDNlXG53cm90ZTpcblxuXHUwMDNlIFBhdGggaW4gIzg2 MiBcdTAwM2NodHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAvcHVsbC84NjJcdTAw M2Ugc2VlbXMgdG8gYmUgdG9cblx1MDAzZSB1c2UgVENQL0RUTFMvYmxhaCB3aGVuZXZlciB0 aGUgZGVmYXVsdCBjYW5kaWRhdGUgaXMgYSBUQ1AgY2FuZGlkYXRlLiBBc1xuXHUwMDNlIGRp c2N1c3NlZCBpbiAjMzk0IFx1MDAzY2h0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cvanNl cC9pc3N1ZXMvMzk0XHUwMDNlLCB0aGlzXG5cdTAwM2Ugd2lsbCBicmVhayBlbmRwb2ludHMg dGhhdCBkb24ndCB1bmRlcnN0YW5kIHRoZSBUQ1AvRFRMUy9SVFAvU0FWUEYgcHJvdG9cblx1 MDAzZSBuYW1lLCBidXQgYXQgdGhpcyBwb2ludCBzdWNoIGVuZHBvaW50cyBzaG91bGQgYmUg cmFyZS5cblx1MDAzZVxuXHUwMDNlIOKAlFxuXHUwMDNlIFlvdSBhcmUgcmVjZWl2aW5nIHRo aXMgYmVjYXVzZSB5b3UgY29tbWVudGVkLlxuXHUwMDNlIFJlcGx5IHRvIHRoaXMgZW1haWwg ZGlyZWN0bHksIHZpZXcgaXQgb24gR2l0SHViXG5cdTAwM2UgXHUwMDNjaHR0cHM6Ly9naXRo dWIuY29tL3J0Y3dlYi13Zy9qc2VwL2lzc3Vlcy84NTQjaXNzdWVjb21tZW50LTQ1Nzg4MDg2 Nlx1MDAzZSwgb3IgbXV0ZVxuXHUwMDNlIHRoZSB0aHJlYWRcblx1MDAzZSBcdTAwM2NodHRw czovL2dpdGh1Yi5jb20vbm90aWZpY2F0aW9ucy91bnN1YnNjcmliZS1hdXRoL0FFaDVTaEEt X0Y3MEhNd0VDc0hDYUh0X2tIY0pQeEJoa3M1dkhRRDZnYUpwWk00WDVTdndcdTAwM2Vcblx1 MDAzZSAuXG5cdTAwM2VcbiJ9XSwiYWN0aW9uIjp7Im5hbWUiOiJWaWV3IElzc3VlIiwidXJs IjoiaHR0cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13Zy9qc2VwL2lzc3Vlcy84NTQjaXNzdWVj b21tZW50LTQ1ODI2OTg2NCJ9fX08L3NjcmlwdD4KICAgICAgPHNjcmlwdCB0eXBlPSJhcHBs aWNhdGlvbi9sZCtqc29uIj5bCnsKIkBjb250ZXh0IjogImh0dHA6Ly9zY2hlbWEub3JnIiwK IkB0eXBlIjogIkVtYWlsTWVzc2FnZSIsCiJwb3RlbnRpYWxBY3Rpb24iOiB7CiJAdHlwZSI6 ICJWaWV3QWN0aW9uIiwKInRhcmdldCI6ICJodHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdn L2pzZXAvaXNzdWVzLzg1NCNpc3N1ZWNvbW1lbnQtNDU4MjY5ODY0IiwKInVybCI6ICJodHRw czovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAvaXNzdWVzLzg1NCNpc3N1ZWNvbW1lbnQt NDU4MjY5ODY0IiwKIm5hbWUiOiAiVmlldyBJc3N1ZSIKfSwKImRlc2NyaXB0aW9uIjogIlZp ZXcgdGhpcyBJc3N1ZSBvbiBHaXRIdWIiLAoicHVibGlzaGVyIjogewoiQHR5cGUiOiAiT3Jn YW5pemF0aW9uIiwKIm5hbWUiOiAiR2l0SHViIiwKInVybCI6ICJodHRwczovL2dpdGh1Yi5j b20iCn0KfQpdPC9zY3JpcHQ+CiAgICA8L2Jsb2NrcXVvdGU+CiAgICA8cD48YnI+CiAgICA8 L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --------------1C6B608D2BD2E18DE5F2A215-- From nobody Mon Jan 28 11:50:38 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20171311CF for ; Mon, 28 Jan 2019 11:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.641 X-Spam-Level: X-Spam-Status: No, score=-17.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrJHnl6Dr3F4 for ; Mon, 28 Jan 2019 11:50:34 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E77F1311CE for ; Mon, 28 Jan 2019 11:50:34 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id g85so379764ita.3 for ; Mon, 28 Jan 2019 11:50:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r23wJVUB9z4g01NtjSzYmPNY/Ae7gaBAw7oJk3eWvok=; b=MF8yJ7g70Uo7tyHllHwbm/7j61k8TOuOqNI2eN30BErbtv17ZYfkvep5y+SqZ/K0kM NXDv4N8w6xONNnF/rHfsgkjQCqc+rJ/Lpb8hbPnxfKHU8SuQ4d5cLOOeCDwGxCdjq/IP aKyOrhv3VBO4JisHLXL5n16ItQrM6k3MwlZwfbilhKoLn5/C5hO5wzhzF49hQnjkee+x oJHf8SS+djj8mmHwLSFAO/gsfkj0Ta/VkbkNgU939BRu29AvJBuh64K3d3cs7TdKQz3z KjI8V0OxgBx16bsIMlPj0DTCpPscBfaHckD9CVHeRh0COTbKFFiwCBm07Q1ZAc+0DuBh xVdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r23wJVUB9z4g01NtjSzYmPNY/Ae7gaBAw7oJk3eWvok=; b=HOFrEfzdyv9mh9nY9j4cQ76nxfmOyA0mw6q9B8EByUTnnwPr0ZWXySoUiAtGx1aYOl y0PRR3iAAMuglyoLm00snoxWSZUHITJaqYkZxPbqkGkCQCYbJcXmyns8Tp/qPnrQHAdu TAYlrIybcoZAxlcwkC5A9dDrk53I61qD87taJ0XD7WuVgijXuV9DdMyQpDOetGQD8ltV 0N6t952icXiUSdjv/OTq0lhLvH8ZDRVlK2wilMJ7rZu8sA2sQV4EFdjCC1g46DaC7htf OB5wQAYPAtuybdTS8pZF7s9iDT/6IdLYB6awIPxgUCI3GuYi8X5BbxyxiVimtYy84p3n 2IxQ== X-Gm-Message-State: AJcUukdu7gOKnZ5hXp77V5ehU1AWBHZb8+TW2uljNNYrJVW7PBbcQLU0 KH8TkxiCUyLpumla2/Qqnq5fjJMpo5u7rWSMPKiSww== X-Google-Smtp-Source: ALg8bN7VXOk4NYf2lyzOvMql12wkraCTbOGg7F015C4p5y3R5knWKF9ndivCCeWJDinOhJq3jHbEXqp6Ig8daeFuC5U= X-Received: by 2002:a24:738f:: with SMTP id y137mr10918027itb.136.1548705033084; Mon, 28 Jan 2019 11:50:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Mon, 28 Jan 2019 11:50:22 -0800 Message-ID: To: Adam Roach Cc: "rtcweb@ietf.org" , Roman Shpount Content-Type: multipart/alternative; boundary="0000000000005c5462058089fdf5" Archived-At: Subject: Re: [rtcweb] [rtcweb-wg/jsep] JSEP says that subsequent offers need to specify the ICE protocol (#854) X-BeenThere: rtcweb@ietf.org 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: Mon, 28 Jan 2019 19:50:37 -0000 --0000000000005c5462058089fdf5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK, will take a shot today or tomorrow. On Mon, Jan 28, 2019 at 11:39 AM Adam Roach wrote: > Taking it back to the RTCWEB mailing list. > > This seems like a better formulation than the text that I put together, > and it is a similarly minimal change that has no impact on any current > WebRTC implementations (at least, that I know of). > > Justin -- if you're willing to craft text that captures this, you'll > probably do a better job of doing it in a style that matches the rest of > JSEP than I can. > > /a > > On 1/28/19 1:33 PM, Roman Shpount wrote: > > My proposal was to use TCP/DTLS/blah whenever the default candidate is a > TCP candidate and *ICE nomination is complete*. If TCP candidate become > default candidate after ICE nomination is complete, both end points shoul= d > support TCP/DTLS based protocol. In all other cases, candidates are > either still being collected or UDP candidate should be present and used = as > default. > > In the initial offer, when ICE nomination is in progress, when ICE restar= t > is initiated, end points must still use UDP based proto, since we do not > want them to send TCP based offer if remote does not support it or change > the proto during the ICE negotiation. > > Regards, > _____________ > Roman Shpount > > > On Sat, Jan 26, 2019 at 8:29 PM Justin Uberti > > wrote: > > > Path in #862 > seems to be to > > use TCP/DTLS/blah whenever the default candidate is a TCP candidate. As > > discussed in #394 > , this > > will break endpoints that don't understand the TCP/DTLS/RTP/SAVPF proto > > name, but at this point such endpoints should be rare. > > > > =E2=80=94 > > You are receiving this because you commented. > > Reply to this email directly, view it on GitHub > > > , or > mute > > the thread > > > > > > . > > > > =E2=80=94 > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > , or= mute > the thread > > . > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000005c5462058089fdf5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, will take a shot today or tomorrow.

On Mon, Jan 28, 201= 9 at 11:39 AM Adam Roach <adam@nostr= um.com> wrote:
=20 =20 =20
Taking it bac= k to the RTCWEB mailing list.

This seems li= ke a better formulation than the text that I put together, and it is a similarly minimal change that has no impact on any current WebRTC implementations (at least, that I know of).

Justin -- if = you're willing to craft text that captures this, you'll probably do a better job of doing it in a style that matches the rest of JSEP than I can.

/a

On 1/28/19 1:= 33 PM, Roman Shpount wrote:
=20 My proposal was to use TCP/DTLS/blah whenever the default candidate is a
TCP candidate and *ICE nomination is complete*. If TCP candidate become
default candidate after ICE nomination is complete, both end points should
support TCP/DTLS based protocol. In all other cases, candidates are
either still being collected or UDP candidate should be present and used as
default.

In the initial offer, when ICE nomination is in progress, when ICE restart
is initiated, end points must still use UDP based proto, since we do not
want them to send TCP based offer if remote does not support it or change
the proto during the ICE negotiation.

Regards,
_____________
Roman Shpount


On Sat, Jan 26, 2019 at 8:29 PM Justin Uberti <notifications@githu= b.com>
wrote:

> Path in #862 <https://= github.com/rtcweb-wg/jsep/pull/862> seems to be to
> use TCP/DTLS/blah whenever the default candidate is a TCP candidate. As
> discussed in #394 <https:= //github.com/rtcweb-wg/jsep/issues/394>, this
> will break endpoints that don't understand the TCP/DTLS/RTP/SAVPF proto
> name, but at this point such endpoints should be rare.
>
> =E2=80=94
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/rtcweb-wg/jsep/issues/854#issuecomment-457880= 866>, or mute
> the thread
> <https://github.com/notificati= ons/unsubscribe-auth/AEh5ShA-_F70HMwECsHCaHt_kHcJPxBhks5vHQD6gaJpZM4X5Svw&g= t;
> .
>

=E2=80=94
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on Git= Hub, or mute = the thread.3D""

=20 =20


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000005c5462058089fdf5-- From nobody Mon Jan 28 14:51:24 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051B4130EE1 for ; Mon, 28 Jan 2019 14:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.641 X-Spam-Level: X-Spam-Status: No, score=-17.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVbGl_mCZESm for ; Mon, 28 Jan 2019 14:51:18 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75CEC130EE4 for ; Mon, 28 Jan 2019 14:51:18 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id z20so1153158itc.3 for ; Mon, 28 Jan 2019 14:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GuYUm0JVrfK/N53JLee1hbUDn/mBBg/UYcP44+dbfBY=; b=o0yDyQbsAgWo/ixQR0N9qo3yp15HUonYJLfNZyvLypvI57q8/l0OA0fQ1YBkl3eCPM 8ADhaLNs5LwjGpGIReJPykwlN/8NmdD2VaGzUhFjmvxpCVxVQRJ7Y56ERHpSoUYMiuBR RXkIIl613xmRpPtf0JVlHi5ZPXpl3H3mBdd4M7c0LADup9vbANJskjko9z/CFc31TvSA kooZanC4zOOcLcIjma3UeDvNTTHNToWXC2FBlZCbGY2OYdszMENv59jZ6cVGgzfPsXfI lUDvtbXyA7BRCzuGD1yaBCy5xpPk4DEGjiVAw6CKWOChq1DOuGKFaOUz8N99EHFRQd8v /v2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GuYUm0JVrfK/N53JLee1hbUDn/mBBg/UYcP44+dbfBY=; b=hNla4W7typ2JPj+U30deuVcf/9JogJOM9qx9avn1Q0YyRToR5nYmuh6cNDCEdXY9qm C7OmtyVRE9DMxm9Fsy3Yd5jk6BEhzTDJujoZMw9jtHIhIlSzyEk/mFUQj0BtvikSufzx 2NbD9aa4j0v7bhlVnPkNRQNnBXpkEU8nPTeICQpX40C0jLHsenW4IekGha4DE/SgyHnc /sgzXA77jk/roKDzTHU44gbuskLxoP/0iwEwL2FbIpHL0Qcxa4B15WHme5osOxahnJvT k7SfpBFlQsYgN1wofCb67PBcXAtAXmYZKyS2/wqr4Jhv+/oDlhctSKPCyyAnFGrw0Gmd bfiA== X-Gm-Message-State: AJcUukf1duEa8sFO2sBCayh79J6rroZFHoxRBrJpt5iU39p7FNKFy6TJ nlUvndJD59jUDOJH1CfnxOqGrpjkiohFxXtW7U5opA== X-Google-Smtp-Source: ALg8bN4CELb3wF4dKU5mhgMI0Ig9dfvVitlUsUyh4Pe+pt80AAUdeeJ0ioGSjFkMdtUFwOmL8X/cmDgUiImtxbWs+z4= X-Received: by 2002:a02:94eb:: with SMTP id x98mr14252032jah.88.1548715877276; Mon, 28 Jan 2019 14:51:17 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> In-Reply-To: From: Justin Uberti Date: Mon, 28 Jan 2019 14:51:05 -0800 Message-ID: To: Christer Holmberg Cc: Eric Rescorla , Adam Roach , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b9e7f705808c83be" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Mon, 28 Jan 2019 22:51:22 -0000 --000000000000b9e7f705808c83be Content-Type: text/plain; charset="UTF-8" Posted https://github.com/rtcweb-wg/jsep/pull/863 as a stab at a consensus. This basically says that the offerer fills in either UDP/TLS/foo or TCP/DTLS/foo based on the current default or selected candidate, in accordance with sip-sdp. As Adam mentioned before, this shouldn't have any impact on JSEP functionality. If this looks good, I'll polish it up. On Sun, Jan 27, 2019 at 3:22 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > I'm not yet persuaded this is needed. The alleged need here is that > there are some ICE-implementing endpoints which will choke if > > they see a profile that doesn't match any actual candidate. I recognize > that this is required by 5245, but that doesn't mean anyone > > ever did it. Can you please point me to a client which would > interoperate with a WebRTC endpoint with this change that would not > > if you just always sent the same profile as JSEP currently requires. > > I don't think it is ok to *specify* that discarding a MUST is ok as long > as nobody can show an implementation that would break by doing so. > > Having said that, in order to prevent an RTCWEB shutdown I am generally ok > with Adam's approach. I would like my pull request comments to be > addressed, though, that is related to separation between the JSEP API and > an application using it: an application should be allowed to act according > to 5245/draft-ice-sdp and update the c/m line if it wishes to, but due to > the way the JSEP API works such applications might sometimes always include > the same value in the c/m- line. > > I also think it shall be explicitly written that JSEP does not update > 5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line. > > Regards, > > Christer > > > > > On Thu, Jan 24, 2019 at 11:12 AM Adam Roach wrote: > > Based on conversations in MMUSIC, as well as several offline > conversations with interested parties, I've put together a proposed > change to JSEP that, if accepted, will allow publication of the Cluster > 238 documents to move forward. > > Note that this new text has no impact on existing implementations (at > least, as far as I am able to discern), which do not currently have the > capability of producing media sections consisting of exclusively TCP > candidates. From that perspective, the change makes existing > implementations no less compliant with JSEP than they were before. > > What this change does provide is both on-paper and in-the-future > compatibility between WebRTC implementations once they finalize TCP > candidate handling (and candidate handling in general for mid-session > offers). > > https://github.com/rtcweb-wg/jsep/pull/862/files > > The key insight here is that JSEP's use of ICE completely discards any > meaning associated with the transport parameter, while SIP's use of ICE > does not. The trivial change that I propose, which bears only on future > WebRTC implementations -- that is, which has no as-built specification > to point to -- allows JSEP to continue to ignore the value of the > transport parameter, while specifying that it says the right thing for > SIP implementations to function properly. > > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000b9e7f705808c83be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Posted=C2=A0https://github.com/rtcweb-wg/jsep/pull/863 as= a stab at a consensus. This basically says that the offerer fills in eithe= r UDP/TLS/foo or TCP/DTLS/foo based on the current default or selected cand= idate, in accordance with sip-sdp. As Adam mentioned before, this shouldn&#= 39;t have any impact on JSEP functionality.

If this looks good, I'll polish it up.
On Sun, J= an 27, 2019 at 3:22 AM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
=

Hi,

=C2=A0

> I'm not yet persuaded this is needed. The alleged need here i= s that there are some ICE-implementing endpoints which will choke if=C2=A0<= br> > they see a profile that doesn't match any actual candidate. I reco= gnize that this is required by 5245, but that doesn't mean anyone=C2=A0=
> ever did it. Can you please point me to a client which would interoper= ate with a WebRTC endpoint with this change that would not=C2=A0
> if you just always sent the same profile as JSEP currently requir= es.

I don't think it is ok to *specify* that discarding a MUST is ok a= s long as nobody can show an implementation that would break by doing so.

Having said that, in order to prevent an RTCWEB shutdown I am generall= y ok with Adam's approach. I would like my pull request comments to be = addressed, though, that is related to separation between the JSEP API and a= n application using it: an application should be allowed to act according to 5245/draft-ice-sdp and update the c/= m line if it wishes to, but due to the way the JSEP API works such applicat= ions might sometimes always include the same value in the c/m- line.=C2=A0<= /div>

I also think it shall be explicitly written that JSEP does not update = 5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line.

Regards,

Christer




On Thu, = Jan 24, 2019 at 11:12 AM Adam Roach <adam@nostrum.com> wrote:
Based on conversations in MMUSIC, as well as several offline
conversations with interested parties, I've put together a proposed change to JSEP that, if accepted, will allow publication of the Cluster 238 documents to move forward.

Note that this new text has no impact on existing implementations (at
least, as far as I am able to discern), which do not currently have the capability of producing media sections consisting of exclusively TCP
candidates. From that perspective, the change makes existing
implementations no less compliant with JSEP than they were before.

What this change does provide is both on-paper and in-the-future
compatibility between WebRTC implementations once they finalize TCP
candidate handling (and candidate handling in general for mid-session
offers).

=C2=A0=C2=A0 https://github.com/rtcweb-wg/jsep/pull/862/files

The key insight here is that JSEP's use of ICE completely discards any =
meaning associated with the transport parameter, while SIP's use of ICE=
does not. The trivial change that I propose, which bears only on future WebRTC implementations -- that is, which has no as-built specification
to point to -- allows JSEP to continue to ignore the value of the
transport parameter, while specifying that it says the right thing for
SIP implementations to function properly.

/a

_______________________________________________
rtcweb mailing list
rt= cweb@ietf.org
https://www.ietf.org/mailman/listinf= o/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000b9e7f705808c83be-- From nobody Mon Jan 28 14:57:50 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8801310DE for ; Mon, 28 Jan 2019 14:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EY0FTHpIgRiK for ; Mon, 28 Jan 2019 14:57:45 -0800 (PST) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D09B130EE4 for ; Mon, 28 Jan 2019 14:57:45 -0800 (PST) Received: by mail-pf1-x42f.google.com with SMTP id w73so8678625pfk.10 for ; Mon, 28 Jan 2019 14:57:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v68WX6YYKkurlc1Byeu8+l9VdETV2tWvdzrNi51OGRI=; b=zsLlc6ua4SyWFQr5902+WiGPEILRMAaqGj7KbdN1qe1nYkTTK/YZFp2qen9LgauUYi FmfTwqX+MCEfDCNbRPmgxVQ6cLRFrlmXXmH+LXn+NBGpeCr6M8ESBxEcBZMwMGpRLQH1 +i90Cxu00EwXH/opzDk8axI4GKcp1q8adH4hCYYeS7Wys7XQYJoK6OJsZMjGJ211VSgl fFPHN6bVGlrJ79L7R+hF6bz+o6hFWUa+/qmrf8w/f5wmB6YcTBuQygjv8W8lSiY1rAsM PZ9X0dfrMFL7bHk6ADtlnDhrrp/uh3aZ7/UL5RN3fkrwbBPFjk26wavBGXy9yLKeuSCR 8hAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v68WX6YYKkurlc1Byeu8+l9VdETV2tWvdzrNi51OGRI=; b=SsicaXNKCTdcXrmLm+nRSWgNhPb1+ubFKJxwYTYN9y0ZUhw4tEisUapO/Q0HQ21nUc k0Ng6pa/MmwKrEzofEiTh3uqoBvcdcuxP6zbxxEeN8Z+QA/fr6VO9N9s3N8mfHKlsaOt 1Fn7G2Sf7ggBtV8nuaBvEAyg8SOrXJgZ0wTxgNdhyve6dHnRa0im+1DHNRnMf3ziPbg7 APonlTwDCcTUk2YNAwnp41wB5S/39D3qReIl/ftySLXMGufk7Z3+dNwxU4An0aCBQ+x0 THHhcKhC5WORKr8GO6/3PRro8f81R4bucT+9HLXsBwHilXJzDMLr/jcLL89rTViElKF0 9DPA== X-Gm-Message-State: AJcUukeNyP0TgYCk/z2bRaHtahuuyqPOO3/TOxyq864nh+3DKClQhW4Q pPrSPKcidcys/o2j08jbGFVxB+3kJtU= X-Google-Smtp-Source: ALg8bN6DLz+/ZBK6Lxh5iMtJqA4CE4UPSskvj+/NiPGZtioC6kH/bWk5eUaPCAXdZVzoqOAHx6q7SA== X-Received: by 2002:a63:4e15:: with SMTP id c21mr21564315pgb.50.1548716264458; Mon, 28 Jan 2019 14:57:44 -0800 (PST) Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com. [209.85.214.172]) by smtp.gmail.com with ESMTPSA id u186sm55090147pfu.51.2019.01.28.14.57.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Jan 2019 14:57:43 -0800 (PST) Received: by mail-pl1-f172.google.com with SMTP id u18so8418936plq.7 for ; Mon, 28 Jan 2019 14:57:43 -0800 (PST) X-Received: by 2002:a17:902:981:: with SMTP id 1mr23006182pln.142.1548716263453; Mon, 28 Jan 2019 14:57:43 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> In-Reply-To: From: Roman Shpount Date: Mon, 28 Jan 2019 17:57:32 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: Christer Holmberg , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bdbae205808c9a1e" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Mon, 28 Jan 2019 22:57:49 -0000 --000000000000bdbae205808c9a1e Content-Type: text/plain; charset="UTF-8" This looks good to me. _____________ Roman Shpount On Mon, Jan 28, 2019 at 5:51 PM Justin Uberti wrote: > Posted https://github.com/rtcweb-wg/jsep/pull/863 as a stab at a > consensus. This basically says that the offerer fills in either UDP/TLS/foo > or TCP/DTLS/foo based on the current default or selected candidate, in > accordance with sip-sdp. As Adam mentioned before, this shouldn't have any > impact on JSEP functionality. > > If this looks good, I'll polish it up. > > On Sun, Jan 27, 2019 at 3:22 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> > I'm not yet persuaded this is needed. The alleged need here is that >> there are some ICE-implementing endpoints which will choke if >> > they see a profile that doesn't match any actual candidate. I recognize >> that this is required by 5245, but that doesn't mean anyone >> > ever did it. Can you please point me to a client which would >> interoperate with a WebRTC endpoint with this change that would not >> > if you just always sent the same profile as JSEP currently requires. >> >> I don't think it is ok to *specify* that discarding a MUST is ok as long >> as nobody can show an implementation that would break by doing so. >> >> Having said that, in order to prevent an RTCWEB shutdown I am generally >> ok with Adam's approach. I would like my pull request comments to be >> addressed, though, that is related to separation between the JSEP API and >> an application using it: an application should be allowed to act according >> to 5245/draft-ice-sdp and update the c/m line if it wishes to, but due to >> the way the JSEP API works such applications might sometimes always include >> the same value in the c/m- line. >> >> I also think it shall be explicitly written that JSEP does not update >> 5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line. >> >> Regards, >> >> Christer >> >> >> >> >> On Thu, Jan 24, 2019 at 11:12 AM Adam Roach wrote: >> >> Based on conversations in MMUSIC, as well as several offline >> conversations with interested parties, I've put together a proposed >> change to JSEP that, if accepted, will allow publication of the Cluster >> 238 documents to move forward. >> >> Note that this new text has no impact on existing implementations (at >> least, as far as I am able to discern), which do not currently have the >> capability of producing media sections consisting of exclusively TCP >> candidates. From that perspective, the change makes existing >> implementations no less compliant with JSEP than they were before. >> >> What this change does provide is both on-paper and in-the-future >> compatibility between WebRTC implementations once they finalize TCP >> candidate handling (and candidate handling in general for mid-session >> offers). >> >> https://github.com/rtcweb-wg/jsep/pull/862/files >> >> The key insight here is that JSEP's use of ICE completely discards any >> meaning associated with the transport parameter, while SIP's use of ICE >> does not. The trivial change that I propose, which bears only on future >> WebRTC implementations -- that is, which has no as-built specification >> to point to -- allows JSEP to continue to ignore the value of the >> transport parameter, while specifying that it says the right thing for >> SIP implementations to function properly. >> >> /a >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000bdbae205808c9a1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This looks good to me.
__________= ___
Roman Shpount


On Mon, Jan 28, 2019 at 5:51 PM Justin = Uberti <juberti=3D40googl= e.com@dmarc.ietf.org> wrote:
Posted=C2=A0https://g= ithub.com/rtcweb-wg/jsep/pull/863 as a stab at a consensus. This basica= lly says that the offerer fills in either UDP/TLS/foo or TCP/DTLS/foo based= on the current default or selected candidate, in accordance with sip-sdp. = As Adam mentioned before, this shouldn't have any impact on JSEP functi= onality.

If this looks goo= d, I'll polish it up.

On Sun, Jan 27, 2= 019 at 3:22 AM Christer Holmberg <christer.holmberg@ericsson.com> wrote:=

Hi,

=C2=A0

> I'm not yet persuaded this is needed. The alleged need here i= s that there are some ICE-implementing endpoints which will choke if=C2=A0<= br> > they see a profile that doesn't match any actual candidate. I reco= gnize that this is required by 5245, but that doesn't mean anyone=C2=A0=
> ever did it. Can you please point me to a client which would interoper= ate with a WebRTC endpoint with this change that would not=C2=A0
> if you just always sent the same profile as JSEP currently requir= es.

I don't think it is ok to *specify* that discarding a MUST is ok a= s long as nobody can show an implementation that would break by doing so.

Having said that, in order to prevent an RTCWEB shutdown I am generall= y ok with Adam's approach. I would like my pull request comments to be = addressed, though, that is related to separation between the JSEP API and a= n application using it: an application should be allowed to act according to 5245/draft-ice-sdp and update the c/= m line if it wishes to, but due to the way the JSEP API works such applicat= ions might sometimes always include the same value in the c/m- line.=C2=A0<= /div>

I also think it shall be explicitly written that JSEP does not update = 5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line.

Regards,

Christer




On Thu, Jan 24, 2019 at 11:12 AM Adam Roach <adam@nostrum.com> wro= te:
Based on conversations in MMUSIC, as well as several offline
conversations with interested parties, I've put together a proposed change to JSEP that, if accepted, will allow publication of the Cluster 238 documents to move forward.

Note that this new text has no impact on existing implementations (at
least, as far as I am able to discern), which do not currently have the capability of producing media sections consisting of exclusively TCP
candidates. From that perspective, the change makes existing
implementations no less compliant with JSEP than they were before.

What this change does provide is both on-paper and in-the-future
compatibility between WebRTC implementations once they finalize TCP
candidate handling (and candidate handling in general for mid-session
offers).

=C2=A0=C2=A0 https://github.com/rtcweb-wg/jsep/pull/862/files

The key insight here is that JSEP's use of ICE completely discards any =
meaning associated with the transport parameter, while SIP's use of ICE=
does not. The trivial change that I propose, which bears only on future WebRTC implementations -- that is, which has no as-built specification
to point to -- allows JSEP to continue to ignore the value of the
transport parameter, while specifying that it says the right thing for
SIP implementations to function properly.

/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000bdbae205808c9a1e-- From nobody Mon Jan 28 16:36:12 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F8A126C7E for ; Mon, 28 Jan 2019 16:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNZClCskA6ot for ; Mon, 28 Jan 2019 16:36:06 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D206124BF6 for ; Mon, 28 Jan 2019 16:36:06 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id c19-v6so15938221lja.5 for ; Mon, 28 Jan 2019 16:36:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HadwHJuHQPaPDxfeRuL7uscRWjd8jVqWEwxE1+nG4GE=; b=y2dbUggnn7/2MKZyktwqLubTeoG2nkyLIFnn8pc685v9AAZqn+eTFfIORNPJEhemcw oqJqrhO7G+WH8tfHlSwTM2UH2yjxZGxdMgxbl2XhJJuXiZ9oKLCvZUuIIUgRiQxUrCmN PBzS3FaFcXJBZBtzHSlNa4x2BysDXLjZTzxVFWjnopnc6Pe92QN8fMnBjGBZ7s8AmxXe SisEbhlUzB/oMjio7HSV+QUyUOqqI4ZhyI1XBSconu+dgWz3UgGxTpn+Ecf0TMSDWe5a m7siq/RtAGIsA+Qu9b3KldoYnx9E4YqogC659dBjRPYbfpRCwfhsjSlfcVsoTwzChETn cqVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HadwHJuHQPaPDxfeRuL7uscRWjd8jVqWEwxE1+nG4GE=; b=ptElfVhcTAfsemsFsSrSUM4qy4BBUCk+pfqRz8XxgPW3Z4EclnvYYB6cM7ukLXPfc3 aPX6s2gu3ddMF1vVDtFVd/OpfnZIGNwXw0J0NudGJqjsQZPuR4i9yC/sw22NwOmYiPan kYqGe8hlS0MBZfUcsT9nhXeCXnV3IUJJRMAglJvK+GqT3kYHGQCuP2tpuG5W0c9pbTVG Nz8mLsR/mkYJ3/E+S5UCdy3/Zs7i7VEeIMjtfgbpnJ8o+WwPZm1kImFlCy8mJXsv8Ieb nD0bIGAVQo0vopLupqkef21kbgycey9Fcmu64+BuzehwB8nzzA79YACItpqZzy1F+nO4 e7uA== X-Gm-Message-State: AJcUukenzaQJ+rYXszCuSLhiifynjLj1zj/ERFnyvGPvUTxV28MXqbbA sEb4lGngQN2+8h+i/khMErmnnJF6bqvpOyLhoNGneA== X-Google-Smtp-Source: ALg8bN6QH63PHpLUlEWFD7tWNmHyT6/XAoNFWUWiW1jcPNnGQeMGj+yq20JM1PX5xH2mrPlSjxxOZa7QXgvbn1dRloQ= X-Received: by 2002:a2e:e02:: with SMTP id 2-v6mr18882629ljo.10.1548722164463; Mon, 28 Jan 2019 16:36:04 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> In-Reply-To: From: Eric Rescorla Date: Mon, 28 Jan 2019 16:35:26 -0800 Message-ID: To: Justin Uberti Cc: Christer Holmberg , Adam Roach , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000781a2c05808dfad4" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 00:36:10 -0000 --000000000000781a2c05808dfad4 Content-Type: text/plain; charset="UTF-8" If we assume that this is a real problem as opposed to a specification problem, then I agree this is reasonable. However, so far nobody has shown me that this is a real problem, and until that this happens, I'm not in favor. On Mon, Jan 28, 2019 at 2:51 PM Justin Uberti wrote: > Posted https://github.com/rtcweb-wg/jsep/pull/863 as a stab at a > consensus. This basically says that the offerer fills in either UDP/TLS/foo > or TCP/DTLS/foo based on the current default or selected candidate, in > accordance with sip-sdp. As Adam mentioned before, this shouldn't have any > impact on JSEP functionality. > > If this looks good, I'll polish it up. > > On Sun, Jan 27, 2019 at 3:22 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> > I'm not yet persuaded this is needed. The alleged need here is that >> there are some ICE-implementing endpoints which will choke if >> > they see a profile that doesn't match any actual candidate. I recognize >> that this is required by 5245, but that doesn't mean anyone >> > ever did it. Can you please point me to a client which would >> interoperate with a WebRTC endpoint with this change that would not >> > if you just always sent the same profile as JSEP currently requires. >> >> I don't think it is ok to *specify* that discarding a MUST is ok as long >> as nobody can show an implementation that would break by doing so. >> >> Having said that, in order to prevent an RTCWEB shutdown I am generally >> ok with Adam's approach. I would like my pull request comments to be >> addressed, though, that is related to separation between the JSEP API and >> an application using it: an application should be allowed to act according >> to 5245/draft-ice-sdp and update the c/m line if it wishes to, but due to >> the way the JSEP API works such applications might sometimes always include >> the same value in the c/m- line. >> >> I also think it shall be explicitly written that JSEP does not update >> 5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line. >> >> Regards, >> >> Christer >> >> >> >> >> On Thu, Jan 24, 2019 at 11:12 AM Adam Roach wrote: >> >> Based on conversations in MMUSIC, as well as several offline >> conversations with interested parties, I've put together a proposed >> change to JSEP that, if accepted, will allow publication of the Cluster >> 238 documents to move forward. >> >> Note that this new text has no impact on existing implementations (at >> least, as far as I am able to discern), which do not currently have the >> capability of producing media sections consisting of exclusively TCP >> candidates. From that perspective, the change makes existing >> implementations no less compliant with JSEP than they were before. >> >> What this change does provide is both on-paper and in-the-future >> compatibility between WebRTC implementations once they finalize TCP >> candidate handling (and candidate handling in general for mid-session >> offers). >> >> https://github.com/rtcweb-wg/jsep/pull/862/files >> >> The key insight here is that JSEP's use of ICE completely discards any >> meaning associated with the transport parameter, while SIP's use of ICE >> does not. The trivial change that I propose, which bears only on future >> WebRTC implementations -- that is, which has no as-built specification >> to point to -- allows JSEP to continue to ignore the value of the >> transport parameter, while specifying that it says the right thing for >> SIP implementations to function properly. >> >> /a >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > --000000000000781a2c05808dfad4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If we assume that this is a real problem as opposed to a s= pecification problem, then I agree this is reasonable. However, so far nobo= dy has shown me that this is a real problem, and until that this happens, I= 'm not in favor.

On Mon, Jan 28, 2019 at 2:51 PM Justin Uberti <<= a href=3D"mailto:juberti@google.com">juberti@google.com> wrote:
<= /div>
Posted=C2=A0https://github.com/rtcweb-wg/jsep/pull/863 as a= stab at a consensus. This basically says that the offerer fills in either = UDP/TLS/foo or TCP/DTLS/foo based on the current default or selected candid= ate, in accordance with sip-sdp. As Adam mentioned before, this shouldn'= ;t have any impact on JSEP functionality.

<= div dir=3D"ltr">If this looks good, I'll polish it up.

<= div class=3D"gmail_quote">
On Sun, Jan 27, 2019 at 3:22 AM Christer Holmberg <christer.ho= lmberg@ericsson.com> wrote:

Hi,

=C2=A0

> I'm not yet persuaded this is needed. The alleged need here i= s that there are some ICE-implementing endpoints which will choke if=C2=A0<= br> > they see a profile that doesn't match any actual candidate. I reco= gnize that this is required by 5245, but that doesn't mean anyone=C2=A0=
> ever did it. Can you please point me to a client which would interoper= ate with a WebRTC endpoint with this change that would not=C2=A0
> if you just always sent the same profile as JSEP currently requir= es.

I don't think it is ok to *specify* that discarding a MUST is ok a= s long as nobody can show an implementation that would break by doing so.

Having said that, in order to prevent an RTCWEB shutdown I am generall= y ok with Adam's approach. I would like my pull request comments to be = addressed, though, that is related to separation between the JSEP API and a= n application using it: an application should be allowed to act according to 5245/draft-ice-sdp and update the c/= m line if it wishes to, but due to the way the JSEP API works such applicat= ions might sometimes always include the same value in the c/m- line.=C2=A0<= /div>

I also think it shall be explicitly written that JSEP does not update = 5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line.

Regards,

Christer




On Thu, Jan 24, 2019 at 11:12 AM Adam Roach <adam@nostrum.com> wr= ote:
Based on conversations in MMUSIC, as well as several offline
conversations with interested parties, I've put together a proposed change to JSEP that, if accepted, will allow publication of the Cluster 238 documents to move forward.

Note that this new text has no impact on existing implementations (at
least, as far as I am able to discern), which do not currently have the capability of producing media sections consisting of exclusively TCP
candidates. From that perspective, the change makes existing
implementations no less compliant with JSEP than they were before.

What this change does provide is both on-paper and in-the-future
compatibility between WebRTC implementations once they finalize TCP
candidate handling (and candidate handling in general for mid-session
offers).

=C2=A0=C2=A0 https://github.com/rtcweb-wg/jsep/pull/862/files

The key insight here is that JSEP's use of ICE completely discards any =
meaning associated with the transport parameter, while SIP's use of ICE=
does not. The trivial change that I propose, which bears only on future WebRTC implementations -- that is, which has no as-built specification
to point to -- allows JSEP to continue to ignore the value of the
transport parameter, while specifying that it says the right thing for
SIP implementations to function properly.

/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000781a2c05808dfad4-- From nobody Mon Jan 28 16:47:05 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CE4124BF6 for ; Mon, 28 Jan 2019 16:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jevqSHO_2fvM for ; Mon, 28 Jan 2019 16:47:00 -0800 (PST) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6A1126C7E for ; Mon, 28 Jan 2019 16:47:00 -0800 (PST) Received: by mail-ot1-x335.google.com with SMTP id i20so16457110otl.0 for ; Mon, 28 Jan 2019 16:47:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+B1o545uI40ttKIvuOaxciuFn38AC+3RRER3KRySOwI=; b=L+1z6SDqOm02v08lv6FGCwB75/XrJbG42ezG5JhbzYRYPaqpJJgxvHiWREoRlF2ArE nc5/yXq876YzlJuOh1ATpxZMXrjGjXqi8Fi6D25QdAQvGSQmlue/GHzRCWUUnFz0H0NX g8zd2S9y9zZiI0/ZJsNJJPHp6i8RVS2rE06cztserJfKJvPWoPONZpg3WuZRNQdBQBcS 1kk3rXqsgeaQKRx2X+51S/Bt5Q+1IyEEjAV697npiFMNm4wKzLVjUVSJ0dI9JqLYdhm2 Kk5F96R7c/lz91fk6err3oZgj5yCK6+vYqZ/itYE2EFQGL6pdhtEPuXMrZGBYEZsR8/4 /wuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+B1o545uI40ttKIvuOaxciuFn38AC+3RRER3KRySOwI=; b=fjOMzoUvySLGkSd2uWwYCUQZ6ozSvsLaMq5grWlAV0X2kniq3SQHk8P8/326N92gnX nSuL2pi1ny5DhFKEVemA9csesRFnqaidG/nAeMoooZldROk310w4+LwHhpt08eAcX4/h ozeDvLuJpBU2/N2nORm3cM2+Ya+YgpXnJg3QyzD6eCP4W/9nhxcLvyF7XKIRrx9tFTPb TyLZchPg3tyn1SNrjHHczdmpS7cDpEhl6V+2qMH8mHWNUyip9uAmMtBCzV5hs4wZgW9i z+9ire7LFJHqqOXyTKtPd/IL62VeQCmQ3cQa0yM7COvKXK1oXYdq+Zwr19lmt38iCh/I ib9g== X-Gm-Message-State: AJcUukdfdp31lvSIjrVvd9EcH1b3Zx/dDpOOlYGpsMshBnAAr310UPH+ dhOVPpC860jB02xkepbBNw7RrhITGhKF74rh32s= X-Google-Smtp-Source: ALg8bN4uqtnDRn96LJqjhtQ9QtrYqcYPr7+AWrgcblWuBrY8a+hjhv90/wDGWLC6bs5hx70yMNipmORbiXpTC9oHNT0= X-Received: by 2002:a9d:738a:: with SMTP id j10mr18387922otk.188.1548722819524; Mon, 28 Jan 2019 16:46:59 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> In-Reply-To: From: Ted Hardie Date: Tue, 29 Jan 2019 09:46:33 +0900 Message-ID: To: Eric Rescorla Cc: Justin Uberti , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000836e4805808e21fa" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 00:47:04 -0000 --000000000000836e4805808e21fa Content-Type: text/plain; charset="UTF-8" On Tue, Jan 29, 2019 at 9:36 AM Eric Rescorla wrote: > If we assume that this is a real problem as opposed to a specification > problem, then I agree this is reasonable. However, so far nobody has shown > me that this is a real problem, and until that this happens, I'm not in > favor. > > As a chair, I wish to confirm my understanding: you have no technical objection to this solution, but you do not wish to include this because you have seen no evidence of the problem. Is that correct? Yours is, at the moment, the only objection I have seen. Before going to a call for a consensus, I want to make sure that the nature of any objection is as clear as possible. thanks, Ted > On Mon, Jan 28, 2019 at 2:51 PM Justin Uberti wrote: > >> Posted https://github.com/rtcweb-wg/jsep/pull/863 as a stab at a >> consensus. This basically says that the offerer fills in either UDP/TLS/foo >> or TCP/DTLS/foo based on the current default or selected candidate, in >> accordance with sip-sdp. As Adam mentioned before, this shouldn't have any >> impact on JSEP functionality. >> >> If this looks good, I'll polish it up. >> >> On Sun, Jan 27, 2019 at 3:22 AM Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> Hi, >>> >>> >>> > I'm not yet persuaded this is needed. The alleged need here is that >>> there are some ICE-implementing endpoints which will choke if >>> > they see a profile that doesn't match any actual candidate. I >>> recognize that this is required by 5245, but that doesn't mean anyone >>> > ever did it. Can you please point me to a client which would >>> interoperate with a WebRTC endpoint with this change that would not >>> > if you just always sent the same profile as JSEP currently requires. >>> >>> I don't think it is ok to *specify* that discarding a MUST is ok as long >>> as nobody can show an implementation that would break by doing so. >>> >>> Having said that, in order to prevent an RTCWEB shutdown I am generally >>> ok with Adam's approach. I would like my pull request comments to be >>> addressed, though, that is related to separation between the JSEP API and >>> an application using it: an application should be allowed to act according >>> to 5245/draft-ice-sdp and update the c/m line if it wishes to, but due to >>> the way the JSEP API works such applications might sometimes always include >>> the same value in the c/m- line. >>> >>> I also think it shall be explicitly written that JSEP does not update >>> 5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> On Thu, Jan 24, 2019 at 11:12 AM Adam Roach wrote: >>> >>> Based on conversations in MMUSIC, as well as several offline >>> conversations with interested parties, I've put together a proposed >>> change to JSEP that, if accepted, will allow publication of the Cluster >>> 238 documents to move forward. >>> >>> Note that this new text has no impact on existing implementations (at >>> least, as far as I am able to discern), which do not currently have the >>> capability of producing media sections consisting of exclusively TCP >>> candidates. From that perspective, the change makes existing >>> implementations no less compliant with JSEP than they were before. >>> >>> What this change does provide is both on-paper and in-the-future >>> compatibility between WebRTC implementations once they finalize TCP >>> candidate handling (and candidate handling in general for mid-session >>> offers). >>> >>> https://github.com/rtcweb-wg/jsep/pull/862/files >>> >>> The key insight here is that JSEP's use of ICE completely discards any >>> meaning associated with the transport parameter, while SIP's use of ICE >>> does not. The trivial change that I propose, which bears only on future >>> WebRTC implementations -- that is, which has no as-built specification >>> to point to -- allows JSEP to continue to ignore the value of the >>> transport parameter, while specifying that it says the right thing for >>> SIP implementations to function properly. >>> >>> /a >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000836e4805808e21fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 29, 2019 at 9:36 AM Eric Resc= orla <ekr@rtfm.com= > wrote:
If we assume that this is a real pr= oblem as opposed to a specification problem, then I agree this is reasonabl= e. However, so far nobody has shown me that this is a real problem, and unt= il that this happens, I'm not in favor.

=
As a chair, I wish to confirm my understanding:=C2=A0 you ha= ve no technical objection to this solution, but you do not wish to include = this because you have seen no evidence of the problem.=C2=A0 Is that correc= t?=C2=A0

Yours is, at the moment, the only ob= jection I have seen.=C2=A0 Before going to a call for a consensus, I want t= o make sure that the nature of any objection is as clear as possible.
=

thanks,

Ted

=

=C2=A0
On Mon, Jan 28, 2019 at= 2:51 PM Justin Uberti <juberti@google.com> wrote:
Posted=C2=A0https= ://github.com/rtcweb-wg/jsep/pull/863 as a stab at a consensus. This ba= sically says that the offerer fills in either UDP/TLS/foo or TCP/DTLS/foo b= ased on the current default or selected candidate, in accordance with sip-s= dp. As Adam mentioned before, this shouldn't have any impact on JSEP fu= nctionality.

If this looks= good, I'll polish it up.

On Sun, Jan 27, 2019 at 3:22 AM Christ= er Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

> I'm not yet persuaded this is needed. The alleged need here i= s that there are some ICE-implementing endpoints which will choke if=C2=A0<= br> > they see a profile that doesn't match any actual candidate. I reco= gnize that this is required by 5245, but that doesn't mean anyone=C2=A0=
> ever did it. Can you please point me to a client which would interoper= ate with a WebRTC endpoint with this change that would not=C2=A0
> if you just always sent the same profile as JSEP currently requir= es.

I don't think it is ok to *specify* that discarding a MUST is ok a= s long as nobody can show an implementation that would break by doing so.

Having said that, in order to prevent an RTCWEB shutdown I am generall= y ok with Adam's approach. I would like my pull request comments to be = addressed, though, that is related to separation between the JSEP API and a= n application using it: an application should be allowed to act according to 5245/draft-ice-sdp and update the c/= m line if it wishes to, but due to the way the JSEP API works such applicat= ions might sometimes always include the same value in the c/m- line.=C2=A0<= /div>

I also think it shall be explicitly written that JSEP does not update = 5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line.

Regards,

Christer




On Thu= , Jan 24, 2019 at 11:12 AM Adam Roach <adam@nostrum.com> wro= te:
Based on conversations in MMUSIC, as well as several offline
conversations with interested parties, I've put together a proposed change to JSEP that, if accepted, will allow publication of the Cluster 238 documents to move forward.

Note that this new text has no impact on existing implementations (at
least, as far as I am able to discern), which do not currently have the capability of producing media sections consisting of exclusively TCP
candidates. From that perspective, the change makes existing
implementations no less compliant with JSEP than they were before.

What this change does provide is both on-paper and in-the-future
compatibility between WebRTC implementations once they finalize TCP
candidate handling (and candidate handling in general for mid-session
offers).

=C2=A0=C2=A0 https://github.com/rtcweb-wg/jsep/pull/862/files

The key insight here is that JSEP's use of ICE completely discards any =
meaning associated with the transport parameter, while SIP's use of ICE=
does not. The trivial change that I propose, which bears only on future WebRTC implementations -- that is, which has no as-built specification
to point to -- allows JSEP to continue to ignore the value of the
transport parameter, while specifying that it says the right thing for
SIP implementations to function properly.

/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/lis= tinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000836e4805808e21fa-- From nobody Mon Jan 28 16:50:41 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D64F126C7E for ; Mon, 28 Jan 2019 16:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7eVE43HzJO2 for ; Mon, 28 Jan 2019 16:50:38 -0800 (PST) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C27124BF6 for ; Mon, 28 Jan 2019 16:50:38 -0800 (PST) Received: by mail-pg1-x536.google.com with SMTP id j10so7993566pga.1 for ; Mon, 28 Jan 2019 16:50:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=juXFNcJomI3dJVu40qzfrhzDD1lD6sSh3gPxD3jOwhY=; b=njrCbWD248pGudr56ZW+Zj7Cdlok4P4kvHyNQY6e0UDF4bIiGNK6h7elZz41mtl/hG joDJaxiMSvevHESCGnIvru/M4tu15WSD8Hnoiyw7qeyNTot1nSdKDYDUmWcIvg9CD8ur +gPP+qts+POakD02ziEPlUur1quDliDdX+q6u2yS5HPfrBcOFktIc2x/0o+IU4TUhe+H RFyKgCAC0snGL/L+Z6I6JDqWxc1lCtB9Poc4NxmL3jpKLrVplwMkclevdeKJUGxy0TsL YCdrpC5WTq4BZ1qf+ApcoLXajmaKj/yA6B7+dmStuBCJ3gfuU5yViXHEGw1SNpjMSx/z +J/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=juXFNcJomI3dJVu40qzfrhzDD1lD6sSh3gPxD3jOwhY=; b=kEekBjbgZsxaK4+pdzjOVStWwrxTkbVDPirY67XjJa53bVmUf6Z90x50Eg7S3BRuSw xxiHGE76c39ylWHwQZkZvsN9vjAk3lAUHKlu/FO2zhahsAyP2RdiEGWmpu2kgPRmGaAf NuGcFPg7DWzelmU+5ZIkZ+40eeUJfTv1260GNsEnCKMvoDOFxChHSvHdoerspzv38IPp xLVQwfL6h3ti7ZIEVfOsfIOb3a+ptf0XQ2wTXQUwQtehcEYoiRjx3c1D1wxGCmJ95+oy LuyVfGl4GcNRvYfGhBEMBGeu4KuMD7cIogom1e4kD0Gxb1ZFhUnqB6+gv01Sz1Lahcu3 pDuw== X-Gm-Message-State: AJcUukdXb/YJyu01A9QBMrJWEjsLerxigY3gjlH/+/Q0n7+ftMtSI7Au f5IUFn5t1+Zp4BSgIfIqjV/MjovM2Ik= X-Google-Smtp-Source: ALg8bN6H75PDtkQWJSYehHmLmot0rg+6q8hNUsH/7QH3lFb4RDmHIFAqLwIZXSsTpRwBF6/myO/Pag== X-Received: by 2002:a63:6d48:: with SMTP id i69mr20965066pgc.215.1548723037755; Mon, 28 Jan 2019 16:50:37 -0800 (PST) Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com. [209.85.210.177]) by smtp.gmail.com with ESMTPSA id w10sm42263085pgi.81.2019.01.28.16.50.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Jan 2019 16:50:37 -0800 (PST) Received: by mail-pf1-f177.google.com with SMTP id c123so8845613pfb.0 for ; Mon, 28 Jan 2019 16:50:36 -0800 (PST) X-Received: by 2002:a63:2e88:: with SMTP id u130mr22244780pgu.9.1548723036719; Mon, 28 Jan 2019 16:50:36 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> In-Reply-To: From: Roman Shpount Date: Mon, 28 Jan 2019 19:50:25 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Cc: Justin Uberti , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="00000000000075924205808e2ecb" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 00:50:40 -0000 --00000000000075924205808e2ecb Content-Type: text/plain; charset="UTF-8" On Mon, Jan 28, 2019 at 7:36 PM Eric Rescorla wrote: > If we assume that this is a real problem as opposed to a specification > problem, then I agree this is reasonable. However, so far nobody has shown > me that this is a real problem, and until that this happens, I'm not in > favor. > > What would you consider a real problem? Would the fact that SDP manipulation in WebRTC JavaScript client or on the server to work with WebRTC be considered a real problem or a minor inconvenience? Regards, _____________ Roman Shpount --00000000000075924205808e2ecb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jan 28, 2019 at 7:36 PM E= ric Rescorla <ekr@rtfm.com> wrote= :
If we assume that this is a real = problem as opposed to a specification problem, then I agree this is reasona= ble. However, so far nobody has shown me that this is a real problem, and u= ntil that this happens, I'm not in favor.

What would you consider a real problem?

Would th= e fact that SDP manipulation in WebRTC JavaScript client or on the server t= o work with WebRTC be considered a real problem or a minor inconvenience?

Regards,
_____________
Roman Shpount
=C2=A0
--00000000000075924205808e2ecb-- From nobody Mon Jan 28 16:56:37 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084A112875B for ; Mon, 28 Jan 2019 16:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-oNnWTE4iJB for ; Mon, 28 Jan 2019 16:56:33 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7725126DBF for ; Mon, 28 Jan 2019 16:56:32 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id k15-v6so15948319ljc.8 for ; Mon, 28 Jan 2019 16:56:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gPaxs4KVw8UPGu9BJRh5sjpOTQIPwXnIFEtO0+vD1tY=; b=e9X0CQvTIAKJacvD2NR6oH+FcsA8dJEqBFjIaP4dxW44OmqSTgY956Za6ibXvoOiMv Wr0guzSVBOlNRW9t8+gtHlKSU3Gdsz8tCzcaOpB39kn057mKIQHJRnUfDrdX08TNijrv Hxch/4N5+iBs/3baK72HNX3eCsUZxjfV6pFXuroYFhAcBfflHV3E0XffR4n+rAV4nufg x8WBJsuMBGvZrIAhZltiphYlLZGha/r7GKaqGPXiSNnq9QqImnvGSqcWh0CAy0KK0sFO X9zLVNGvJ2hE/N7QOkSioBBunWs2kYGv1H2jLNvrvdb1zuvyKI3oSQQvYtzjg/0MxZPa XshQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gPaxs4KVw8UPGu9BJRh5sjpOTQIPwXnIFEtO0+vD1tY=; b=Aujitl905zffzAOEOFLkz4FpLIecpeDYg/5mH0Ph2tkn19rc2K9S7E+kS7OlSmWWUA f3l1/a7QHhgKyEq6zuJy+wU5tYF8Tyn1RTdnvic5MFlPPlDkuxkVR4ISM/OLj9U/2jw4 yzs6o8jIj4XsmbNfm/jqynDlzjTcTtyMNpETK6XOdZaXG9ITyl7AyPIyTjbG+DmOmJzi sh/tDgEHfwmRUfwWrYS4EXv1xHV4ElwRdy4X4zcw+s8YkfX8nEoPQT2gM1uLXeVQNZNQ d6CpgBJ96jrn3OB6GA+zNUBSqStkOxTaCtxl8dY3H2zm80UoVV3rJWu4V/+HhxUZVkLX Dllg== X-Gm-Message-State: AJcUukeiJrZBbESZYjws2AAtid2Fv34m0YS0WU98uNcxxyJi4W3fgu3Q zuIofvkPOINhDv0tLQxCuCmIBqu+TCzm8uZ6Aod2nw== X-Google-Smtp-Source: ALg8bN4nwqzqsiZKqFaWrdES5p3pBq+5cKeDU9pLQS/dQV4H5ruPubal5H+mHUEYhFKt/pkZ94vs/AYuirwAAnrlFPY= X-Received: by 2002:a2e:91d1:: with SMTP id u17-v6mr19213841ljg.160.1548723390782; Mon, 28 Jan 2019 16:56:30 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> In-Reply-To: From: Eric Rescorla Date: Mon, 28 Jan 2019 16:55:53 -0800 Message-ID: To: Ted Hardie Cc: Justin Uberti , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009033f105808e4328" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 00:56:36 -0000 --0000000000009033f105808e4328 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 28, 2019 at 4:47 PM Ted Hardie wrote: > On Tue, Jan 29, 2019 at 9:36 AM Eric Rescorla wrote: > >> If we assume that this is a real problem as opposed to a specification >> problem, then I agree this is reasonable. However, so far nobody has shown >> me that this is a real problem, and until that this happens, I'm not in >> favor. >> >> > As a chair, I wish to confirm my understanding: you have no technical > objection to this solution, but you do not wish to include this because you > have seen no evidence of the problem. Is that correct? > No. I object to it because it's unnecessary complexity and moves against the consensus direction that we had that this field was meaningless. If it's necessary, then I'm willing to live with it. -Ekr > Yours is, at the moment, the only objection I have seen. Before going to > a call for a consensus, I want to make sure that the nature of any > objection is as clear as possible. > > thanks, > > Ted > > > > >> On Mon, Jan 28, 2019 at 2:51 PM Justin Uberti wrote: >> >>> Posted https://github.com/rtcweb-wg/jsep/pull/863 as a stab at a >>> consensus. This basically says that the offerer fills in either UDP/TLS/foo >>> or TCP/DTLS/foo based on the current default or selected candidate, in >>> accordance with sip-sdp. As Adam mentioned before, this shouldn't have any >>> impact on JSEP functionality. >>> >>> If this looks good, I'll polish it up. >>> >>> On Sun, Jan 27, 2019 at 3:22 AM Christer Holmberg < >>> christer.holmberg@ericsson.com> wrote: >>> >>>> Hi, >>>> >>>> >>>> > I'm not yet persuaded this is needed. The alleged need here is that >>>> there are some ICE-implementing endpoints which will choke if >>>> > they see a profile that doesn't match any actual candidate. I >>>> recognize that this is required by 5245, but that doesn't mean anyone >>>> > ever did it. Can you please point me to a client which would >>>> interoperate with a WebRTC endpoint with this change that would not >>>> > if you just always sent the same profile as JSEP currently requires. >>>> >>>> I don't think it is ok to *specify* that discarding a MUST is ok as >>>> long as nobody can show an implementation that would break by doing so. >>>> >>>> Having said that, in order to prevent an RTCWEB shutdown I am generally >>>> ok with Adam's approach. I would like my pull request comments to be >>>> addressed, though, that is related to separation between the JSEP API and >>>> an application using it: an application should be allowed to act according >>>> to 5245/draft-ice-sdp and update the c/m line if it wishes to, but due to >>>> the way the JSEP API works such applications might sometimes always include >>>> the same value in the c/m- line. >>>> >>>> I also think it shall be explicitly written that JSEP does not update >>>> 5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> On Thu, Jan 24, 2019 at 11:12 AM Adam Roach wrote: >>>> >>>> Based on conversations in MMUSIC, as well as several offline >>>> conversations with interested parties, I've put together a proposed >>>> change to JSEP that, if accepted, will allow publication of the Cluster >>>> 238 documents to move forward. >>>> >>>> Note that this new text has no impact on existing implementations (at >>>> least, as far as I am able to discern), which do not currently have the >>>> capability of producing media sections consisting of exclusively TCP >>>> candidates. From that perspective, the change makes existing >>>> implementations no less compliant with JSEP than they were before. >>>> >>>> What this change does provide is both on-paper and in-the-future >>>> compatibility between WebRTC implementations once they finalize TCP >>>> candidate handling (and candidate handling in general for mid-session >>>> offers). >>>> >>>> https://github.com/rtcweb-wg/jsep/pull/862/files >>>> >>>> The key insight here is that JSEP's use of ICE completely discards any >>>> meaning associated with the transport parameter, while SIP's use of ICE >>>> does not. The trivial change that I propose, which bears only on future >>>> WebRTC implementations -- that is, which has no as-built specification >>>> to point to -- allows JSEP to continue to ignore the value of the >>>> transport parameter, while specifying that it says the right thing for >>>> SIP implementations to function properly. >>>> >>>> /a >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > --0000000000009033f105808e4328 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 28, 2019 at 4:47 PM Ted H= ardie <ted.ietf@gmail.com> = wrote:
On Tue, Jan 29, 2019 at 9:36 AM Eric Rescorla <= ;ekr@rtfm.com> wro= te:
If we assume that this is a real problem as= opposed to a specification problem, then I agree this is reasonable. Howev= er, so far nobody has shown me that this is a real problem, and until that = this happens, I'm not in favor.


As a chair, I wish to confirm my understanding:=C2=A0 you have no te= chnical objection to this solution, but you do not wish to include this bec= ause you have seen no evidence of the problem.=C2=A0 Is that correct?=C2=A0=

No. I object to it = because it's unnecessary complexity and moves against the consensus dir= ection that we had that this field was meaningless.

If it's necessary, then I'm willing to live with it.

-Ekr

=C2=A0
Yours is, at the moment, the only objection I have s= een.=C2=A0 Before going to a call for a consensus, I want to make sure that= the nature of any objection is as clear as possible.

<= div>thanks,

Ted


<= /div>
=C2=A0
On Mon, Jan= 28, 2019 at 2:51 PM Justin Uberti <juberti@google.com> wrote:
Pos= ted=C2=A0https://github.com/rtcweb-wg/jsep/pull/863 as a stab at a consen= sus. This basically says that the offerer fills in either UDP/TLS/foo or TC= P/DTLS/foo based on the current default or selected candidate, in accordanc= e with sip-sdp. As Adam mentioned before, this shouldn't have any impac= t on JSEP functionality.

I= f this looks good, I'll polish it up.

christer.holmberg@ericsson= .com> wrote:

Hi,

=C2=A0

> I'm not yet persuaded this is needed. The alleged need here i= s that there are some ICE-implementing endpoints which will choke if=C2=A0<= br> > they see a profile that doesn't match any actual candidate. I reco= gnize that this is required by 5245, but that doesn't mean anyone=C2=A0=
> ever did it. Can you please point me to a client which would interoper= ate with a WebRTC endpoint with this change that would not=C2=A0
> if you just always sent the same profile as JSEP currently requir= es.

I don't think it is ok to *specify* that discarding a MUST is ok a= s long as nobody can show an implementation that would break by doing so.

Having said that, in order to prevent an RTCWEB shutdown I am generall= y ok with Adam's approach. I would like my pull request comments to be = addressed, though, that is related to separation between the JSEP API and a= n application using it: an application should be allowed to act according to 5245/draft-ice-sdp and update the c/= m line if it wishes to, but due to the way the JSEP API works such applicat= ions might sometimes always include the same value in the c/m- line.=C2=A0<= /div>

I also think it shall be explicitly written that JSEP does not update = 5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line.

Regards,

Christer




On Thu, Jan 24, 2019 at 11:12 AM Adam Roach <adam@nostrum.com&= gt; wrote:
Based on conversations in MMUSIC, as well as several offline
conversations with interested parties, I've put together a proposed change to JSEP that, if accepted, will allow publication of the Cluster 238 documents to move forward.

Note that this new text has no impact on existing implementations (at
least, as far as I am able to discern), which do not currently have the capability of producing media sections consisting of exclusively TCP
candidates. From that perspective, the change makes existing
implementations no less compliant with JSEP than they were before.

What this change does provide is both on-paper and in-the-future
compatibility between WebRTC implementations once they finalize TCP
candidate handling (and candidate handling in general for mid-session
offers).

=C2=A0=C2=A0 https://github.com/rtcweb-wg/jsep/pull/862/files

The key insight here is that JSEP's use of ICE completely discards any =
meaning associated with the transport parameter, while SIP's use of ICE=
does not. The trivial change that I propose, which bears only on future WebRTC implementations -- that is, which has no as-built specification
to point to -- allows JSEP to continue to ignore the value of the
transport parameter, while specifying that it says the right thing for
SIP implementations to function properly.

/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000009033f105808e4328-- From nobody Mon Jan 28 16:59:27 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1BA1277BB for ; Mon, 28 Jan 2019 16:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4bMquB0cMMX for ; Mon, 28 Jan 2019 16:59:24 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E53126DBF for ; Mon, 28 Jan 2019 16:59:23 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id e26so13343848lfc.2 for ; Mon, 28 Jan 2019 16:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mOQM08b/mrt7OXwR4RckvkKX58k72rZlQpRmfcxX+go=; b=KDWWNbUAvQZPui4Bfm7uZo3e0fz6UZ0wjM2TcwWnz5Tucv+s3nThhgcYDp1i3+rcjk v59i/mJG2Ad1rfxjgbRmkditYz7KmCQTNT0IsJUfOQ2nsz91YHM5uPr7CFnFNzq800HI swLsEx+hgBuq37/dBjfPOpxZ5uzWymDqGbyd2aywrpjWVMT5m61nw4xtg6deCzQSYuTU La0mJRFSdzifI9C4TCl+wkxydqMP4itsETAlLrThB84FunZ5p2rSnJj2QCwBXiDeTHsY Xhubp2Q8brtd4ZqYFx50GmVi6l6Ara4RLnAUCJiaM/Q2t581lwt7o+Kqr3r7r3w9xPsv NbGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mOQM08b/mrt7OXwR4RckvkKX58k72rZlQpRmfcxX+go=; b=Z8C97/e8cysbw9h7hopIECT3haUVXxqWKy2s0a+LWVkBYQDNP3PzGXnvY21hsG/AoG KVecipNW3LEg58oJFtpJsyviAckBoRo4aka4n8vv317wg5kRfl3J653MSJKrlt9/1kYt QFdbXVT1aDR5wUBkiWpKG47fcd+YlkrTaR4tSIGMbkEu7SY/ai4GdkwSP6RKDrYFmwaO qOBJehFedpojnXUn7GZc7dOOO5X0Y9sWbdt3o7rQpDAAO5Heh7ukI6ogjcyCwzU5tvQf E7NfytQJHhSiwzrl+pTgyYdXdn367MZAXrvKKj5j1zz46+c/oxWtApAp+iASsfJSPPNX Aqdg== X-Gm-Message-State: AJcUukcsYm9+fBOAYzx+c7sNDnRvrJ7UD1Qh1qkZB1ppk7x2K35AeCxx lPlyPsit+XkSQbpSI0XCgBUBrs0SKzuMQvyat+JH/w== X-Google-Smtp-Source: ALg8bN5epNlSWJo0ckNLmw80mHl6WCcFG7M3ZDS0OSqqEIWI4XsidSwLMAnRnVSbFaWQdimDh1+AtPjYvFBPFMawYh4= X-Received: by 2002:a19:3fcf:: with SMTP id m198mr16657587lfa.106.1548723561717; Mon, 28 Jan 2019 16:59:21 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> In-Reply-To: From: Eric Rescorla Date: Mon, 28 Jan 2019 16:58:44 -0800 Message-ID: To: Roman Shpount Cc: Justin Uberti , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c07fc005808e4d38" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 00:59:26 -0000 --000000000000c07fc005808e4d38 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 28, 2019 at 4:50 PM Roman Shpount wrote: > On Mon, Jan 28, 2019 at 7:36 PM Eric Rescorla wrote: > >> If we assume that this is a real problem as opposed to a specification >> problem, then I agree this is reasonable. However, so far nobody has shown >> me that this is a real problem, and until that this happens, I'm not in >> favor. >> >> What would you consider a real problem? > A system with substantial deployment that works properly with WebRTC if the default candidates are UDP but not when the default candidates are TCP and the proto is UDP/foo -Ekr > Would the fact that SDP manipulation in WebRTC JavaScript client or on the > server to work with WebRTC be considered a real problem or a minor > inconvenience? > > Regards, > _____________ > Roman Shpount > > --000000000000c07fc005808e4d38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 28, 2019 at 4:50 PM Roman= Shpount <roman@telurix.com>= wrote:
On Mon, Jan 28, 2019 at 7:36 PM Eric Rescorla &l= t;ekr@rtfm.com> wr= ote:
If we assume that this is a re= al problem as opposed to a specification problem, then I agree this is reas= onable. However, so far nobody has shown me that this is a real problem, an= d until that this happens, I'm not in favor.

=
What would you consider a real problem?
=

A system with substantial deployment that works properl= y with WebRTC if the default candidates are UDP but not when the default ca= ndidates are TCP and the proto is UDP/foo

-Ekr=


Would the fact = that SDP manipulation in WebRTC JavaScript client or on the server to work = with WebRTC be considered a real problem or a minor inconvenience?

Regards,
_____________
Roman Shpount
=C2=A0
--000000000000c07fc005808e4d38-- From nobody Mon Jan 28 17:09:54 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A77B1277BB for ; Mon, 28 Jan 2019 17:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIitcJkMl_qx for ; Mon, 28 Jan 2019 17:09:50 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69F8126CB6 for ; Mon, 28 Jan 2019 17:09:50 -0800 (PST) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0T19mPi082120 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 28 Jan 2019 19:09:50 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1548724190; bh=H8NQKc+ONr/+uj826ki9fTb8aMghMoQKu+wunbUdwRU=; h=Subject:To:References:From:Date:In-Reply-To; b=ohZuPGI0Hmjxq1wG6w2YM+YJwwKoDax7j9w6u/UNIKMdEdnOXFLZo5MYwxAlVcsQY dytyjJCZScGgOZX2JRXBMc+Ds99q010/9aCsDFFRBsTA2wSCzaiK3sdNva+AldcT4T yThkmQ2WfOI10zhyFmqHSOQ0pb46JJyFN2re+aZw= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: rtcweb@ietf.org References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> From: Adam Roach Message-ID: <937eade0-f126-472a-d990-aa4b65ea5a82@nostrum.com> Date: Mon, 28 Jan 2019 19:09:43 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 01:09:53 -0000 [as an individual] On 1/28/19 6:55 PM, Eric Rescorla wrote: > it's unnecessary complexity To make sure we're not all overlooking something that is obvious to you -- can you describe the complexity involved here? /a From nobody Mon Jan 28 17:10:22 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471E4126DBF for ; Mon, 28 Jan 2019 17:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SosTX8xEFezS for ; Mon, 28 Jan 2019 17:10:17 -0800 (PST) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17A9312875B for ; Mon, 28 Jan 2019 17:10:17 -0800 (PST) Received: by mail-oi1-x236.google.com with SMTP id x23so14797510oix.3 for ; Mon, 28 Jan 2019 17:10:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=grnS0NyhB05vK2ZTZaziKZn0SyUiyuOq4AL10Yv05J4=; b=tWA2Tgaxn6z6ehQ+6LdnySLaKS99arMnxtNt4eYAXRDOpbaRk4nuJ8PlIRzm3usfs0 03vh9xH+UNtyEHbCjVBJtP+5NlZGcPnUzmBsLxv0M6T0b6GtkBDBP5WDFDMauoA/4ZOt JIT26ci5zpxMTEx8Sj9KDxLUAFfNyk48M1dgOqDqSmnF+UuDNE3qpTECjEvw+Moj8RsA PNGMtiqTdSTmEGJSSpycBPHHwmb510J9/BE9iDegLj0PDmRWB/jvlq9Ar9p8n2k7CR9k IGFn34PMLqQuPoYpJVhMiMlUPPn/JygISgAw0lR4e+a58Nk/CpKqnOq8BG/sAHCFU2T/ q/nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=grnS0NyhB05vK2ZTZaziKZn0SyUiyuOq4AL10Yv05J4=; b=V/dYOrSEqtHvhrGwurGdxTLsR26Zc5j4sIYSSZQRix3KBbdkudxzVhzUmwchiERUNO wt6FWFgxFhaphEsqY5FWjmM3ZoUbW4/8tp+BFy3lpIjxassqGzBK5sviWy9urdeicqji QswXSIyo5YCYRwW8u1ddcAdlO9QtJ6K6lk/6XhKFJe0L+JrYWmyteEOjbWXsJXNwfhCo 7Yw3465yZqRJkEmDigGiO1ySl0jlzpQrD0fZWlDrQZ6I2NkkL1xQb8upMRNpFo9NyZvZ /P4xTMrP+Afj6hw+g5POFH33kbCJgEzwTwfIE4yr3oh0rLCi4LUgBX1Am5daZA5O4nw3 O4JQ== X-Gm-Message-State: AJcUukf/Y2OHBHgnak0zim013qLI1cVqM3V24fMns9SynKvaG54zfI8o z9yyX/SpyuswQJ0vvVtn5+fBRmWkpbkaRiCjrT0= X-Google-Smtp-Source: ALg8bN6SYcXtB9jTld5TnoDyS9/MDbvxVUTdxTAmVpKU0Gzlre7rptv579GC6iSsaO1qALE+FMuK2MKKRO37vLFhI3E= X-Received: by 2002:aca:1b0a:: with SMTP id b10mr7938546oib.192.1548724216096; Mon, 28 Jan 2019 17:10:16 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> In-Reply-To: From: Ted Hardie Date: Tue, 29 Jan 2019 10:09:48 +0900 Message-ID: To: Eric Rescorla Cc: Justin Uberti , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c16d5905808e74bf" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 01:10:20 -0000 --000000000000c16d5905808e74bf Content-Type: text/plain; charset="UTF-8" In-line. On Tue, Jan 29, 2019 at 9:56 AM Eric Rescorla wrote: > > > On Mon, Jan 28, 2019 at 4:47 PM Ted Hardie wrote: > >> On Tue, Jan 29, 2019 at 9:36 AM Eric Rescorla wrote: >> >>> If we assume that this is a real problem as opposed to a specification >>> problem, then I agree this is reasonable. However, so far nobody has shown >>> me that this is a real problem, and until that this happens, I'm not in >>> favor. >>> >>> >> As a chair, I wish to confirm my understanding: you have no technical >> objection to this solution, but you do not wish to include this because you >> have seen no evidence of the problem. Is that correct? >> > > No. I object to it because it's unnecessary complexity and moves against > the consensus direction that we had that this field was meaningless. > > That consensus was limited to JSEP; other related uses of SIP/SDP do not treat it as meaningless. The additional complexity added to a system is, of course, always a concern. But I interpret your statement "If it's necessary, then I'm willing to live with it." as agreeing that this solution will work if the additional domain of interoperability which results is not empty. Please correct me, if I have gotten this wrong. thanks, Ted > > >> On Mon, Jan 28, 2019 at 2:51 PM Justin Uberti wrote: >> >>> Posted https://github.com/rtcweb-wg/jsep/pull/863 as a stab at a >>> consensus. This basically says that the offerer fills in either UDP/TLS/foo >>> or TCP/DTLS/foo based on the current default or selected candidate, in >>> accordance with sip-sdp. As Adam mentioned before, this shouldn't have any >>> impact on JSEP functionality. >>> >>> If this looks good, I'll polish it up. >>> >>> On Sun, Jan 27, 2019 at 3:22 AM Christer Holmberg < >>> christer.holmberg@ericsson.com> wrote: >>> >>>> Hi, >>>> >>>> >>>> > I'm not yet persuaded this is needed. The alleged need here is that >>>> there are some ICE-implementing endpoints which will choke if >>>> > they see a profile that doesn't match any actual candidate. I >>>> recognize that this is required by 5245, but that doesn't mean anyone >>>> > ever did it. Can you please point me to a client which would >>>> interoperate with a WebRTC endpoint with this change that would not >>>> > if you just always sent the same profile as JSEP currently requires. >>>> >>>> I don't think it is ok to *specify* that discarding a MUST is ok as >>>> long as nobody can show an implementation that would break by doing so. >>>> >>>> Having said that, in order to prevent an RTCWEB shutdown I am generally >>>> ok with Adam's approach. I would like my pull request comments to be >>>> addressed, though, that is related to separation between the JSEP API and >>>> an application using it: an application should be allowed to act according >>>> to 5245/draft-ice-sdp and update the c/m line if it wishes to, but due to >>>> the way the JSEP API works such applications might sometimes always include >>>> the same value in the c/m- line. >>>> >>>> I also think it shall be explicitly written that JSEP does not update >>>> 5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> On Thu, Jan 24, 2019 at 11:12 AM Adam Roach wrote: >>>> >>>> Based on conversations in MMUSIC, as well as several offline >>>> conversations with interested parties, I've put together a proposed >>>> change to JSEP that, if accepted, will allow publication of the Cluster >>>> 238 documents to move forward. >>>> >>>> Note that this new text has no impact on existing implementations (at >>>> least, as far as I am able to discern), which do not currently have the >>>> capability of producing media sections consisting of exclusively TCP >>>> candidates. From that perspective, the change makes existing >>>> implementations no less compliant with JSEP than they were before. >>>> >>>> What this change does provide is both on-paper and in-the-future >>>> compatibility between WebRTC implementations once they finalize TCP >>>> candidate handling (and candidate handling in general for mid-session >>>> offers). >>>> >>>> https://github.com/rtcweb-wg/jsep/pull/862/files >>>> >>>> The key insight here is that JSEP's use of ICE completely discards any >>>> meaning associated with the transport parameter, while SIP's use of ICE >>>> does not. The trivial change that I propose, which bears only on future >>>> WebRTC implementations -- that is, which has no as-built specification >>>> to point to -- allows JSEP to continue to ignore the value of the >>>> transport parameter, while specifying that it says the right thing for >>>> SIP implementations to function properly. >>>> >>>> /a >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > --000000000000c16d5905808e74bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In-line.

On Tue, Jan 29, 2019 at 9:56 AM Eric Resc= orla <ekr@rtfm.com> wrote:


On Mon, Jan 28, 2019 at 4:47 PM = Ted Hardie <ted.= ietf@gmail.com> wrote:
On Tue, Jan 29, 2019 at 9:3= 6 AM Eric Rescorla <ek= r@rtfm.com> wrote:
If we assume that thi= s is a real problem as opposed to a specification problem, then I agree thi= s is reasonable. However, so far nobody has shown me that this is a real pr= oblem, and until that this happens, I'm not in favor.


As a chair, I wish to confirm my understanding= :=C2=A0 you have no technical objection to this solution, but you do not wi= sh to include this because you have seen no evidence of the problem.=C2=A0 = Is that correct?=C2=A0

No. I object to it because it's unnecessary complexity and moves aga= inst the consensus direction that we had that this field was meaningless.

That consensus was lim= ited to JSEP; other related uses of SIP/SDP do not treat it as meaningless.= =C2=A0

The additional c= omplexity added to a system is, of course, always a concern.=C2=A0 But=C2= =A0 I interpret your statement "If it's necessary, then I'm wi= lling to live with it." as agreeing that this solution will work if th= e additional domain of interoperability which results is not empty.

Please correc= t me, if I have gotten this wrong.

thanks,

Ted




=C2=A0
On Mon, Jan 28, 2019= at 2:51 PM Justin Uberti <juberti@google.com> wrote:
Posted=C2= =A0https://github.com/rtcweb-wg/jsep/pull/863 as a stab at a consensus. T= his basically says that the offerer fills in either UDP/TLS/foo or TCP/DTLS= /foo based on the current default or selected candidate, in accordance with= sip-sdp. As Adam mentioned before, this shouldn't have any impact on J= SEP functionality.

If this= looks good, I'll polish it up.

On Sun, Jan 27, 2019 at 3:22 AM Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

> I'm not yet persuaded this is needed. The alleged need here i= s that there are some ICE-implementing endpoints which will choke if=C2=A0<= br> > they see a profile that doesn't match any actual candidate. I reco= gnize that this is required by 5245, but that doesn't mean anyone=C2=A0=
> ever did it. Can you please point me to a client which would interoper= ate with a WebRTC endpoint with this change that would not=C2=A0
> if you just always sent the same profile as JSEP currently requir= es.

I don't think it is ok to *specify* that discarding a MUST is ok a= s long as nobody can show an implementation that would break by doing so.

Having said that, in order to prevent an RTCWEB shutdown I am generall= y ok with Adam's approach. I would like my pull request comments to be = addressed, though, that is related to separation between the JSEP API and a= n application using it: an application should be allowed to act according to 5245/draft-ice-sdp and update the c/= m line if it wishes to, but due to the way the JSEP API works such applicat= ions might sometimes always include the same value in the c/m- line.=C2=A0<= /div>

I also think it shall be explicitly written that JSEP does not update = 5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line.

Regards,

Christer




On Thu, Jan 24, 2019 at 11= :12 AM Adam Roach <adam@nostrum.co= m> wrote:
Based on conversations in MMUSIC, as well as several offline
conversations with interested parties, I've put together a proposed change to JSEP that, if accepted, will allow publication of the Cluster 238 documents to move forward.

Note that this new text has no impact on existing implementations (at
least, as far as I am able to discern), which do not currently have the capability of producing media sections consisting of exclusively TCP
candidates. From that perspective, the change makes existing
implementations no less compliant with JSEP than they were before.

What this change does provide is both on-paper and in-the-future
compatibility between WebRTC implementations once they finalize TCP
candidate handling (and candidate handling in general for mid-session
offers).

=C2=A0=C2=A0 https://github.com/rtcweb-wg/jsep/pull/862/files

The key insight here is that JSEP's use of ICE completely discards any =
meaning associated with the transport parameter, while SIP's use of ICE=
does not. The trivial change that I propose, which bears only on future WebRTC implementations -- that is, which has no as-built specification
to point to -- allows JSEP to continue to ignore the value of the
transport parameter, while specifying that it says the right thing for
SIP implementations to function properly.

/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000c16d5905808e74bf-- From nobody Mon Jan 28 17:24:11 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C917126DBF for ; Mon, 28 Jan 2019 17:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dCjnZ7UAeT0 for ; Mon, 28 Jan 2019 17:24:07 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E7E0126CB6 for ; Mon, 28 Jan 2019 17:24:07 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id a16so13371367lfg.3 for ; Mon, 28 Jan 2019 17:24:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XEmqukbRhj1dqVqEyqw3sKxv5LBd3lNgaVNNzpHahrs=; b=co1XrPKNI/aJ3rfCRUfcF+4KI/rYFeVAruX3Beq9uJWg2RMuGmFjHyq3Y8N9A1jdpZ QSKgudQAONsMVuVBbA4c99Qp/PDmt2lfwhFL0CxlQD87bUDx3HE+KTJbuTaa7oQi/pf8 TwSlo3C3rxpMB9y5nwD1TXD8hR1sRvVxe5JyldnnwUTOuU7TECK1j8P9/q/cXD+Jtb32 diQ2hGoDHGub2fNM3Yb5ZIB96O1isufi3I1WGwprDdz7JvK5CegmqlpPug6jkGgfy0ut /lTay8H19tTo3WLZOxqYnRACtfRoYXoVvKGFNCEYCCf/UR5KOWmJRcvCZ7YLFBcC1Gjs mnhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XEmqukbRhj1dqVqEyqw3sKxv5LBd3lNgaVNNzpHahrs=; b=EFiWYhiEC3WPeZ5aQu+97bFAqBz1m4POQY20m1Kjj/4+sW2o2v9n/aiGRc+I+sbc6Q odSC8/+RrJ446BLKep6pAM3IZOX7V4ugJclRjohRRbI/CsH+J8QQj/CQ9JfUIDTMVRG8 i1ST/jun08scf2ER0pldass5xPZmyXFHohlr98rXhXL+f4RPKPNPywjdyxYDWq2028xs k05P9ehTyeN5Je7Gp8GkSCnpAOxx4wzvUWZtxSb7XXa7z8k2iDrEE/WxXnpKXISGCFCL ysYBnqAw6RGvj4JNARHr8JtLO+GCyTqEcGo434hAGG32ZUi65fT5w4PTT7nmPZCPKcsQ xx9g== X-Gm-Message-State: AJcUukcQeqaKbT7/GIJy8JTj4E2s26U9pYZRvUbRirjwjI0/yJ9Kp/a7 iOp6JrVe6HGSlUbiiny1ewOEqRPE8RunxLoY2EcMmA== X-Google-Smtp-Source: ALg8bN5r8SEDuyz2xflP04fQ29LZBpS2PbESQCLvUt6h4zPkuqthw+YtPGdJgGNRVW0qir+djaNUdNgQZgoBE8pcLwc= X-Received: by 2002:a19:3fcf:: with SMTP id m198mr16704679lfa.106.1548725045375; Mon, 28 Jan 2019 17:24:05 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> In-Reply-To: From: Eric Rescorla Date: Mon, 28 Jan 2019 17:23:27 -0800 Message-ID: To: Ted Hardie Cc: Justin Uberti , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002f443205808ea602" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 01:24:10 -0000 --0000000000002f443205808ea602 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 28, 2019 at 5:10 PM Ted Hardie wrote: > In-line. > > On Tue, Jan 29, 2019 at 9:56 AM Eric Rescorla wrote: > >> >> >> On Mon, Jan 28, 2019 at 4:47 PM Ted Hardie wrote: >> >>> On Tue, Jan 29, 2019 at 9:36 AM Eric Rescorla wrote: >>> >>>> If we assume that this is a real problem as opposed to a specification >>>> problem, then I agree this is reasonable. However, so far nobody has shown >>>> me that this is a real problem, and until that this happens, I'm not in >>>> favor. >>>> >>>> >>> As a chair, I wish to confirm my understanding: you have no technical >>> objection to this solution, but you do not wish to include this because you >>> have seen no evidence of the problem. Is that correct? >>> >> >> No. I object to it because it's unnecessary complexity and moves against >> the consensus direction that we had that this field was meaningless. >> >> That consensus was limited to JSEP; > Yes, and we're talking about the JSEP spec here. other related uses of SIP/SDP do not treat it as meaningless. > That seems to be assuming the answer to my question. The additional complexity added to a system is, of course, always a > concern. But I interpret your statement "If it's necessary, then I'm > willing to live with it." as agreeing that this solution will work if the > additional domain of interoperability which results is not empty. > No, that's not what I said. What I said was "A system with substantial deployment that works properly with WebRTC if the default candidates are UDP but not when the default candidates are TCP and the proto is UDP/foo" -Ekr > Ted > > > > >> >> >>> On Mon, Jan 28, 2019 at 2:51 PM Justin Uberti >>> wrote: >>> >>>> Posted https://github.com/rtcweb-wg/jsep/pull/863 as a stab at a >>>> consensus. This basically says that the offerer fills in either UDP/TLS/foo >>>> or TCP/DTLS/foo based on the current default or selected candidate, in >>>> accordance with sip-sdp. As Adam mentioned before, this shouldn't have any >>>> impact on JSEP functionality. >>>> >>>> If this looks good, I'll polish it up. >>>> >>>> On Sun, Jan 27, 2019 at 3:22 AM Christer Holmberg < >>>> christer.holmberg@ericsson.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> > I'm not yet persuaded this is needed. The alleged need here is that >>>>> there are some ICE-implementing endpoints which will choke if >>>>> > they see a profile that doesn't match any actual candidate. I >>>>> recognize that this is required by 5245, but that doesn't mean anyone >>>>> > ever did it. Can you please point me to a client which would >>>>> interoperate with a WebRTC endpoint with this change that would not >>>>> > if you just always sent the same profile as JSEP currently requires. >>>>> >>>>> I don't think it is ok to *specify* that discarding a MUST is ok as >>>>> long as nobody can show an implementation that would break by doing so. >>>>> >>>>> Having said that, in order to prevent an RTCWEB shutdown I am >>>>> generally ok with Adam's approach. I would like my pull request comments to >>>>> be addressed, though, that is related to separation between the JSEP API >>>>> and an application using it: an application should be allowed to act >>>>> according to 5245/draft-ice-sdp and update the c/m line if it wishes to, >>>>> but due to the way the JSEP API works such applications might sometimes >>>>> always include the same value in the c/m- line. >>>>> >>>>> I also think it shall be explicitly written that JSEP does not update >>>>> 5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Jan 24, 2019 at 11:12 AM Adam Roach wrote: >>>>> >>>>> Based on conversations in MMUSIC, as well as several offline >>>>> conversations with interested parties, I've put together a proposed >>>>> change to JSEP that, if accepted, will allow publication of the >>>>> Cluster >>>>> 238 documents to move forward. >>>>> >>>>> Note that this new text has no impact on existing implementations (at >>>>> least, as far as I am able to discern), which do not currently have >>>>> the >>>>> capability of producing media sections consisting of exclusively TCP >>>>> candidates. From that perspective, the change makes existing >>>>> implementations no less compliant with JSEP than they were before. >>>>> >>>>> What this change does provide is both on-paper and in-the-future >>>>> compatibility between WebRTC implementations once they finalize TCP >>>>> candidate handling (and candidate handling in general for mid-session >>>>> offers). >>>>> >>>>> https://github.com/rtcweb-wg/jsep/pull/862/files >>>>> >>>>> The key insight here is that JSEP's use of ICE completely discards any >>>>> meaning associated with the transport parameter, while SIP's use of >>>>> ICE >>>>> does not. The trivial change that I propose, which bears only on >>>>> future >>>>> WebRTC implementations -- that is, which has no as-built specification >>>>> to point to -- allows JSEP to continue to ignore the value of the >>>>> transport parameter, while specifying that it says the right thing for >>>>> SIP implementations to function properly. >>>>> >>>>> /a >>>>> >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> >>>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> --0000000000002f443205808ea602 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 28, 2019 at 5:10 PM Ted H= ardie <ted.ietf@gmail.com> = wrote:
In-line.

On Tue, Jan 29, 2019 a= t 9:56 AM Eric Rescorla <ekr@rtfm.com> wrote:


On Mon, Jan 28, 2019 at 4:47 PM Ted Hardi= e <ted.ietf@gmai= l.com> wrote:
On Tue, Jan 29, 2019 at 9:36 AM Eric= Rescorla <ekr@rtfm.co= m> wrote:
If we assume that this is a re= al problem as opposed to a specification problem, then I agree this is reas= onable. However, so far nobody has shown me that this is a real problem, an= d until that this happens, I'm not in favor.

=

As a chair, I wish to confirm my understanding:=C2=A0 y= ou have no technical objection to this solution, but you do not wish to inc= lude this because you have seen no evidence of the problem.=C2=A0 Is that c= orrect?=C2=A0

No. I = object to it because it's unnecessary complexity and moves against the = consensus direction that we had that this field was meaningless.
<= div>
That consensus was limited to J= SEP;

Yes, and we're = talking about the JSEP spec here.


other related uses of SIP/SDP do not treat it as meaning= less.=C2=A0

That see= ms to be assuming the answer to my question.


<= /div>
The additional complexit= y added to a system is, of course, always a concern.=C2=A0 But=C2=A0 I inte= rpret your statement "If it's necessary, then I'm willing to l= ive with it." as agreeing that this solution will work if the addition= al domain of interoperability which results is not empty.
=

No, that's not what I said. What I sai= d was "A system with substantial deployment that works properly with W= ebRTC if=20 the default candidates are UDP but not when the default candidates are=20 TCP and the proto is UDP/foo"

-Ekr
=

Ted




=C2=A0
On = Mon, Jan 28, 2019 at 2:51 PM Justin Uberti <juberti@google.com> wrote:
Posted=C2=A0https://github.com/rtcweb-wg/jsep/pull/863 as a stab at = a consensus. This basically says that the offerer fills in either UDP/TLS/f= oo or TCP/DTLS/foo based on the current default or selected candidate, in a= ccordance with sip-sdp. As Adam mentioned before, this shouldn't have a= ny impact on JSEP functionality.

If this looks good, I'll polish it up.

On Sun, J= an 27, 2019 at 3:22 AM Christer Holmberg <christer.holmberg@ericsson.com>= ; wrote:

Hi,

=C2=A0

> I'm not yet persuaded this is needed. The alleged need here i= s that there are some ICE-implementing endpoints which will choke if=C2=A0<= br> > they see a profile that doesn't match any actual candidate. I reco= gnize that this is required by 5245, but that doesn't mean anyone=C2=A0=
> ever did it. Can you please point me to a client which would interoper= ate with a WebRTC endpoint with this change that would not=C2=A0
> if you just always sent the same profile as JSEP currently requir= es.

I don't think it is ok to *specify* that discarding a MUST is ok a= s long as nobody can show an implementation that would break by doing so.

Having said that, in order to prevent an RTCWEB shutdown I am generall= y ok with Adam's approach. I would like my pull request comments to be = addressed, though, that is related to separation between the JSEP API and a= n application using it: an application should be allowed to act according to 5245/draft-ice-sdp and update the c/= m line if it wishes to, but due to the way the JSEP API works such applicat= ions might sometimes always include the same value in the c/m- line.=C2=A0<= /div>

I also think it shall be explicitly written that JSEP does not update = 5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line.

Regards,

Christer




On Thu, Jan 24, 2019 at 11:12 AM Adam Roach <adam@nost= rum.com> wrote:
Based on conversations in MMUSIC, as well as several offline
conversations with interested parties, I've put together a proposed change to JSEP that, if accepted, will allow publication of the Cluster 238 documents to move forward.

Note that this new text has no impact on existing implementations (at
least, as far as I am able to discern), which do not currently have the capability of producing media sections consisting of exclusively TCP
candidates. From that perspective, the change makes existing
implementations no less compliant with JSEP than they were before.

What this change does provide is both on-paper and in-the-future
compatibility between WebRTC implementations once they finalize TCP
candidate handling (and candidate handling in general for mid-session
offers).

=C2=A0=C2=A0 https://github.com/rtcweb-wg/jsep/pull/862/files

The key insight here is that JSEP's use of ICE completely discards any =
meaning associated with the transport parameter, while SIP's use of ICE=
does not. The trivial change that I propose, which bears only on future WebRTC implementations -- that is, which has no as-built specification
to point to -- allows JSEP to continue to ignore the value of the
transport parameter, while specifying that it says the right thing for
SIP implementations to function properly.

/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000002f443205808ea602-- From nobody Mon Jan 28 17:25:07 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B11C1277BB for ; Mon, 28 Jan 2019 17:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jar32trrfZx6 for ; Mon, 28 Jan 2019 17:25:04 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A01126DBF for ; Mon, 28 Jan 2019 17:25:04 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id x85-v6so16039391ljb.2 for ; Mon, 28 Jan 2019 17:25:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gzItv2JbE20L8Hdhvx58X+gL6sFN4zNIUwmvsybj5bE=; b=W8CjIpwB23QmH6K9VUUpf0+EK9a9KpR4VbDPonBGaOjs9kpQwJkBIZckkmb/dexpPu AUueEr/V/rmZRXg9rZExQH2b2x6hfgUJIoTUyihbiO6QIJzlh91oeRepI0SdFKoG8ndK JLGwCB467y5wM1jpnG0fH+MqCSp2QU2pcdb4nvwiePXk/IniFkPAnTcWCqED1fS67zwt sWoGGOWKOnNTMGxYu6psYvQ2zlje5/NCzFTcuxDnWIsLrOCsJK1HJxz2NC32cUikJVGK hyUFO4k0K05MixQz0kTtC/zZy5gEeOddYLGSY+1TPPfRrYzaPoDy3bbuS98En2Q/RHTA jp8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gzItv2JbE20L8Hdhvx58X+gL6sFN4zNIUwmvsybj5bE=; b=IRjQoNsPG2llzkimzbvbpPeKbVZcZdGI3o+IGxIwEOfVXfAf+k+trRNHZhJ6u7yuLA mYDL718RUpYmtxadwXiTSOCdWqU6lgw2xC+PRXeGOBc2DsuWaEAXT+gUvF9H8hwpVyAj DtAn3mZXFMhI8trcEIlWxhGWh5Ge9mTGykVJuYM8VIMGStwk4CS0/1/Q+oOo+DpSiHY6 zG6uVIk6EHtZDkeVXHPwzIZhqQX9m9qTk6SiAODaavPeG7uRT+7zxBN8/lYGtfrhD6yu GbkboAaqHeMoNcRgJuWm78X4+/BedlLLG+uG09tHVxvnjwjHsNW3XmjzTR7cZY8dSAWm dx7A== X-Gm-Message-State: AJcUukdjIcGyNQDVfdK3EhqYfMp2cWe1TJ8bmECpDWOdEnP5UAelEEc+ HjifD9c5FD+SHRJzJGU9uK/b8sLUPRayDeCa4Iw7+uwV X-Google-Smtp-Source: ALg8bN5s5+zkLOXQ5jRJJwynD6Z2dfOJDKwGfZyN3FxKwy8oD8a7TDQtb5ZsU3mwbf8FWbkycxp1Ld0MSj3otx7Jvyk= X-Received: by 2002:a2e:a202:: with SMTP id h2-v6mr18812347ljm.72.1548725102380; Mon, 28 Jan 2019 17:25:02 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <937eade0-f126-472a-d990-aa4b65ea5a82@nostrum.com> In-Reply-To: <937eade0-f126-472a-d990-aa4b65ea5a82@nostrum.com> From: Eric Rescorla Date: Mon, 28 Jan 2019 17:24:25 -0800 Message-ID: To: Adam Roach Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000951ef305808ea9fb" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 01:25:06 -0000 --000000000000951ef305808ea9fb Content-Type: text/plain; charset="UTF-8" On Mon, Jan 28, 2019 at 5:10 PM Adam Roach wrote: > [as an individual] > > On 1/28/19 6:55 PM, Eric Rescorla wrote: > > it's unnecessary complexity > > > To make sure we're not all overlooking something that is obvious to you > -- can you describe the complexity involved here? > Having to condition what you put in the proto line depending on the candidates is more complexity than not having to do so. -Ekr > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000951ef305808ea9fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 28, 2019 at 5:10 PM Adam = Roach <adam@nostrum.com> wrot= e:
[as an indivi= dual]

On 1/28/19 6:55 PM, Eric Rescorla wrote:
> it's unnecessary complexity


To make sure we're not all overlooking something that is obvious to you=
-- can you describe the complexity involved here?

=
Having to condition what you put in the proto line depending on = the candidates is more complexity than not having to do so.

<= /div>
-Ekr


/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000951ef305808ea9fb-- From nobody Mon Jan 28 17:26:50 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1EC1277BB for ; Mon, 28 Jan 2019 17:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_00gwa548q9 for ; Mon, 28 Jan 2019 17:26:46 -0800 (PST) Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890DB126CB6 for ; Mon, 28 Jan 2019 17:26:46 -0800 (PST) Received: by mail-vs1-xe44.google.com with SMTP id y27so11044182vsi.1 for ; Mon, 28 Jan 2019 17:26:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vqEz/LKi69YAVrskwRHiVpMMU6N5NDl99xOGnqRuUuc=; b=q/1sRiozr3Zj+lezYfPp1ODnzH2H1HdMhbb7bVVt7Opr4ipehPFpy46kiydJ8mND0n 3H7S28GowUhdPkOLt/CFHFHWRhB5kYCsXgmvl2HspTX8R+Quichgjswo6F62fMiDUsfi uwUTHMJNKCtLXa8WfaAQrls09DYUZBMQvBtW0uyCmhST/S2SdyBGFQ3JVK5wpmmXSosl Kn3+Ye4HCQxFbpRfj3kcX+pYzrW7G8UT3Azos6dxitLS3PD1CBAChz9tasnUeIaQHTM5 OM/I2AR5XEIozvQWmawCdgiNPtMN6LwTa/HwTkiEHlCLdR3Q1AiRbba7gI8ydD73S7fO JB7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vqEz/LKi69YAVrskwRHiVpMMU6N5NDl99xOGnqRuUuc=; b=swwFO8PWarf10YKIxN6kmILpBTvel1S/OOqrKMQmCAY+fDGty/MFVM9bBGv56bZsoi 1yrZjbanX0xgLMxEz0nn+Igr/lgG1XZV2b5jtGy72kJ8+wdTSq7lVnIWA0v5Te3WLvaA PmOwr+K4ybH6RaLSwIQUJrXrdFOKMu4ruy3HKiz9Pz+bU/jOyO2g9hNYwyuRCv9S5opl wZTNb9fRkuK5qv9Ny1J+zRqnvA2jGg5gVGCprjdmUBp9tYKRAFmUel0Zkzwe3ZvZMqvI 7Z5lDV3Iqx1+Eors+PFkJzf30ZQg3XWQzl6xHZ9E2GOKw4VgM96k+pS7ZClgaFy1pwTm pluQ== X-Gm-Message-State: AJcUukd00LDv5Lq/5HWFpHlhYfJi3Df4QDgOEgPflTNtXq5617aZtQoy g7ybORj27d/MiU4XAwiVW2D1zd/bPtmW2GC5Y/8wDA== X-Google-Smtp-Source: ALg8bN6eQ2sIb/nZmUN2pDKXpNopyYfBaBbOPWeP6ff4XWqEVaugSVC2zf5HpPa4zXG6dXQW1NFrY3d/mdOzpn1/MCI= X-Received: by 2002:a67:7106:: with SMTP id m6mr10388752vsc.67.1548725205494; Mon, 28 Jan 2019 17:26:45 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 29 Jan 2019 02:26:33 +0100 Message-ID: To: Ted Hardie Cc: Eric Rescorla , "rtcweb@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 01:26:49 -0000 On Tue, 29 Jan 2019 at 02:10, Ted Hardie wrote: > That consensus was limited to JSEP; other related uses of SIP/SDP do not = treat it as meaningless. > > The additional complexity added to a system is, of course, always a conce= rn. But I interpret your statement "If it's necessary, then I'm willing t= o live with it." as agreeing that this solution will work if the additional= domain of interoperability which results is not empty. The summary is basically that it adds extra complexity to WebRTC without absolutely any advantage or added feature. Anyway: > Implementations MUST indicate this profile for each media m=3D line they produce in an offer unless the media section contains only TCP candidates; if all candidates use TCP as a transport, implementations MUST indicate "TCP/DTLS/RTP/SAVPF," to allow for compatibility with non-WebRTC implementations Some concerns: 1) Browser and WebRTC "clients" will always offer UDP candidates, so the above is not likely to happen. 2) If it happens (there are just TCP candidates) this is probably because the server mandates TCP, so the "service monitoring system" already knows that. 3) The browser offers UDP and TCP candidates so will place "UDP/TLS/RTP/SAVPF" in the transport. Then the server replies with just TCP candidates. I assume that the server would also use "UDP/TLS/RTP/SAVPF" in the answer (because it must match the transport value in the offer) but, do we expect that the browser will "send a re-offer with TCP/DTLS/RTP/SAVPF" to conform to this spec? That won't happen. So how is this useful at all for the service monitoring system? Instead of all this folklore, couldn't the "phone" just send a multi-purpose OPTIONS somewhere once it knows the selected ICE tuple and we are done? That can be easily implemented in flexible SIP and WebRTC stacks. --=20 I=C3=B1aki Baz Castillo From nobody Mon Jan 28 17:42:16 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1114D1277BB for ; Mon, 28 Jan 2019 17:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJbt6Ciszhey for ; Mon, 28 Jan 2019 17:42:13 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9684D12875B for ; Mon, 28 Jan 2019 17:42:13 -0800 (PST) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0T1gBL5087344 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 28 Jan 2019 19:42:12 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1548726133; bh=8c08BPF4mqj3+Zpq55u4SxwQ/UFxPft08YYynzQFwYQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=RxJWDRyNHiM8IMe44q4UqHmC0H7l1weiqqk0w/ZVZ8edlDSBuPRX1WzbGQ4+bX0Fo HlI6U1wx8DpYaVvderMqB8cRHaA9u3ZMf6wb1MG/44UlZMLct+O6p+yjCu9Q6U0++j DD3FR3shDrn2WDOAVLZwlyrRfx675SeE7MG4CDCY= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Eric Rescorla Cc: RTCWeb IETF References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <937eade0-f126-472a-d990-aa4b65ea5a82@nostrum.com> From: Adam Roach Message-ID: <8f0f5425-96cd-3398-fb0a-c52b8820aaf2@nostrum.com> Date: Mon, 28 Jan 2019 19:42:05 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0E3CC5E571140F0112DAE5B6" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 01:42:15 -0000 This is a multi-part message in MIME format. --------------0E3CC5E571140F0112DAE5B6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 1/28/19 7:24 PM, Eric Rescorla wrote: > > > On Mon, Jan 28, 2019 at 5:10 PM Adam Roach > wrote: > > [as an individual] > > On 1/28/19 6:55 PM, Eric Rescorla wrote: > > it's unnecessary complexity > > > To make sure we're not all overlooking something that is obvious > to you > -- can you describe the complexity involved here? > > > Having to condition what you put in the proto line depending on the > candidates is more complexity than not having to do so. Thanks. I think we're all on the same page regarding complexity. /a --------------0E3CC5E571140F0112DAE5B6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 1/28/19 7:24 PM, Eric Rescorla wrote:


On Mon, Jan 28, 2019 at 5:10 PM Adam Roach <adam@nostrum.com> wrote:
[as an individual]

On 1/28/19 6:55 PM, Eric Rescorla wrote:
> it's unnecessary complexity


To make sure we're not all overlooking something that is obvious to you
-- can you describe the complexity involved here?

Having to condition what you put in the proto line depending on the candidates is more complexity than not having to do so.


Thanks. I think we're all on the same page regarding complexity.

/a

--------------0E3CC5E571140F0112DAE5B6-- From nobody Mon Jan 28 18:05:51 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8373130E86 for ; Mon, 28 Jan 2019 18:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMdFKudFefP3 for ; Mon, 28 Jan 2019 18:05:48 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8942812875B for ; Mon, 28 Jan 2019 18:05:48 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id 32so16515730ota.12 for ; Mon, 28 Jan 2019 18:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=repl7NYjzM7w3vlvBNglrnu2eHzAOEDUXpd8nf2Dya4=; b=T6oRz1xtuOOJQxAbivB5OP1speIo2To3nJuO1FJy73upNkrcmoIi3D9uPbo/N959qc j8zP5I+a+LE3Moyzb+bHLA4kHwzfw8bQQ2kz01f9g1cKnMsjzV0aQpPEHyAPa3vXBHOZ wcyG06+wkYXYDAI13gvcOhhSp6Fgrf4/p4FG1SQJAOQbQ83464m6Ht/Q3pJzYytZGMzA MOhXPGdQV541RWKL41dGV0oguTp/FYBjaS3ujciYwYWLDRlaF2we6jqj7ccp9NHIH5aj IPUGLAZTMWh0LTVR3E0jVOJV7Y2DGIASWy7RNLmCBMWs7mCf8zqdWwGOPLo4NzJQbTiO JKaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=repl7NYjzM7w3vlvBNglrnu2eHzAOEDUXpd8nf2Dya4=; b=kjzDZlWiyHSJ0xXCKbVWD4A9VwWdo1GUlIhg5XKQyW4NYfF+2f2ROy+APu7gIY/v4X iRz8IkoU3ZyceAuuiNRdDd0UFQKh0DH+IL93g8+kQuqiNGrOOJzf3j+bbvgx44HqW4zN WFBkK4mB0luNP3IS1rhrxE4hT2yxWjRaaO/mDZjMpcKxF923lDiJSvaQsUPNDi7MyO1V 4Lniu4YJ5ZTnAkDddq8OwVQZLiHT0VmUzHgoD8CCjK0q0y5uvvmkbUG2znqeLxAuhhA4 H3cx4lbdxdt5L4TVVj1JCliMNY47HbKt+GJeJjjPOlw1KY0dtHJJUrcpCWwyW8q+mvh7 xgQw== X-Gm-Message-State: AJcUukfLC0KGiZTgPEZyZw7macfZxBuALwT22QDdTozpIyoLc5MdjxbV nuGbk/JlepkrRhCVdzqtpCwH2uqRTdb+R/mH8YU= X-Google-Smtp-Source: ALg8bN46Uz/zH6LKfiO2qqr2X9/LZ7dGf5OejFYFc2G0fS2obhGWJHw2NQINJC4617ezQru/KzGIDGPVpToX6JWdVzs= X-Received: by 2002:a9d:738a:: with SMTP id j10mr18553003otk.188.1548727547664; Mon, 28 Jan 2019 18:05:47 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> In-Reply-To: From: Ted Hardie Date: Tue, 29 Jan 2019 11:05:22 +0900 Message-ID: To: Eric Rescorla Cc: Justin Uberti , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000551d1405808f3bb2" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 02:05:50 -0000 --000000000000551d1405808f3bb2 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 29, 2019 at 10:24 AM Eric Rescorla wrote: > > No, that's not what I said. What I said was "A system with substantial > deployment that works properly with WebRTC if the default candidates are > UDP but not when the default candidates are TCP and the proto is UDP/foo" > When we call for consensus, we will take this into account. My current plan is to discuss the timing with Sean tomorrow (Japan time) and call for consensus by the end of the week, with the usual time frames. Ted > --000000000000551d1405808f3bb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 29, 2019 at 10:24 AM Eric Res= corla <ekr@rtfm.com> wrote:

No, that's not what I said. What I said was "A = system with substantial deployment that works properly with WebRTC if=20 the default candidates are UDP but not when the default candidates are=20 TCP and the proto is UDP/foo"

<= /div>
=C2=A0When we call for consensus, we will t= ake this into account.=C2=A0

My current plan is to discuss the timing with S= ean tomorrow (Japan time) and call for consensus by the end of the week, wi= th the usual time frames.

Ted
--000000000000551d1405808f3bb2-- From nobody Tue Jan 29 01:10:39 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C486130F3C for ; Tue, 29 Jan 2019 01:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WB25vXrbIets for ; Tue, 29 Jan 2019 01:10:35 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8723130F3B for ; Tue, 29 Jan 2019 01:10:35 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id t13so8471198pgr.11 for ; Tue, 29 Jan 2019 01:10:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5qCnFdLEHeOsxAWj7rs2ip3E/6p2aObxNnABayaaiqI=; b=vfk3qlJ8+LW+JNj3zCV88xwvdoT9M3leAEewSmX+K8DCX27kPSFYsBIxPDFp+GD9hM 6oUS60jRgHGwH8paDsNEzxM3K5d2bs3mN26dYAyb/8ATwRfwtNGf/vdHbYsob/0DiUF4 6+yxMae13u4FFVvbqvFYZiCVoqrFtEbMxJElsyEYvHg4SzV9Wp3Zn6TYOW0UVN5LqDYk xaJh1IF5c5mp2Wpnm8KtODx120Pqc0agti3H64KLZ8HEFBYWq+Y5FZ0GzDutafRRcJAm O2IqNupfjb5eCP8aWVfPvqnd8bCQJsWhmpodLwbKKSP55rujJgc/JD9BYADVsXHyBFb1 ny3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5qCnFdLEHeOsxAWj7rs2ip3E/6p2aObxNnABayaaiqI=; b=bluHTnX7ea0W4UPehUhBkbrsQdfUa7beOrUMa5y77rXCVSks9fuobRm6v3+X/Ww19p w4T6mfizj7JQlzL2lpMmdhZST61nN3A2F5U9+8oFFNS0DwlhOjlYkPbcc3rmfAt2tXWx RESs+qr+lBZFjQ8z/SysILXyzxsWcqtJvlPNur0LsNEKwKAm6nNRlBcxxQdvjjW7EQ20 okYGKdsS7wCFpF3VmyE49nM29tz8OU84Md8qMFGkU2dQYSuRjQQ3chZHfaG8soiasm2s Gz3maOuKwJiGM9ESCI+rBtIo99HjfI/p8wvib2KFYy7OmX8VIkYtsahinczfiqekkyMy +uDA== X-Gm-Message-State: AJcUukdFRFe30ir1ljkN9BQKQqvsuKyWuz64p/tY6U4+tH5oYhzhUTQF 8ngJgjd8HPOnDE8XVHJnnNnlBUHBK7U= X-Google-Smtp-Source: ALg8bN4RaFweOmj3gh0Mbt8sEITLw/+/rV9yGvpeMEyX/JQ2rrwQiQK/riM096+kEymIns8LDJHR1A== X-Received: by 2002:a62:a99:: with SMTP id 25mr24976605pfk.121.1548753034544; Tue, 29 Jan 2019 01:10:34 -0800 (PST) Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com. [209.85.210.173]) by smtp.gmail.com with ESMTPSA id t87sm54056522pfk.122.2019.01.29.01.10.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 01:10:33 -0800 (PST) Received: by mail-pf1-f173.google.com with SMTP id i12so9375590pfo.7 for ; Tue, 29 Jan 2019 01:10:33 -0800 (PST) X-Received: by 2002:a62:9fcf:: with SMTP id v76mr25054229pfk.144.1548753033482; Tue, 29 Jan 2019 01:10:33 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> In-Reply-To: From: Roman Shpount Date: Tue, 29 Jan 2019 04:10:21 -0500 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: Ted Hardie , RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000067d96e0580952a17" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 09:10:37 -0000 --00000000000067d96e0580952a17 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=C3=B1aki, Please consider the following: 1. Browser client is placed behind the firewall which only allows TCP connections 2. No TURN servers are configured 3. Client establishes connection to a server which supports ICE TCP 4. ICE nomination completes 5. Client browser app calls createOffer with no options (ICE restart option is not present) Based on the current set of specifications, in this case ICE nomination is complete and the TCP candidate is nominated. No other candidates should be present in the offer. Roman Shpount --00000000000067d96e0580952a17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I=C3=B1aki,

= Please consider the following:

1. Browser client is placed behind the firewall which only allows TC= P connections

2. No TURN servers are configured

3. Client establishes connection to a server which supp= orts ICE TCP

4. ICE nomi= nation completes

5. Clie= nt browser app calls createOffer with no options (ICE restart option is not= present)

Based on the c= urrent set of specifications, in this case ICE nomination is complete and t= he TCP candidate is nominated. No other candidates should be present in the= offer.

Roman= Shpount
--00000000000067d96e0580952a17-- From nobody Tue Jan 29 04:03:00 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E1612D4E8 for ; Tue, 29 Jan 2019 04:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3l0iqNEqRAHW for ; Tue, 29 Jan 2019 04:02:56 -0800 (PST) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D25BE12DD85 for ; Tue, 29 Jan 2019 04:02:55 -0800 (PST) Received: by mail-vs1-xe36.google.com with SMTP id t17so11764826vsc.8 for ; Tue, 29 Jan 2019 04:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/dVDN+tJKYX/hgXHerX5ZTL0KqUMK8HTI+vcPcgYNlo=; b=sr8uokGnlAbcPrJgPLvpe6jauD9iz6ZVoSkeb+G8YdV48g740F3dWRnl/HgL6kixqO lI000HVWaKo0WPU9MCd118p5ciMP4txgpLLa01aQowo6mcVqEU+SPKCwuONW/T+1KnyU fWTDjNfTp3FgKs/ffZK741iyorGTnZzxNXaHne3XYz95aDzjNNsZLKyryuqjK3rOMKFt 2htJBFkMjGhjyW2ME70qqFzaanBziO6tjDcYQ2RJS6MrzqocvpQNL35+3c9+8Ex5CNlY L1845kLvY3rWr0LsIhntGTTHQnxvfm4Tr06s6TMFueezcVA+tAqmPSdvDefaFdBmYTIr 1zNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/dVDN+tJKYX/hgXHerX5ZTL0KqUMK8HTI+vcPcgYNlo=; b=axE3F2zXAepYKHNTESBlmcqqlLLUu6aYzDJItaLiNiP5Y/zlz7PEQTxfMKiMkPUjza uezt+qmNcbBDnvHuz6XSVWVofYALgnZahfnvVbauidjYPChGSof14mnLZt5j4F1qRkxQ qn4PFgkyrkYcdtGUqTtWrPQnvpi1yhPsOFmE4vIy+rpHUy6RHS8ahxbFzwBGhBKmm9pr gB4/jdZT+Oo+XRs4slpt50RPjl+jyQIEYFAxatEMe0r2pV8rO63UQunBRnFaDuFsiEmH 1cLo/LQ9WO8AYmO0/AmNDWWitVgx1XKpNH0yECua3VYRfUqdG3txRVGCUIaldrZtyf1d wGgw== X-Gm-Message-State: AJcUukdTOr4v+BJOejQLtdz7nYt5wevK82dDCaq3bisV3KJOo4Mjzqr1 mxhzXWy8Qa2Lzim4UjMQGHjVun37/pkdXJvyFeFTmA== X-Google-Smtp-Source: ALg8bN6Ptj1+IOaV1wAwlrPoNHalWYq+MqZXxQQw5o6EenwdKEgqNNaaPgobDZPbCt1dTcwfZo4O7TthrPSGd6Ow8fQ= X-Received: by 2002:a67:3edc:: with SMTP id a89mr10429454vsi.136.1548763374726; Tue, 29 Jan 2019 04:02:54 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 29 Jan 2019 13:02:43 +0100 Message-ID: To: Roman Shpount Cc: Ted Hardie , rtcweb@ietf.org Content-Type: multipart/alternative; boundary="000000000000cabd450580979243" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 12:02:58 -0000 --000000000000cabd450580979243 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Roman. In SIP world (and in many others) 5 will happen before 3, so I don't understand. Do I miss something? El mar., 29 ene. 2019 10:10, Roman Shpount escribi=C3= =B3: > I=C3=B1aki, > > Please consider the following: > > 1. Browser client is placed behind the firewall which only allows TCP > connections > > 2. No TURN servers are configured > > 3. Client establishes connection to a server which supports ICE TCP > > 4. ICE nomination completes > > 5. Client browser app calls createOffer with no options (ICE restart > option is not present) > > Based on the current set of specifications, in this case ICE nomination i= s > complete and the TCP candidate is nominated. No other candidates should b= e > present in the offer. > > Roman Shpount > --000000000000cabd450580979243 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Roman.

I= n SIP world (and in many others) 5 will happen before 3, so I don't und= erstand. Do I miss something?

El mar., 29 ene. 2019 10:10, Roman Shpount <roman@telurix.com> escribi=C3=B3:
I=C3=B1aki,

Please consider the following:

1. Browser client is placed behind th= e firewall which only allows TCP connections

2. No TURN servers are configured

3. Client establishes conn= ection to a server which supports ICE TCP

=
4. ICE nomination completes

5. Client browser app calls createOffer with no optio= ns (ICE restart option is not present)

Based on the current set of specifications, in this case ICE= nomination is complete and the TCP candidate is nominated. No other candid= ates should be present in the offer.

Roman Shpount
--000000000000cabd450580979243-- From nobody Tue Jan 29 05:36:32 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBE1124408 for ; Tue, 29 Jan 2019 05:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikdEzXbaxhte for ; Tue, 29 Jan 2019 05:36:28 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343D71200D7 for ; Tue, 29 Jan 2019 05:36:28 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id n2so8764401pgm.3 for ; Tue, 29 Jan 2019 05:36:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9ExgYsMkyfs2qGjR/5rRrWGw4LS6yvNBqXHtio/HgXo=; b=CaodpApa3iWC45XAqfVqjVoNNYn7P1zk+FQLllDmCqHw9r0++i2k5glFUT0m5ALo/A sycia1vcxqnpaAZzVmX9+JSvRbEFIZiu9li5k48/Qn/m7CEvXS8Z7dNBUDWYl2wrpEYY TAt5xZMgah4/myua9AKvKcn4GHW7sSEFitJ77GH9oAtE627XNokLMzvCToQLR4bo1Hro mhyYoqHmMgFzd3eaKsWSM/ytF0KybltZ8Oi+Gf8e7BAKQteGqTcWJr9Ei4g7FzliE37p t6V2gBuunJh/be8xtGID9Gj9GrqrCqRZPV/HSaOA4X6ZnLHFLpSrOb7h6Tj5F6zDKTnU dWcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9ExgYsMkyfs2qGjR/5rRrWGw4LS6yvNBqXHtio/HgXo=; b=Ivq5r7mmJjvAeAmkQNAmU6R0UDIbFl8LYhogF2UXNY9RLgeH9fgy2uHlOd4g/PqBzw A33Mpzs6jEC9zgsH20OXsQtcTNr4y0HrIooK87afGRIsx6hYPxyWs8JUXzr9m5uTBgZm EDPW/CKbWSmOixUX8R0AdEIEfDnL/FVvn4eFqFpTl1neGVfApaTFqBm9ploYalgAirjN FHoAhrRHdooGt/nvT9AGBzIKSuvg5ofq0jHJ2vXVZp6Ptx3I8+KVTU/5WAoa6vMLMu5f FQi+RQUP6no211gy0+YC2+us3Cf9So6DGIpPiuELrYv3S3wufx8XVfRF6CUsAaHZiXNd VCfg== X-Gm-Message-State: AJcUuke8BuwvjWvsI46mhlfY/IjO+qMx400+tebWniYcm5DlE5tHUTa6 r3lb+1YrKuYhSl4Qbvv65sepEG1Qn9A= X-Google-Smtp-Source: ALg8bN7dUPU5XqkM63VoNECMKcvrhqH7FKEpmcwP9Yz4Ztm3CAAf2DuBWm8BSCzIBnksRDSfK2fEOw== X-Received: by 2002:a62:c302:: with SMTP id v2mr26452616pfg.155.1548768986969; Tue, 29 Jan 2019 05:36:26 -0800 (PST) Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com. [209.85.214.181]) by smtp.gmail.com with ESMTPSA id l184sm48350295pfc.112.2019.01.29.05.36.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 05:36:26 -0800 (PST) Received: by mail-pl1-f181.google.com with SMTP id b5so9350493plr.4 for ; Tue, 29 Jan 2019 05:36:26 -0800 (PST) X-Received: by 2002:a17:902:2f03:: with SMTP id s3mr25511025plb.277.1548768985749; Tue, 29 Jan 2019 05:36:25 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> In-Reply-To: From: Roman Shpount Date: Tue, 29 Jan 2019 08:36:13 -0500 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: Ted Hardie , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000003c1fa1058098e1ec" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 13:36:30 -0000 --0000000000003c1fa1058098e1ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 1-4 are for initial connection. 5 is for the new offer. It can be a "fix up" offer or simply an offer which happened not to change transport parameters and is simply adding a codec. I can write this up in more detail if you need. Roman Shpount On Tue, Jan 29, 2019, 7:02 AM I=C3=B1aki Baz Castillo Hi, Roman. > > In SIP world (and in many others) 5 will happen before 3, so I don't > understand. Do I miss something? > > El mar., 29 ene. 2019 10:10, Roman Shpount escribi=C3= =B3: > >> I=C3=B1aki, >> >> Please consider the following: >> >> 1. Browser client is placed behind the firewall which only allows TCP >> connections >> >> 2. No TURN servers are configured >> >> 3. Client establishes connection to a server which supports ICE TCP >> >> 4. ICE nomination completes >> >> 5. Client browser app calls createOffer with no options (ICE restart >> option is not present) >> >> Based on the current set of specifications, in this case ICE nomination >> is complete and the TCP candidate is nominated. No other candidates shou= ld >> be present in the offer. >> >> Roman Shpount >> > --0000000000003c1fa1058098e1ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
1-4 are for initial connection. 5 is for the new off= er. It can be a "fix up" offer or simply an offer which happened = not to change transport parameters and is simply adding a codec.

I can write this up in more detail= if you need.

R= oman Shpount

On Tue, Jan 29, 2019, 7:02 AM I=C3=B1aki Baz Castillo <ibc@aliax.net wrote:
Hi, Roman.

In SIP world (and in many others) 5 will happen before 3, so I do= n't understand. Do I miss something?

El mar., 29 ene. 2019 10:10, Roman Shpount <roma= n@telurix.com> escribi=C3=B3:
I=C3=B1aki,

Please consider the following:

1. Browser client is placed behind the firewall which only allows= TCP connections

2. No TURN servers are configured

3. Client establishes connection to a server which sup= ports ICE TCP

4. ICE nom= ination completes

5. Cli= ent browser app calls createOffer with no options (ICE restart option is no= t present)

Based on the = current set of specifications, in this case ICE nomination is complete and = the TCP candidate is nominated. No other candidates should be present in th= e offer.

Roma= n Shpount
--0000000000003c1fa1058098e1ec-- From nobody Tue Jan 29 09:46:19 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDC6130EA2 for ; Tue, 29 Jan 2019 09:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4eL8ziQ34-4 for ; Tue, 29 Jan 2019 09:46:14 -0800 (PST) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B11130E58 for ; Tue, 29 Jan 2019 09:46:14 -0800 (PST) Received: by mail-pl1-x62c.google.com with SMTP id w4so9690770plz.1 for ; Tue, 29 Jan 2019 09:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Hj4Btkwr8/VKeKJoPDspFyOtJX/4wwsZ6EuzgfwTXdc=; b=HXhlP1OBIDiJArDRrKB7zrMixWdaer48cvK+xNzkYQSL3Xm2fz5axlYrHA7C3Oxq9E HL/tUn8HyJo0d6w7bcrz88w69ljgzSJryRcdqu4NHBcSVDYYx8KbGF9iqMFdIL1b6sXa ORXBGr8LJBwc2VFf5J81QPcvN3q+CX8X/d0d0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Hj4Btkwr8/VKeKJoPDspFyOtJX/4wwsZ6EuzgfwTXdc=; b=Xdq9ypJ9+vfeqZcjyLk3n1cTViOh8CtaAzkgo5RjGWVZu3j+obxSCv9SfFw0b5M/Rk PcgJ2hk+EV+abjSZ7p9S+590MfK0muENQszDgeO3nXrRlKJ6Vh/9dOlqbaoEfNzkHJqQ /wcz6RUKd6WHeUlI1HidV4a4GB3Rx+xYjr7Sfr+nd8K4hqta0w0KaZ79hD2vQNjmSP9m NuPENLhvyhAFPCdQHb+oiYsqLpFP1yf2MYHyn0w/9VvjTAWXPgYTAuYdrrpKgJ/9Z+mr QMTsXXtnj4Ja+0U5Cxj9evAEsJ1Lq0zKrX5eNJ4ESYFpkIFoH9qZnnYKcefFLT9NwGf0 3INA== X-Gm-Message-State: AJcUukc/cjEZvIuIS0iplLuahuoblxFgY9xbHRw7FOnabupfRxWbP32+ 685MnI7gtZ3SiSgIPsuqdlkfvd66JJGuWQs4 X-Google-Smtp-Source: ALg8bN5rlApkCOw40+Dq+lniWC88wJA0HAL1nyTuFqL84GTDPYnyMBHIXE3nmaSrZJiBr1gpltETuQ== X-Received: by 2002:a17:902:f20d:: with SMTP id gn13mr25838377plb.11.1548783973556; Tue, 29 Jan 2019 09:46:13 -0800 (PST) Received: from ?IPv6:2620:101:80fc:224:b94e:c0f3:356d:3836? ([2620:101:80fc:224:b94e:c0f3:356d:3836]) by smtp.gmail.com with ESMTPSA id b10sm52207939pfj.183.2019.01.29.09.46.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 09:46:12 -0800 (PST) From: Nils Ohlmeier Message-Id: <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_35885C8D-5726-4C56-AC09-8B1C17A445AC" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 29 Jan 2019 09:46:10 -0800 In-Reply-To: Cc: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= , RTCWeb IETF To: Roman Shpount References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 17:46:17 -0000 --Apple-Mail=_35885C8D-5726-4C56-AC09-8B1C17A445AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 What I don=E2=80=99t quite understand here: 1-4 with the initial = connection will use UDP in the protocol field. Only the subsequent = re-offer from step 5 on would use TCP in the protocol field. How come = that 1-4 works, but 5 does not? Best Nils Ohlmeier > On 29Jan, 2019, at 05:36, Roman Shpount wrote: >=20 > 1-4 are for initial connection. 5 is for the new offer. It can be a = "fix up" offer or simply an offer which happened not to change transport = parameters and is simply adding a codec. >=20 > I can write this up in more detail if you need. >=20 > Roman Shpount >=20 > On Tue, Jan 29, 2019, 7:02 AM I=C3=B1aki Baz Castillo wrote: > Hi, Roman. >=20 > In SIP world (and in many others) 5 will happen before 3, so I don't = understand. Do I miss something? >=20 > El mar., 29 ene. 2019 10:10, Roman Shpount > escribi=C3=B3: > I=C3=B1aki, >=20 > Please consider the following: >=20 > 1. Browser client is placed behind the firewall which only allows TCP = connections >=20 > 2. No TURN servers are configured >=20 > 3. Client establishes connection to a server which supports ICE TCP >=20 > 4. ICE nomination completes >=20 > 5. Client browser app calls createOffer with no options (ICE restart = option is not present) >=20 > Based on the current set of specifications, in this case ICE = nomination is complete and the TCP candidate is nominated. No other = candidates should be present in the offer. >=20 > Roman Shpount > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_35885C8D-5726-4C56-AC09-8B1C17A445AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 What = I don=E2=80=99t quite understand here: 1-4 with the initial connection = will use UDP in the protocol field. Only the subsequent re-offer from = step 5 on would use TCP in the protocol field. How come that 1-4 works, = but 5 does not?

Best
  Nils Ohlmeier

On 29Jan, 2019, at 05:36, Roman Shpount <roman@telurix.com> = wrote:

1-4 are for initial connection. = 5 is for the new offer. It can be a "fix up" offer or simply an offer = which happened not to change transport parameters and is simply adding a = codec.

I can write this up in more detail if you = need.

Roman Shpount

On Tue, = Jan 29, 2019, 7:02 AM I=C3=B1aki Baz Castillo <ibc@aliax.net wrote:
Hi, Roman.

In SIP world (and in many = others) 5 will happen before 3, so I don't understand. Do I miss = something?

El mar., 29 ene. 2019 10:10, Roman Shpount <roman@telurix.com> escribi=C3=B3:
I=C3=B1aki,

Please consider the = following:

1. Browser client is placed behind the firewall = which only allows TCP connections

2. No TURN servers are configured

3. Client = establishes connection to a server which supports ICE TCP

4. ICE nomination completes

5. Client = browser app calls createOffer with no options (ICE restart option is not = present)

Based on the current set of specifications, in = this case ICE nomination is complete and the TCP candidate is nominated. = No other candidates should be present in the offer.

Roman Shpount
_______________________________________________
rtcweb = mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

= --Apple-Mail=_35885C8D-5726-4C56-AC09-8B1C17A445AC-- From nobody Tue Jan 29 09:51:05 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2680130EAC for ; Tue, 29 Jan 2019 09:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQcrOCOzC7d1 for ; Tue, 29 Jan 2019 09:51:01 -0800 (PST) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03CE130E6E for ; Tue, 29 Jan 2019 09:51:00 -0800 (PST) Received: by mail-vs1-xe2d.google.com with SMTP id n13so12509049vsk.4 for ; Tue, 29 Jan 2019 09:51:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HwInYInx7tTdOcd8enOnPDHPZ0G+IugjGUWvUwvgfOY=; b=VAFxqOoiz6VcOnMG/GTrg0GiNZDE+14p6LDtUFGdHJDBRcpo3opLyzY+NRrLs+RYYH S+Ht/zWed7CRxr6boVVuwHw2+nDr7z6GRyIP/nG0PIyOC0N9hPLidWXUCFN5ENkRv2F2 qH5lY9mLqvSui7YQQiRSYWRRT3Q3iDHJjlHxXEDR1Lbop/S8uFo7kxxcE0Rk9syCVZwB PxsnPyfxftha2m2U6G1XPnpDa1DjnxG8ci8TAqImYmFSiIXVCaYTfWNzIo8g9W0mknOW 8qqBj1afc82MdCj0qrbj8PD30kL55GLLXZ/bBiODq+8siAzVMk14fFsLg5ZrrjXQFYFx kpXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HwInYInx7tTdOcd8enOnPDHPZ0G+IugjGUWvUwvgfOY=; b=M0k8ZRnjWi0Gfhx3h7ZpxuemBxKdF2iO5YzpQ1MtCsbImUKrMjbnaUEbi2u7QMuK4k ZoDIWZsBFeKAL7NECtpS8sOo/Kat/A4AuYJpb1HHxs+PZmScfVF1hFw7qk/N6hUVodEz CnHIrQjvp2QGw04GKvHCCLTPxdjoEP0CAeFJSBIblAeByDym31o6KncyDdi8xrEr8HYY vP9decmqqclekUnC99l+OHSHlZuKT1J0/PQpCbH/t7IYIGK5MxzekLGqCMIq27+wgO9H XfSIYEjr1FSTYWEpQnnLeezq7E9LdSCSNvWmJgiHB1NgOs747URkRU/IU7vLFw9dyWTD jlKQ== X-Gm-Message-State: AJcUukdqjVps5RSM2qoY+G78KxEH6vypI0+wVFsyjbWJjW1hD6lighRq nICTgHHo86VCPaD1ZLpeUJtjaxUzzZ3Ot1i+HW1TOQ== X-Google-Smtp-Source: ALg8bN4JboIdqhoKnpOlaJIqTF+4TLLH8jZy/EqfN5RfGMUlJ7x1BFICYGfiZxYDQcg8nxZ2XQfToVfncU4ONvcub/Y= X-Received: by 2002:a67:3edc:: with SMTP id a89mr10959467vsi.136.1548784259739; Tue, 29 Jan 2019 09:50:59 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com> In-Reply-To: <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 29 Jan 2019 18:50:48 +0100 Message-ID: To: Nils Ohlmeier Cc: Roman Shpount , RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 17:51:04 -0000 On Tue, 29 Jan 2019 at 18:46, Nils Ohlmeier wrote: > > What I don=E2=80=99t quite understand here: 1-4 with the initial connecti= on will use UDP in the protocol field. Only the subsequent re-offer from st= ep 5 on would use TCP in the protocol field. How come that 1-4 works, but 5= does not? The sysadmin realized about dangerous and suspicious UDP traffic so changed the firewall rules. He also blocked ICMP (for security!!!) but that's not a problem because static constexpr uint16_t MTU =3D 1200. --=20 I=C3=B1aki Baz Castillo From nobody Tue Jan 29 10:05:58 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D119D130F3B for ; Tue, 29 Jan 2019 10:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6RpfEYFg_6X for ; Tue, 29 Jan 2019 10:05:53 -0800 (PST) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875CC130EC9 for ; Tue, 29 Jan 2019 10:05:53 -0800 (PST) Received: by mail-pf1-x42f.google.com with SMTP id b85so10029767pfc.3 for ; Tue, 29 Jan 2019 10:05:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JcgcPXnyVtclB+5zevpqQ+UXCO5HjbbxSMnMDBJ83ns=; b=A1c5vEk0yXK8EclUtzM4LdJkgnvQ1mJ5pqbA+vewsoE629+6GLialn6LECjUIbqRpw zfZz5f5/SpPTs2oqsds351gP+KT9qQYWlwXs4ttELZ8Q4Cwpwj/w4X97S3/agbZpy2Om hFQCikqibWknB9zQqW+c78K02Qbg6gkaQbnyHTPRmzH7Vc9rQakd0CejmlSGoMA1QHpY anWm08DfVU9IqIq2gXmFO74tckXlheEr4PGy+69Y3M2re3+TGDckfXeaXcO/ND3qB/HT CIezSZY9r3rE5hZkm1D4WNjwwvUSX5C2Sic+mwBlqCORHMRCT53KcAlu5JLzJCGZG5+F ycog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JcgcPXnyVtclB+5zevpqQ+UXCO5HjbbxSMnMDBJ83ns=; b=hVRrB5lxPRvfTX9f4HKK9gB9/+uN/ziegI5UcpSuidNfwnCy7ynMrcgcchgG8KkOsN ufWYe/BOOeOOcozY3PMLSmPhpLPBBWclC6yPCKqw+GC3t3CNcNq8c3gUjmWL5aD4GAxo 5TBtvT00LCPC4zAHrCNoPZ6tOXHgsbZo5eVQpiksPcPJUf5qkcVS1N5G/SEUVrBZNa3e wK/78hqMKrp8EM5S8ZiwEuAV2/ttHxE7KHx0oX+gzqvsOkfQcU88T16mTKUrPb9HeePI fOCfGXKnhcIWlabP3Hwi1nTho06PQgYfL0rrBAM0iq96xqXezvh1D+ie229kqzZz+6kh dBFA== X-Gm-Message-State: AJcUukdZgHsxSvb/l/gWpXIt2M/ntesh2ZOx9rzlyKafSDRujwambpM3 cvP871eZFpYrlz5opI8A/wV56pbIG0g= X-Google-Smtp-Source: ALg8bN7KWDGiXrwA2tF3eB9axx+emq0W5Hj0JpwM01gUqGu4AZVs/zDmJxn+gQjUz5v9d+3JKyMQJA== X-Received: by 2002:a63:dd15:: with SMTP id t21mr23554723pgg.347.1548785152711; Tue, 29 Jan 2019 10:05:52 -0800 (PST) Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com. [209.85.214.180]) by smtp.gmail.com with ESMTPSA id y6sm42421504pfl.187.2019.01.29.10.05.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 10:05:51 -0800 (PST) Received: by mail-pl1-f180.google.com with SMTP id u6so9692154plm.8 for ; Tue, 29 Jan 2019 10:05:51 -0800 (PST) X-Received: by 2002:a17:902:8b88:: with SMTP id ay8mr27404846plb.55.1548785151426; Tue, 29 Jan 2019 10:05:51 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com> In-Reply-To: <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com> From: Roman Shpount Date: Tue, 29 Jan 2019 13:05:40 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Nils Ohlmeier Cc: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000c8c4ea05809ca4e7" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 18:05:56 -0000 --000000000000c8c4ea05809ca4e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 29, 2019 at 12:46 PM Nils Ohlmeier wrote: > What I don=E2=80=99t quite understand here: 1-4 with the initial connecti= on will > use UDP in the protocol field. Only the subsequent re-offer from step 5 o= n > would use TCP in the protocol field. How come that 1-4 works, but 5 does > not? > > During steps 1-4, browser client sends an offer which includes both UDP and TCP candidates. It is using one of the UDP candidates as a default candidate in c=3D and m=3D line (proto is UDP/... something). Server, also responds with UDP and TCP candidates. It also uses one of the UDP candidates as a default candidate in c=3D and m=3D line (proto is UDP/... something). Since client location blocks everything except TCP, only the connectivity check for TCP candidate pair succeeds and TCP candidate gets nominated. Once ICE nomination process is completed, new offer is generated from the client without ICE restart (for instance to add a codec or initiate "fix up" offer). This offer must include locally nominated candidate pair and no other candidates ( https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.4.1.= 2.2). This means this offer will only have TCP candidates present. This TCP candidate is the default candidate and will be used in c=3D and m=3D line resulting in TCP/... proto in the m=3D line. There is literally one call scenario here which is affected. TCP candidates should not be used as default candidates or TCP based proto should not be used in the m=3D line in the offer in any other scenario. If you do not understand this scenario, please ask questions before commenting. Thank You, _____________ Roman Shpount --000000000000c8c4ea05809ca4e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 29, 2019 at 12:46 PM Nils Ohlmeier <= nohlmeier@mozilla.com> wrot= e:
What I = don=E2=80=99t quite understand here: 1-4 with the initial connection will u= se UDP in the protocol field. Only the subsequent re-offer from step 5 on w= ould use TCP in the protocol field. How come that 1-4 works, but 5 does not= ?


During steps 1-4, br= owser client sends an offer which includes both UDP and TCP candidates. It = is using one of the UDP candidates as a default candidate in c=3D and m=3D = line (proto is UDP/... something). Server, also responds with UDP and TCP c= andidates. It also uses one of the UDP candidates as a default candidate in= c=3D and m=3D line (proto is UDP/... something). Since client location blo= cks everything except TCP, only the connectivity check for TCP candidate pa= ir succeeds and TCP candidate gets nominated. Once ICE nomination process i= s completed, new offer is generated from the client without ICE restart (fo= r instance to add a codec or initiate "fix up" offer). This offer= must include locally nominated candidate pair and no other candidates (https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#s= ection-3.4.1.2.2). This means this offer will only have TCP candidates = present. This TCP candidate is the default candidate and will be used in c= =3D and m=3D line resulting in TCP/... proto in the m=3D line.
There is literally one call scenario here which is affected. T= CP candidates should not be used as default candidates or TCP based proto s= hould not be used in the m=3D line in the offer in any other scenario.

If you do not understand this scenario, please ask que= stions before commenting.

Thank You,
________= _____
Roman Shpount
= =C2=A0
--000000000000c8c4ea05809ca4e7-- From nobody Tue Jan 29 10:08:14 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38ECB130F3B for ; Tue, 29 Jan 2019 10:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 857mDK2Mc3Ks for ; Tue, 29 Jan 2019 10:08:12 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB0D5130EC9 for ; Tue, 29 Jan 2019 10:08:11 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id s198so9079571pgs.2 for ; Tue, 29 Jan 2019 10:08:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dC9drDbBaRAiIy54RZOqt/Fl+VsGMlI4FilA5LrRP48=; b=n/1TZRXwa05Ks/08hN1h6wcRo4Ibe6BjXnBJeTMi3nmXWWJV+y0vNO9Av5WoF3ajVP ce7+vqpkYCiT29WqDsG/LAnv2165Fa+cEDZhgX+aXcS9wMFGkKq/3n57U3C3o/zVgVDe oiocNa90lsJwQWPdrgzhmWRHHBBNO/Q0ZdEVpD2Ya/eXzjCluEWCVPk8Eju/MX26CpOm t3HNOh/WLOkryWNaw+Wy2oMvpvE3qldkNI0hxDIT296cYRqhx3APzG425BBtTxEy097p ytIrI8DMg4ce6OUe19DeWexQyOtnfKdpGWFfX4LEhgJyZ7Nmd4zsK/cjEnUOV47MEzwq 94dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dC9drDbBaRAiIy54RZOqt/Fl+VsGMlI4FilA5LrRP48=; b=qnX5Wf9TfTKeGTUXxK72vF5yCShe7qBZHi/9RqvO4KZ8PYY2M6J4Gp4GMeRQtW+qCN jg4leXuZhwCpV29Tm0cYXYG7+husRMpktDGK6fRmcEQ/mcLz+rnBA85b5I7JUG9HZjbU IuvQYiDqfU9UR/gaQ1kUTfMwkQ1KfJVrCnJBrbOpQSQuPcaYA2ZktW0F4YXkzP2+h2UL 62rCwPvMxi9dgdGJ0zXWeh789qSq3S3uAr1T/xg/qUgiy2ST8vdqFAd3Cw8Mg6PyuY1Q 9vVjU7SeYqUqRiRPxx82+5gqK+xMNvdpbXNmLg3fQEVxRw6gStDYcxxeDzJfPhvCuv2Q zqjg== X-Gm-Message-State: AJcUukfby6nFFG73UvhOmmt+vY+9VHNxv7uyFRmizCnyYNQ5IlDclGnI 9qqWlyWZmMF/Ir75QdzFuTvwqCZ52MA= X-Google-Smtp-Source: ALg8bN4jcTpX4aBOBtl4kf1+ATmUL8oggS8Cd+9+LYiA88Vsx/8hBPYXghjX/ICEMxwNeKgQoNSwGA== X-Received: by 2002:a63:3602:: with SMTP id d2mr24156414pga.404.1548785291266; Tue, 29 Jan 2019 10:08:11 -0800 (PST) Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com. [209.85.210.172]) by smtp.gmail.com with ESMTPSA id d16sm40583122pgj.21.2019.01.29.10.08.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 10:08:10 -0800 (PST) Received: by mail-pf1-f172.google.com with SMTP id z9so10029159pfi.2 for ; Tue, 29 Jan 2019 10:08:10 -0800 (PST) X-Received: by 2002:a62:160d:: with SMTP id 13mr26993242pfw.203.1548785290242; Tue, 29 Jan 2019 10:08:10 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com> In-Reply-To: From: Roman Shpount Date: Tue, 29 Jan 2019 13:07:59 -0500 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: Nils Ohlmeier , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000000ef16905809cad6b" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 18:08:13 -0000 --0000000000000ef16905809cad6b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 29, 2019 at 12:51 PM I=C3=B1aki Baz Castillo wr= ote: > On Tue, 29 Jan 2019 at 18:46, Nils Ohlmeier wrote= : > > > > What I don=E2=80=99t quite understand here: 1-4 with the initial connec= tion will > use UDP in the protocol field. Only the subsequent re-offer from step 5 o= n > would use TCP in the protocol field. How come that 1-4 works, but 5 does > not? > > The sysadmin realized about dangerous and suspicious UDP traffic so > changed the firewall rules. He also blocked ICMP (for security!!!) but > that's not a problem because static constexpr uint16_t MTU =3D 1200. > > This has absolutely nothing to do whit what we are discussing. _____________ Roman Shpount --0000000000000ef16905809cad6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 29, 2019 at 12:51 PM = I=C3=B1aki Baz Castillo <ibc@aliax.net<= /a>> wrote:
On Tue, 29 Jan 2019 at 18:46, Nils Oh= lmeier <nohlm= eier@mozilla.com> wrote:
>
> What I don=E2=80=99t quite understand here: 1-4 with the initial conne= ction will use UDP in the protocol field. Only the subsequent re-offer from= step 5 on would use TCP in the protocol field. How come that 1-4 works, bu= t 5 does not?

The sysadmin realized about dangerous and suspicious UDP traffic so
changed the firewall rules. He also blocked ICMP (for security!!!) but
that's not a problem because static constexpr uint16_t MTU =3D 1200.

This has absolutely nothing to do whi= t what we are discussing.
_____________
Roman Shpount
=C2=A0
--0000000000000ef16905809cad6b-- From nobody Tue Jan 29 10:33:34 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4306130FB4 for ; Tue, 29 Jan 2019 10:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmZyDVfqKkYh for ; Tue, 29 Jan 2019 10:33:30 -0800 (PST) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86521130FB2 for ; Tue, 29 Jan 2019 10:33:30 -0800 (PST) Received: by mail-ua1-x936.google.com with SMTP id d21so7180819uap.9 for ; Tue, 29 Jan 2019 10:33:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+eC9gKSrMgjVu3rdbPjAhTLlKo4raCVuUdd/rEhkN68=; b=ELIPb1JTgO3wbXTcg9oXD38q77LtLSjtLdI/xIKbdFoCi44l3ZX0XnANocmZdte793 N/nzpJSQUt6quEDrtH+s+pKIl/vqg++8wm1B5hiISna0vxvpb9Yb8ehMCipur3QZmNLN KaIoAlzxlUamrt4a0UIbT3cZJrR3IfnQBJeYpJ1k9uelQ3EdlYhV97449M3wcg4Exjvp wy9yeVHiRzoyhUzjKnW9e2Wx9/RcZd++jL36vzfNK5IdIxofEpD4HVqApCPhU4EFdgGQ qTYIPclsC/X+DL3ajUi/lKgeKW5bpSfpS2pWTILchZomJ2ZwTbYXaK6Wdj0thsUG+u+G kRAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+eC9gKSrMgjVu3rdbPjAhTLlKo4raCVuUdd/rEhkN68=; b=VyNFTksGOc3L1n1bSK35RLICV46yoL13Wf5AuUt+a6eROHga6NgxvntiYLcm/cPhhZ /umQ2RBqij/sf4+ZFIfYJIrm5OAgHIZLOIcQVsH2is06i8aJXAkYUI2exLjX+tM1Ltec pGO58yOLCyiHcnVrQCc6o5spsYZJug6gMecijEEYi4tc8zprtTgs6fG/naFZA6D4xGee 1wV1Qcd8b1LqDTvqDNNgwci3+H6PR7zDeHhCyuI4e9X47MfnTgSqNlwg10/rXANpuMmx oUkOOj9p4ECD84bMYxWKIgM37vFDR/QJyxM1+nd1ec2S5ZhU7IixS5AzqEqMC28DGNnT B8FA== X-Gm-Message-State: AJcUukcHsiL2X33geoQkfxB806zV3aj0uWr6teNrO3+5cs9TmjhJA3qp kDmFUgVv6apBT4R9hefOy/oqWNfYprvo/drB0qMMWGTJ+xk= X-Google-Smtp-Source: ALg8bN4wHZwta71Rp5oKmN+ebpzzYNA+okD8grbqifjA8MgHM8txOUPN5LrjwXfkHwRYuwt4um8NOGNcmJsIIlXSrfU= X-Received: by 2002:ab0:7048:: with SMTP id v8mr11490092ual.84.1548786809394; Tue, 29 Jan 2019 10:33:29 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 29 Jan 2019 19:33:18 +0100 Message-ID: To: Roman Shpount Cc: Nils Ohlmeier , RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 18:33:33 -0000 On Tue, 29 Jan 2019 at 19:05, Roman Shpount wrote: > During steps 1-4, browser client sends an offer which includes both UDP a= nd TCP candidates. It is using one of the UDP candidates as a default candi= date in c=3D and m=3D line (proto is UDP/... something). Server, also respo= nds with UDP and TCP candidates. It also uses one of the UDP candidates as = a default candidate in c=3D and m=3D line (proto is UDP/... something). Sin= ce client location blocks everything except TCP, only the connectivity chec= k for TCP candidate pair succeeds and TCP candidate gets nominated. Once IC= E nomination process is completed, new offer is generated from the client w= ithout ICE restart (for instance to add a codec or initiate "fix up" offer)= . This offer must include locally nominated candidate pair and no other can= didates (https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#secti= on-3.4.1.2.2). This means this offer will only have TCP candidates present.= This TCP candidate is the default candidate and will be used in c=3D and m= =3D line resulting in TCP/... proto in the m=3D line. This is a very good point: > This (re)offer must include locally nominated candidate pair and no other= candidates But how is the draft above useful at all if browsers do not set the selected candidate into c=3D/m=3D lines during a re-offer? Imagine browser do implement the draft above and, indeed, they set "TCP/DTLS/..." in the proto line of the re-offer with just TCP candidates. Assuming that they do NOT set the selected candidate pair in the m=3D/c=3D line, this is just valid to know whether UDP or TCP has been selected, nothing else. Am I wrong? In the other side, and assuming this is about JavaScript SIP+WebRTC clients, wouldn't it work if they mangle the SDP re-offer? By checking the peerconnection stats you can know the selected candidate and so on. --=20 I=C3=B1aki Baz Castillo From nobody Tue Jan 29 10:48:55 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CDC130FB4 for ; Tue, 29 Jan 2019 10:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIJOwD0cC1lp for ; Tue, 29 Jan 2019 10:48:50 -0800 (PST) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2A5130F88 for ; Tue, 29 Jan 2019 10:48:50 -0800 (PST) Received: by mail-pg1-x52a.google.com with SMTP id z11so9135028pgu.0 for ; Tue, 29 Jan 2019 10:48:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WfrGccs8rK1J+wh/ZvBwbVMzQFRNniAwyl/YM5CCgR0=; b=C8bJ9PAIS7SpRrimybwdAqNhtMnEwRmZZhwClOnDJCoM3J6opKBBpHvqUV7SvzMj63 nz5boLpy6bmY4xtqfZVbzSZGwkYCwBI34OT1xn/ViBp2p2kHzzpal5zT/CQNOOMl8n10 Dc82XEPixuCKshpHOstqvcoH2w9O7Ht60BsE51zehAzYLMgriuvLqGJb/CKi5zr0v5Sz BtFn+Tcn80208huAwM4LjaD8Mxh2oLAK8GeLNi1f/DUrx2s9ZV4VxcGpTUFnl4Y89LQj tlRWT8o7eQGnXsoMTl4zK12lqzYsaWaS8ZZ8mkBkcgT9uE/xXsYn/Daf758HRFOSPVfm aFBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WfrGccs8rK1J+wh/ZvBwbVMzQFRNniAwyl/YM5CCgR0=; b=Oydgns/42pV3ZCLAk0Bbe6CGLH4sgQv+pLnznbPauhFqmcqGKyJXrFkHSfCf7DZpxC SXZMkAl0E+JYjH1ptilXkUOsufinSzn4akwx1HWAcQwTSK8BqQ08yBsf/xUKqpdkrejJ XRNoFw5DDL4tScgRU+/VWYiG5OnlgEpJFGILPVbuvuvl3kNvOglrR7buauLRrjKlR/MA 4eWbd3nqmhO6wGzfL94DGW7ELvpcCxmBkeJmdcgrnkKJDTK91Bi/g4klWI/OrRmKypfu PwoYGK+WV1OIzYwD1XiTq07x4QfBQe3TgSnNT3tjM0Ww7822qfKslcnXozZ/0o70HKXY x2wg== X-Gm-Message-State: AJcUukfPre8nrLK9nEwC5tDEtNxciL0p1SHsBejZEWswoicZ7olD85bY qZFjCdvK6kmL9X5fikCgS0yuqSptRLc= X-Google-Smtp-Source: ALg8bN4UoPtDWOen97tjBkn/+zpIPBFPqce+IvtOYu2W3w175qH/HnDzXAH3+7FOnJhs+xDMy7+OxA== X-Received: by 2002:a63:62c4:: with SMTP id w187mr22802293pgb.230.1548787729689; Tue, 29 Jan 2019 10:48:49 -0800 (PST) Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com. [209.85.215.171]) by smtp.gmail.com with ESMTPSA id 202sm47392566pfy.87.2019.01.29.10.48.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 10:48:49 -0800 (PST) Received: by mail-pg1-f171.google.com with SMTP id g189so9120630pgc.5 for ; Tue, 29 Jan 2019 10:48:48 -0800 (PST) X-Received: by 2002:a62:160d:: with SMTP id 13mr27145672pfw.203.1548787728605; Tue, 29 Jan 2019 10:48:48 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com> In-Reply-To: From: Roman Shpount Date: Tue, 29 Jan 2019 13:48:37 -0500 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: Nils Ohlmeier , RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000065696105809d3e4a" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 18:48:53 -0000 --00000000000065696105809d3e4a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 29, 2019 at 1:33 PM I=C3=B1aki Baz Castillo wro= te: > On Tue, 29 Jan 2019 at 19:05, Roman Shpount wrote: > > > During steps 1-4, browser client sends an offer which includes both UDP > and TCP candidates. It is using one of the UDP candidates as a default > candidate in c=3D and m=3D line (proto is UDP/... something). Server, als= o > responds with UDP and TCP candidates. It also uses one of the UDP > candidates as a default candidate in c=3D and m=3D line (proto is UDP/... > something). Since client location blocks everything except TCP, only the > connectivity check for TCP candidate pair succeeds and TCP candidate gets > nominated. Once ICE nomination process is completed, new offer is generat= ed > from the client without ICE restart (for instance to add a codec or > initiate "fix up" offer). This offer must include locally nominated > candidate pair and no other candidates ( > https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.4.= 1.2.2). > This means this offer will only have TCP candidates present. This TCP > candidate is the default candidate and will be used in c=3D and m=3D line > resulting in TCP/... proto in the m=3D line. > > This is a very good point: > > > This (re)offer must include locally nominated candidate pair and no > other candidates > > But how is the draft above useful at all if browsers do not set the > selected candidate into c=3D/m=3D lines during a re-offer? Imagine browse= r > do implement the draft above and, indeed, they set "TCP/DTLS/..." in > the proto line of the re-offer with just TCP candidates. Assuming that > they do NOT set the selected candidate pair in the m=3D/c=3D line, this i= s > just valid to know whether UDP or TCP has been selected, nothing else. > Am I wrong? > One way to interpret JSEP in its current state, that it specifies that address and port in c=3D and m=3D line should be updated to the selected candidate, but proto should always be UDP/..., even if address in c=3D and port in m=3D lines are from the TCP candidate. All I am asking, is if end point updates address c=3D and port in m=3D line, it should update the prot= o to match. In the other side, and assuming this is about JavaScript SIP+WebRTC > clients, wouldn't it work if they mangle the SDP re-offer? By checking > the peerconnection stats you can know the selected candidate and so > on. > > JS SIP + WebRTC clients are one of the issues. For instance, it is possible to build a network using JS SIP clients (jssip works great :), regular VoIP clients that support DTLS-SRTP (for instance something pjsip based), and SBC which support DTLS-SRTP+ICE TCP. All are connected to the SIP-over-WS enabled proxy. CDRs and monitoring are done from proxy using proxy generated CDR and SIP signaling capture using something like SIP Homer. The simplest way to get client connection information is by using "fix-up" offers and extracting data from SIP signaling. It is possible to build a separate monitoring solution for WebRTC clients using stats, but using existing SIP based solutions already works well enough except for bogus info about nominated candidate in c=3D and m=3D lines. Regards, _____________ Roman Shpount --00000000000065696105809d3e4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 29, 2019 at 1:33 PM I= =C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
On Tue, 29 Jan 2019 at 19:05, Roman Sh= pount <roman@telu= rix.com> wrote:

> During steps 1-4, browser client sends an offer which includes both UD= P and TCP candidates. It is using one of the UDP candidates as a default ca= ndidate in c=3D and m=3D line (proto is UDP/... something). Server, also re= sponds with UDP and TCP candidates. It also uses one of the UDP candidates = as a default candidate in c=3D and m=3D line (proto is UDP/... something). = Since client location blocks everything except TCP, only the connectivity c= heck for TCP candidate pair succeeds and TCP candidate gets nominated. Once= ICE nomination process is completed, new offer is generated from the clien= t without ICE restart (for instance to add a codec or initiate "fix up= " offer). This offer must include locally nominated candidate pair and= no other candidates (= https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.4.1.= 2.2). This means this offer will only have TCP candidates present. This= TCP candidate is the default candidate and will be used in c=3D and m=3D l= ine resulting in TCP/... proto in the m=3D line.

This is a very good point:

> This (re)offer must include locally nominated candidate pair and no ot= her candidates

But how is the draft above useful at all if browsers do not set the
selected candidate into c=3D/m=3D lines during a re-offer? Imagine browser<= br> do implement the draft above and, indeed, they set "TCP/DTLS/..."= in
the proto line of the re-offer with just TCP candidates. Assuming that
they do NOT set the selected candidate pair in the m=3D/c=3D line, this is<= br> just valid to know whether UDP or TCP has been selected, nothing else.
Am I wrong?

One way to interpret JSEP i= n its current state, that it specifies that address and port in c=3D and m= =3D line should be updated to the selected candidate, but proto should alwa= ys be UDP/..., even if address in c=3D and port in m=3D lines are from the = TCP candidate. All I am asking, is if end point updates address c=3D and po= rt in m=3D line, it should update the proto to match.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">In the other side, and ass= uming this is about JavaScript SIP+WebRTC
clients, wouldn't it work if they mangle the SDP re-offer? By checking<= br> the peerconnection stats you can know the selected candidate and so
on.


JS SIP=C2=A0+ WebRTC clients ar= e one of the issues. For instance, it is possible to build a network using = JS SIP clients (jssip works great :), regular VoIP clients that support DTL= S-SRTP (for instance something pjsip based), and SBC which support DTLS-SRT= P+ICE TCP. All are connected to the SIP-over-WS enabled proxy. CDRs and mon= itoring are done from proxy using proxy generated CDR and SIP signaling cap= ture using something like SIP Homer. The simplest way to get client connect= ion information is by using "fix-up" offers and extracting data f= rom SIP signaling. It is possible to build a separate monitoring solution f= or WebRTC clients using stats, but using existing SIP based solutions alrea= dy works well enough except for bogus info about nominated candidate in c= =3D and m=3D lines.

Regards,
_____________Roman Shpount
=C2=A0
--00000000000065696105809d3e4a-- From nobody Tue Jan 29 11:05:48 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1F1130FC2 for ; Tue, 29 Jan 2019 11:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-rG7Le_MHlZ for ; Tue, 29 Jan 2019 11:05:44 -0800 (PST) Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C66E130FB8 for ; Tue, 29 Jan 2019 11:05:44 -0800 (PST) Received: by mail-vs1-xe44.google.com with SMTP id t17so12611383vsc.8 for ; Tue, 29 Jan 2019 11:05:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vhrl6tS4JAc/nvjkV/61ONt/BOtRAAD+b8sVamImUyk=; b=TIN/w9bM1eFCWHdyegvihMr1mF/1WFZcxvb5lrMByouwwUBwFOP2MnizCsapu9T3xa tkb2f68KpNTaKqtOi1b6IcUP680Ni2gp0sk87EvZMQ0PNgNHvRJL9RvKLYnVSlE5sgwi mpY3cMGEmrtfuzqSBbadx0OpXouOdWsKTCkptDdhwvNPPXeulYoCgf522z4Z7a8C4FHA 467sSlptUrM6rBBo8WUKjKqBcKU3/Ei0Lxr0ngejQjw/GGKkf0x4qc3lF6WNfrWx+gRt GDO5epQSgadOjO1AxJfiuMw+zUKSYse0AMUbwW2P6TcIRX5KuJbXLRrYxqrr06GMUayi 0bfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vhrl6tS4JAc/nvjkV/61ONt/BOtRAAD+b8sVamImUyk=; b=NMcsu31yYW87WSTpTnoVNdx39AKtEpbRWgQ0aedFutu2aXtgHTX+q6PqRg5VPfrenG eyQBgXr7htbg7syu2iwB0niN3p3S+/AAmnIZNPGcc4TX2nTEaIgxDo1Ltp6WslSOkbxU hIjmr+hn7mDmbnQMWqEYhO6h5gxGLhNiEZYr3TbEtjX1MOnTSYxwnXMlq6I5U9/ZtirN RbBaZdd0iv77ngmgyCsEv3NspNkh2dU3kRpusjL8t5oePCuDsyqpQDjnDBOl6oQ2tc0z BmzQYQFjURcDRxILBKX+WqyD3ZPAN+p3evz38+N1b6aQkmSKucP3vnioJUsCEi2QNneI a6NQ== X-Gm-Message-State: AJcUukfIFTutGHeutHaxHuQLSJOUSbn7eC4CPyV/z68iHW7Fj8OXJtCw g1/59p4z0Z1SKYswtZNacB1s/tSmHMBfX0uRMONZxe2k X-Google-Smtp-Source: ALg8bN4+p5+T7yhdJSEwCrW65DphW5X96NAutZCon4CId/LTZsgcPd8WAbkunntfpfrJXjaP3BW4mEBqq88q1fTTEEY= X-Received: by 2002:a67:3edc:: with SMTP id a89mr11073870vsi.136.1548788743492; Tue, 29 Jan 2019 11:05:43 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 29 Jan 2019 20:05:31 +0100 Message-ID: To: Roman Shpount Cc: nohlmeier@mozilla.com, rtcweb@ietf.org Content-Type: multipart/alternative; boundary="000000000000e368ee05809d7a7e" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 19:05:47 -0000 --000000000000e368ee05809d7a7e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I understand your point. But still I don't understand the purpose of the new draft (set TCP/DTLS/etc in proto line if there are just TCP candidates in the offer). Of course, if browser follow the ICE spec and set the selected candidate in the c/m lines, they must also indicate whether that is over UDP or TCP. The problem here is what such a proto line is intended to mean when there is ICE candidates of UDP and TCP. But ok, let's assume that browser do update c/m lines in the trigger with the selected candidate, and they JUST change the proto line to TCP/DTLS if there are just TCP candidates. Now thing about this scenario: 1) Client initial offer with UDP and TCP candidates. 2) Server answers with both UDP and TCP candidates. 3.1) UDP is selected. Re-offer is created with just UDP candidates (as per spec). 3.2) or TCP is selected. Re-offer is created with just TCP candidates (as per specs). In both 3.1 and 3.2 the "monitoring Node" doesn't need to inspect the proto line. It can just check the protocol (UDP or TCP) of *any* candidate in the offer to know whether UDP or TCP was selected. Am I wrong? El mar., 29 ene. 2019 19:48, Roman Shpount escribi=C3= =B3: > On Tue, Jan 29, 2019 at 1:33 PM I=C3=B1aki Baz Castillo w= rote: > >> On Tue, 29 Jan 2019 at 19:05, Roman Shpount wrote: >> >> > During steps 1-4, browser client sends an offer which includes both UD= P >> and TCP candidates. It is using one of the UDP candidates as a default >> candidate in c=3D and m=3D line (proto is UDP/... something). Server, al= so >> responds with UDP and TCP candidates. It also uses one of the UDP >> candidates as a default candidate in c=3D and m=3D line (proto is UDP/..= . >> something). Since client location blocks everything except TCP, only the >> connectivity check for TCP candidate pair succeeds and TCP candidate get= s >> nominated. Once ICE nomination process is completed, new offer is genera= ted >> from the client without ICE restart (for instance to add a codec or >> initiate "fix up" offer). This offer must include locally nominated >> candidate pair and no other candidates ( >> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.4= .1.2.2). >> This means this offer will only have TCP candidates present. This TCP >> candidate is the default candidate and will be used in c=3D and m=3D lin= e >> resulting in TCP/... proto in the m=3D line. >> >> This is a very good point: >> >> > This (re)offer must include locally nominated candidate pair and no >> other candidates >> >> But how is the draft above useful at all if browsers do not set the >> selected candidate into c=3D/m=3D lines during a re-offer? Imagine brows= er >> do implement the draft above and, indeed, they set "TCP/DTLS/..." in >> the proto line of the re-offer with just TCP candidates. Assuming that >> they do NOT set the selected candidate pair in the m=3D/c=3D line, this = is >> just valid to know whether UDP or TCP has been selected, nothing else. >> Am I wrong? >> > > One way to interpret JSEP in its current state, that it specifies that > address and port in c=3D and m=3D line should be updated to the selected > candidate, but proto should always be UDP/..., even if address in c=3D an= d > port in m=3D lines are from the TCP candidate. All I am asking, is if end > point updates address c=3D and port in m=3D line, it should update the pr= oto to > match. > > In the other side, and assuming this is about JavaScript SIP+WebRTC >> clients, wouldn't it work if they mangle the SDP re-offer? By checking >> the peerconnection stats you can know the selected candidate and so >> on. >> >> > JS SIP + WebRTC clients are one of the issues. For instance, it is > possible to build a network using JS SIP clients (jssip works great :), > regular VoIP clients that support DTLS-SRTP (for instance something pjsip > based), and SBC which support DTLS-SRTP+ICE TCP. All are connected to the > SIP-over-WS enabled proxy. CDRs and monitoring are done from proxy using > proxy generated CDR and SIP signaling capture using something like SIP > Homer. The simplest way to get client connection information is by using > "fix-up" offers and extracting data from SIP signaling. It is possible to > build a separate monitoring solution for WebRTC clients using stats, but > using existing SIP based solutions already works well enough except for > bogus info about nominated candidate in c=3D and m=3D lines. > > Regards, > _____________ > Roman Shpount > > --000000000000e368ee05809d7a7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I understand your point. But still I don't understand= the purpose of the new draft (set TCP/DTLS/etc in proto line if there are = just TCP candidates in the offer).

Of course, if browser follow the ICE spec and set the selected candida= te in the c/m lines, they must also indicate whether that is over UDP or TC= P. The problem here is what such a proto line is intended to mean when ther= e is ICE candidates of UDP and TCP. But ok, let's assume that browser d= o update c/m lines in the trigger with the selected candidate, and they JUS= T change the proto line to TCP/DTLS if there are just TCP candidates. Now t= hing about this scenario:

1) Client initial offer with UDP and TCP candidates.

2) Server answers with both UDP and TCP cand= idates.

3.1) UDP is sele= cted. Re-offer is created with just UDP candidates (as per spec).

3.2) or TCP is selected. Re-offer= is created with just TCP candidates (as per specs).

In both 3.1 and 3.2 the "monitoring Node&= quot; doesn't need to inspect the proto line. It can just check the pro= tocol (UDP or TCP) of *any* candidate in the offer to know whether UDP or T= CP was selected.

Am I wr= ong?

El mar., 29= ene. 2019 19:48, Roman Shpount <ro= man@telurix.com> escribi=C3=B3:
On Tue,= Jan 29, 2019 at 1:33 PM I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote= :
On Tue, 29 Jan 2019 at 19:05, Roman Shpount <rom= an@telurix.com> wrote:

> During steps 1-4, browser client sends an offer which includes both UD= P and TCP candidates. It is using one of the UDP candidates as a default ca= ndidate in c=3D and m=3D line (proto is UDP/... something). Server, also re= sponds with UDP and TCP candidates. It also uses one of the UDP candidates = as a default candidate in c=3D and m=3D line (proto is UDP/... something). = Since client location blocks everything except TCP, only the connectivity c= heck for TCP candidate pair succeeds and TCP candidate gets nominated. Once= ICE nomination process is completed, new offer is generated from the clien= t without ICE restart (for instance to add a codec or initiate "fix up= " offer). This offer must include locally nominated candidate pair and= no other candidates (https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#se= ction-3.4.1.2.2). This means this offer will only have TCP candidates p= resent. This TCP candidate is the default candidate and will be used in c= =3D and m=3D line resulting in TCP/... proto in the m=3D line.

This is a very good point:

> This (re)offer must include locally nominated candidate pair and no ot= her candidates

But how is the draft above useful at all if browsers do not set the
selected candidate into c=3D/m=3D lines during a re-offer? Imagine browser<= br> do implement the draft above and, indeed, they set "TCP/DTLS/..."= in
the proto line of the re-offer with just TCP candidates. Assuming that
they do NOT set the selected candidate pair in the m=3D/c=3D line, this is<= br> just valid to know whether UDP or TCP has been selected, nothing else.
Am I wrong?

One way to interpret JSEP i= n its current state, that it specifies that address and port in c=3D and m= =3D line should be updated to the selected candidate, but proto should alwa= ys be UDP/..., even if address in c=3D and port in m=3D lines are from the = TCP candidate. All I am asking, is if end point updates address c=3D and po= rt in m=3D line, it should update the proto to match.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">In the other side, and ass= uming this is about JavaScript SIP+WebRTC
clients, wouldn't it work if they mangle the SDP re-offer? By checking<= br> the peerconnection stats you can know the selected candidate and so
on.


JS SIP=C2=A0+ WebRTC clients ar= e one of the issues. For instance, it is possible to build a network using = JS SIP clients (jssip works great :), regular VoIP clients that support DTL= S-SRTP (for instance something pjsip based), and SBC which support DTLS-SRT= P+ICE TCP. All are connected to the SIP-over-WS enabled proxy. CDRs and mon= itoring are done from proxy using proxy generated CDR and SIP signaling cap= ture using something like SIP Homer. The simplest way to get client connect= ion information is by using "fix-up" offers and extracting data f= rom SIP signaling. It is possible to build a separate monitoring solution f= or WebRTC clients using stats, but using existing SIP based solutions alrea= dy works well enough except for bogus info about nominated candidate in c= =3D and m=3D lines.

Regards,
_____________Roman Shpount
=C2=A0
--000000000000e368ee05809d7a7e-- From nobody Tue Jan 29 11:28:27 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2772130FE9 for ; Tue, 29 Jan 2019 11:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRpcSwBSesnl for ; Tue, 29 Jan 2019 11:28:24 -0800 (PST) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B973130FE6 for ; Tue, 29 Jan 2019 11:28:24 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id a14so9774302plm.12 for ; Tue, 29 Jan 2019 11:28:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VIqeXymov9x6jzez3TF/KJisP08yk1vRQFcSCu9uIYw=; b=zDKgbyW4oW04V21+li4wOoUYhQ+0GmOfthIWWWBWuFmzlHPvRolz/FcyZzZf/Rwzpg jUsS3p9l4GqM6Z4R9g+U4uImsb14fEp1LdyCxOPrF4zvJvjL5vfHPWJSihX3jHWVkBkU EYJyk18bPsfqMqb+DzDX8rvqm8v0Nix8E7tYHFy9a2iFLI0/NGT8q8/xjt5b86c40SfD Z6ptGQtj6BgCrmIa+n71yMWbknanQ3kYAx/EV1UG0wiJVDDA7EGsVh8oMw4cRqPQKW+T IoW0nUunwRHgEZ8I2J4xdIibxkPG75P3v8Uh0lODW6rn10csYOp0UOVyYup+/LuuNJv8 MOOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VIqeXymov9x6jzez3TF/KJisP08yk1vRQFcSCu9uIYw=; b=U3CyYeDzMqPMxiiWVEN4a9HS6ZonML53Hkrc+WuupCf9ix7yM14/t8cPkyOOphHcmR VDoraFteeDB0dkxKEhIbSuZpEXZ9Vh5ZRQQvesGJt5Rpqt1vQ/szrvWM614/HLw3vSNt wThZh/c9pg5VHcyT/8JX3B9SzhUPkueJHgJH/vwgtiEPCBMRp71e39iyumzF8TeD9j62 +XnxTSqQY559QYiKcXrjWAARV9E3IcjcVpVX6DFH1aPJYgKk5+EqtxvmfTwKQkitA8Dr g4U8SndeRJHOT6v87dVxBcJwh+necpId0hRNDy8R6fyj395TRFsE7uQulDTlkm/KB9qn 2KBQ== X-Gm-Message-State: AJcUukfS0dj8qWdCYjQXKcf9VsM8yP6NCV9s1Zuh8VX7UGzxyGT2+AiJ ygyF+M5DYeO/Fq3M/hfMrHHRqV80BRc= X-Google-Smtp-Source: ALg8bN51vDVWJY+BJf0KkPJVZ3OERdBVe4poCZyty3NOyx3hE0bswq/D7OlB/BNq1R1XqhELvKDCqQ== X-Received: by 2002:a17:902:142:: with SMTP id 60mr28136992plb.330.1548790103593; Tue, 29 Jan 2019 11:28:23 -0800 (PST) Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com. [209.85.214.179]) by smtp.gmail.com with ESMTPSA id q199sm69403136pfc.97.2019.01.29.11.28.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 11:28:22 -0800 (PST) Received: by mail-pl1-f179.google.com with SMTP id p8so9794339plo.2 for ; Tue, 29 Jan 2019 11:28:22 -0800 (PST) X-Received: by 2002:a17:902:6909:: with SMTP id j9mr26459856plk.196.1548790102402; Tue, 29 Jan 2019 11:28:22 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com> In-Reply-To: From: Roman Shpount Date: Tue, 29 Jan 2019 14:28:11 -0500 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: Nils Ohlmeier , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000e2ace305809dcb42" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 19:28:26 -0000 --000000000000e2ace305809dcb42 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 29, 2019 at 2:05 PM I=C3=B1aki Baz Castillo wro= te: > I understand your point. But still I don't understand the purpose of the > new draft (set TCP/DTLS/etc in proto line if there are just TCP candidate= s > in the offer). > The purpose is standard compliance. If nominated candidate is UDP, proto line should be UDP. If nominated candidate is TCP, proto line should be TCP. If you do not care about the c=3D and m=3D line, put the dummy values = and UDP there, but this breaks legacy interop by causing ICE mismatch. Putting UDP proto and address from TCP candidate breaks legacy interop as well, but it is typically localized to provider managed server, so it is possible to patch around this either in JS client or on the server to treat WebRTC clients differently. Alternatively, WebRTC clients can add a couple lines of code and become compliant with the RFC they decided to implement and remove the need for patching. Of course, if browser follow the ICE spec and set the selected candidate in > the c/m lines, they must also indicate whether that is over UDP or TCP. T= he > problem here is what such a proto line is intended to mean when there is > ICE candidates of UDP and TCP. But ok, let's assume that browser do updat= e > c/m lines in the trigger with the selected candidate, and they JUST chang= e > the proto line to TCP/DTLS if there are just TCP candidates. Now thing > about this scenario: > > 1) Client initial offer with UDP and TCP candidates. > > 2) Server answers with both UDP and TCP candidates. > > 3.1) UDP is selected. Re-offer is created with just UDP candidates (as pe= r > spec). > > 3.2) or TCP is selected. Re-offer is created with just TCP candidates (as > per specs). > > In both 3.1 and 3.2 the "monitoring Node" doesn't need to inspect the > proto line. It can just check the protocol (UDP or TCP) of *any* candidat= e > in the offer to know whether UDP or TCP was selected. > > Am I wrong? > You are correct. Checking c=3D and m=3D line is simply to avoid checking an= d parsing ICE candidates. If monitoring client would handle ICE candidates, then the monitoring client would still need to figure out which candidate is default to record client media IP. Keeping c=3D and m=3D line in sync wi= th default candidate on the client seemed to cause the least amount of problems which is why it was left in ice-sip-sdp. Regards, _____________ Roman Shpount --000000000000e2ace305809dcb42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 29, 2019 at 2:05 PM I= =C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
<= div dir=3D"auto">






__= ___________
Roman Shpount
<= div>=C2=A0
--000000000000e2ace305809dcb42-- From nobody Tue Jan 29 13:53:27 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F78F130DE3 for ; Tue, 29 Jan 2019 13:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEghcw53ixLj for ; Tue, 29 Jan 2019 13:53:24 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA683130DC9 for ; Tue, 29 Jan 2019 13:53:23 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id s5-v6so18845870ljd.12 for ; Tue, 29 Jan 2019 13:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pQdJKpwH+UEDTSYRZDw7zs+NLGIYi6Lz0IoURVPPXLg=; b=P2DK9/KHo2NFdz7TibeRgKIGr+UGanTGmVGgygzxa2DNy3fQYcOInqvhZJQiXIgG+w uA6erO1YIq21Mfe3lp4VoVgxGakpsKKsxFRlblQCkmVcxOdnSxcm2pySiIhYI7UfcIal RUvxAWK1hn+vskT/5K/5AvSsyFmb0aJgWdp9ppt4eElIvVZR1wWf9//plN3GUItgSqtK T0+TdYuG5ZSZl6KfLcML+ch7aXniT2wr0NKL7+L/PfAKKMxZ5RX0HsbP1EPUqWdv3pbC QvGN/TE5uUL82wLKPkUfw+PhGYKx21Ulhu+0PEPmpXkj/rtJ4ifBfUklKgBCLlJvA5DM tIdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pQdJKpwH+UEDTSYRZDw7zs+NLGIYi6Lz0IoURVPPXLg=; b=AzD0s1aglPnkfgTC6Ltj0GHq11fG4GO4gw7i/nXt4bqYVC4lQPUnn16xlTbzdKh8RP hdChhQgHMuOpFosb7SmAv4rfv8Ys43xTrpk8dk2I2yLzWEmh+5HUdVTR1rA8iqcMG/oB 1BXLVAh/BGmKKcm03L838/x2Hb+sA24LYYZsbwQ1aL5dglNFDFvbatE/iPXqoRd8GSSd 0TxVDj76kAagvdS5J3jmZGDEsOZZt1CO6bo3AT9OE/m9h9j1ULlq7242g6sUNv6s1Cb7 C6GgQpTZchzWzWi0zHaap18QEuerVYGv1CnOIRnsUq/V94D+EwkDc+PM6NuUxfri+3Se DsMg== X-Gm-Message-State: AJcUukdOjULSr1eZESjVCGrlMJpSGP18ozFjcsBosWnN4mOfLM8wQmdj rQgXps7gQdNdE3uRvXp8mTwDa0dNRLyoyDVIOwWF+fsh X-Google-Smtp-Source: ALg8bN5aRP+sqY/Buzp5LBGTEwW2bOo4W6EhwmvyEXPr1X/PLaIcwa9MsXPDYOEZhiNXy77EEhl7hPbLbwoonnmXXik= X-Received: by 2002:a2e:95c6:: with SMTP id y6-v6mr19985769ljh.59.1548798801914; Tue, 29 Jan 2019 13:53:21 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com> In-Reply-To: From: Eric Rescorla Date: Tue, 29 Jan 2019 13:52:43 -0800 Message-ID: To: Roman Shpount Cc: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000006ac15f05809fd257" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 21:53:26 -0000 --0000000000006ac15f05809fd257 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 29, 2019 at 11:28 AM Roman Shpount wrote: > On Tue, Jan 29, 2019 at 2:05 PM I=C3=B1aki Baz Castillo w= rote: > >> I understand your point. But still I don't understand the purpose of the >> new draft (set TCP/DTLS/etc in proto line if there are just TCP candidat= es >> in the offer). >> > > The purpose is standard compliance. If nominated candidate is UDP, proto > line should be UDP. If nominated candidate is TCP, proto line should be > TCP. If you do not care about the c=3D and m=3D line, put the dummy value= s and > UDP there, but this breaks legacy interop by causing ICE mismatch. > This is two separate statements that don't necessarily follow form each other 1. This is a matter of standards compliance. 2. It breaks legacy interop I agree on point (1). I'm still waiting for someone to demonstrate point (2= ) -Ekr Putting UDP proto and address from TCP candidate breaks legacy interop as > well, but it is typically localized to provider managed server, so it is > possible to patch around this either in JS client or on the server to tre= at > WebRTC clients differently. Alternatively, WebRTC clients can add a coupl= e > lines of code and become compliant with the RFC they decided to implement > and remove the need for patching. > > Of course, if browser follow the ICE spec and set the selected candidate >> in the c/m lines, they must also indicate whether that is over UDP or TC= P. >> The problem here is what such a proto line is intended to mean when ther= e >> is ICE candidates of UDP and TCP. But ok, let's assume that browser do >> update c/m lines in the trigger with the selected candidate, and they JU= ST >> change the proto line to TCP/DTLS if there are just TCP candidates. Now >> thing about this scenario: >> >> 1) Client initial offer with UDP and TCP candidates. >> >> 2) Server answers with both UDP and TCP candidates. >> >> 3.1) UDP is selected. Re-offer is created with just UDP candidates (as >> per spec). >> >> 3.2) or TCP is selected. Re-offer is created with just TCP candidates (a= s >> per specs). >> >> In both 3.1 and 3.2 the "monitoring Node" doesn't need to inspect the >> proto line. It can just check the protocol (UDP or TCP) of *any* candida= te >> in the offer to know whether UDP or TCP was selected. >> >> Am I wrong? >> > > You are correct. Checking c=3D and m=3D line is simply to avoid checking = and > parsing ICE candidates. If monitoring client would handle ICE candidates, > then the monitoring client would still need to figure out which candidate > is default to record client media IP. Keeping c=3D and m=3D line in sync = with > default candidate on the client seemed to cause the least amount of > problems which is why it was left in ice-sip-sdp. > > Regards, > _____________ > Roman Shpount > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000006ac15f05809fd257 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 29, 2019 at 11:28 AM Roma= n Shpount <roman@telurix.com>= ; wrote:
On Tue, Jan 29, 2019 at 2:05 PM I=C3=B1aki Baz C= astillo <ibc@aliax.ne= t> wrote:
I understand your= point. But still I don't understand the purpose of the new draft (set = TCP/DTLS/etc in proto line if there are just TCP candidates in the offer).<= /div>
=C2=A0
The purpose is standard compliance.= If nominated candidate is UDP, proto line should be UDP. If nominated cand= idate is TCP, proto line should be TCP. If you do not care about the c=3D a= nd m=3D line, put the dummy values and UDP there, but this breaks legacy in= terop by causing ICE mismatch.

This is two separate statements that don't necessarily follow for= m each other

1. This is a matter of standards comp= liance.
2. It breaks legacy interop

I ag= ree on point (1). I'm still waiting for someone to demonstrate point (2= )

-Ekr

Putting UDP proto and address from TCP candidate breaks legacy interop as= well, but it is typically localized to provider managed server, so it is p= ossible to patch around this either in JS client or on the server to treat = WebRTC clients differently. Alternatively, WebRTC clients can add a couple = lines of code and become compliant with the RFC they decided to implement a= nd remove the need for patching.

Of course, = if browser follow the ICE spec and set the selected candidate in the c/m li= nes, they must also indicate whether that is over UDP or TCP. The problem h= ere is what such a proto line is intended to mean when there is ICE candida= tes of UDP and TCP. But ok, let's assume that browser do update c/m lin= es in the trigger with the selected candidate, and they JUST change the pro= to line to TCP/DTLS if there are just TCP candidates. Now thing about this = scenario:

1) Client = initial offer with UDP and TCP candidates.

2) Server answers with both UDP and TCP candidates.

3.1) UDP is selected. Re-off= er is created with just UDP candidates (as per spec).

3.2) or TCP is selected. Re-offer is created = with just TCP candidates (as per specs).

<= div dir=3D"auto">In both 3.1 and 3.2 the "monitoring Node" doesn&= #39;t need to inspect the proto line. It can just check the protocol (UDP o= r TCP) of *any* candidate in the offer to know whether UDP or TCP was selec= ted.

Am I wrong?

You are correct. Checking c=3D and m= =3D line is simply to avoid checking and parsing ICE candidates. If monitor= ing client would handle ICE candidates, then the monitoring client would st= ill need to figure out which candidate is default to record client media IP= . Keeping c=3D and m=3D line in sync with default candidate on the client s= eemed to cause the least amount of problems which is why it was left in ice= -sip-sdp.

Regards,
_____________
Roman Shp= ount
=C2=A0
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000006ac15f05809fd257-- From nobody Tue Jan 29 14:08:40 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A7F130EDB for ; Tue, 29 Jan 2019 14:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vaFFSp8u6BE for ; Tue, 29 Jan 2019 14:08:36 -0800 (PST) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8067D12E7C1 for ; Tue, 29 Jan 2019 14:08:36 -0800 (PST) Received: by mail-pg1-x536.google.com with SMTP id m1so9359476pgq.8 for ; Tue, 29 Jan 2019 14:08:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gY7x9kLNYLhoDVz8msp1B4b8ovpgweC56jkVdpMeWfk=; b=nmuoTXnnqv1DqVQrhV7lzkeMecb+9EETtvRj4XOlc9pBCNeZHTvq21X1UrWyZaAggh 76lz76upydHtCf4ZOjL25dWoSIEP+rvi726qMDoxAzMm0oBpDK+dbIeOLoq/qZQI2vWT Pzh/JEmcLRSJXOcGuEUk7wENeYKQKkrC9K1Z5AhHY6yMhtbCLmtXLJSwWjeCZtLWaNib KPVmCOlL+BzI+xBZ1Qsuz9NAoPCg+o8h0KMJV+pxMaat04mEqReXUv8PbhVyGj1odglj rxNQSiAlQ1az9Rb8GSuU8rTVWlRfe/HzErLZh3+N+3oCq6YZlLp7W3Y+1F6IjS0zVTrQ Wd/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gY7x9kLNYLhoDVz8msp1B4b8ovpgweC56jkVdpMeWfk=; b=dYh8ztos+ah1vHVkku6W8BO5Ds9IHSLVIZLWuL1R4aw0UfzLKS78fVnS8N46abv+uj g9/AWR+k8G5ooixaterOD9xBCQOVGWo/6MSUOuwqJZpkJ/er8lURaZ0YOyntZq5mYp7S ZSzpJK3Dz9rNX+qH/1GfFBzkTeZJ1UWKWKdtnw7LdhGgpedkwFFTHE++4yiVM0Kaqu+z 2T8UUW/WC1WPSbqgtfGyuVgwTTmpVerrpwYG9/KKkDbnF9+/13tBLpoo8zZBuLiAcNT0 +Apu5aNAot2MmAi0InUzNtoxDR8hwE6LBNE+NFkdrbIs6wlcwvNTDBd9c2lCxJB4pe6i 3g+Q== X-Gm-Message-State: AJcUukfDYcsXKMYnYnHj36dSbyEqsSJg/nCx94uhr/RRsq66sOhszYkR Nqf1FPLkOY1+g8/srCxW1T1lNFSMGzs= X-Google-Smtp-Source: ALg8bN4s7a8JzLtA0bNJ+Gudijj/VYSwkaC2KJdsHfGJyszYnLXSnC6+j3KQMZudeRwbKMajl9QYmw== X-Received: by 2002:a63:c42:: with SMTP id 2mr25327253pgm.372.1548799715298; Tue, 29 Jan 2019 14:08:35 -0800 (PST) Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com. [209.85.214.169]) by smtp.gmail.com with ESMTPSA id 5sm67250480pfz.149.2019.01.29.14.08.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 14:08:34 -0800 (PST) Received: by mail-pl1-f169.google.com with SMTP id u18so10001934plq.7 for ; Tue, 29 Jan 2019 14:08:34 -0800 (PST) X-Received: by 2002:a17:902:8b88:: with SMTP id ay8mr28219532plb.55.1548799714253; Tue, 29 Jan 2019 14:08:34 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com> In-Reply-To: From: Roman Shpount Date: Tue, 29 Jan 2019 17:08:23 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Cc: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000cbe2fa0580a00820" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 22:08:38 -0000 --000000000000cbe2fa0580a00820 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 29, 2019 at 4:53 PM Eric Rescorla wrote: > > On Tue, Jan 29, 2019 at 11:28 AM Roman Shpount wrote: > >> On Tue, Jan 29, 2019 at 2:05 PM I=C3=B1aki Baz Castillo = wrote: >> >>> I understand your point. But still I don't understand the purpose of th= e >>> new draft (set TCP/DTLS/etc in proto line if there are just TCP candida= tes >>> in the offer). >>> >> >> The purpose is standard compliance. If nominated candidate is UDP, proto >> line should be UDP. If nominated candidate is TCP, proto line should be >> TCP. If you do not care about the c=3D and m=3D line, put the dummy valu= es and >> UDP there, but this breaks legacy interop by causing ICE mismatch. >> > > This is two separate statements that don't necessarily follow form each > other > > 1. This is a matter of standards compliance. > 2. It breaks legacy interop > > I agree on point (1). I'm still waiting for someone to demonstrate point > (2) > >> >> Unfortunately 2 is impossible to demonstrate to your satisfaction since: a. Browsers currently do something different from the spec (once again is being debated) and include additional candidates even after ICE nomination was completed b. Using UDP based proto when TCP based candidate is nominated only affects server provider SBC or media servers. These components are typically easier to patch when dealing with non-compliant implementations similar to current JSEP clients. What you are arguing is to keep the "special" profile for SBC/Media Servers indefinitely instead of making browsers and VoIP end points do the same thing. This is simply moving the complexity from one place to another. As an observation, since JSEP currently mandates that c=3D and m=3D lines a= re already updated (address and port) based on the ICE candidate which is nominated, I am not sure if additional complexity of updating the proto line at the same time is all that great. Regards, _____________ Roman Shpount --000000000000cbe2fa0580a00820 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 29, 2019 at 4:53 PM E= ric Rescorla <ekr@rtfm.com> wrote= :

On Tue, Jan 29, 2019 at 11:28 AM Roman Shpount <roman@telurix.com> wrote:=
On Tue, Jan 29, 2019 at 2:05= PM I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
I understand your point. But still I don't understand the purpose of= the new draft (set TCP/DTLS/etc in proto line if there are just TCP candid= ates in the offer).
=C2=A0
The purpose is = standard compliance. If nominated candidate is UDP, proto line should be UD= P. If nominated candidate is TCP, proto line should be TCP. If you do not c= are about the c=3D and m=3D line, put the dummy values and UDP there, but t= his breaks legacy interop by causing ICE mismatch.

This is two separate statements that don't ne= cessarily follow form each other

1. This is a matt= er of standards compliance.
2. It breaks legacy interop

I agree on point (1). I'm still waiting for someone to = demonstrate point (2)
=C2=A0
--000000000000cbe2fa0580a00820-- From nobody Tue Jan 29 15:22:07 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18C8130EE0 for ; Tue, 29 Jan 2019 15:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEiGDTjP9jdl for ; Tue, 29 Jan 2019 15:22:03 -0800 (PST) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEB9F130EDD for ; Tue, 29 Jan 2019 15:22:03 -0800 (PST) Received: by mail-vs1-xe2d.google.com with SMTP id h78so13090553vsi.6 for ; Tue, 29 Jan 2019 15:22:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PtIQTHg+bn+PtgYahgv2X7VzBnDj/ObnlHFlEUtymVw=; b=hx0NyS4DUi2fuYT9l9zzdV5y2jqL3FGKEGWanZrp8Gtp55kqK6FICKjTFfzn6TM9sF bE42opWqFm31iGyNfxIX4G4CQIrOBlbgSMDOAgcyauhmu1iG0MgQWXLBYaPVSXQ83rHi P4snAETMsnEvShzY/TW9PXDRvS00VVxK+TZz8+7iZ5d04n13NdE7GHaGlDvaZ2tTceHt HFezTzcLN/YtOjiJCrD9BgwIbJTgwv7kt3DnrncYHofxFsfRF194zjfrgDA6L5BkosKB c4qou8IFvXRRz3azHvZQr1X8hAgeSLhyeNMVR/7prLuWeh2I597E2cQm7sVAsT6wOAo6 7LsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PtIQTHg+bn+PtgYahgv2X7VzBnDj/ObnlHFlEUtymVw=; b=kKO0U631X212HVcv3zCwUWq5N90hpQSXjKyH5xea2D/fiaeb47IJ4E6SThaDrO38v3 L6S4GzyamrcmA8dPkLZEnJWdjKkSTpsIjeAamDRGwZFSma14NznSt7rcxexG5VALziUM KQlgSwZ9VdgwGZz1a3ii3ckGFwjV/pPPEprftVFV6Z2MKw4zFb27jVu/zrrq5NDwd/J1 jVpnYsA2C52/qzAm6AqOpNdZ7W5GaOLpfdHj1fruyHNrhygVmK7L+SnzcpgBkRJPcu51 DEMcIaGbhdFs1J+7ksCwXtcu/L1rbkGFXFSS6oIEhbmrsQA+SnYhYpmgPCh7Rnk0oqa6 pZuw== X-Gm-Message-State: AJcUukdDP8HN2ynS3GREP6Y8FeKHHANQGelhUFyKSF80ViAJjj3hGGIc GYkOGHAKwxY2mOGS0c9s1gt6Rye3m230u9zeJ4ZnxBpY+MQ= X-Google-Smtp-Source: ALg8bN684dyAKJe77vNcGPdKaapqnj3bpcakouGattjugcpHtC10oQK09pgnK4S5tfqUdJEMgVi7vDYNOx1O0FyAnjY= X-Received: by 2002:a67:7106:: with SMTP id m6mr12183930vsc.67.1548804122724; Tue, 29 Jan 2019 15:22:02 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 30 Jan 2019 00:21:51 +0100 Message-ID: To: Roman Shpount Cc: Nils Ohlmeier , RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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: Tue, 29 Jan 2019 23:22:06 -0000 On Tue, 29 Jan 2019 at 20:28, Roman Shpount wrote: > WebRTC clients can add a couple lines of code and become compliant with t= he RFC they decided to implement and remove the need for patching. I can just agree. If vendors do not want to implement something in the spec they should fight the spec itself and not those who try to conform to it. --=20 I=C3=B1aki Baz Castillo From nobody Wed Jan 30 06:17:32 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB208128CF2 for ; Wed, 30 Jan 2019 06:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.853 X-Spam-Level: X-Spam-Status: No, score=-8.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=TWH66LeZ; dkim=pass (1024-bit key) header.d=ericsson.com header.b=bzWAuvpt Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOIyQwJ03p38 for ; Wed, 30 Jan 2019 06:17:28 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F8B130EB5 for ; Wed, 30 Jan 2019 06:16:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1548857801; x=1551449801; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1Pfn2N9PdegatzBY7rD9LYLsqciiE+M7MlqcFa72muI=; b=TWH66LeZeu4FFqKQNkEdf+CjbC1Ygn/ElyN36FdKPaW3ptSKomrjjAZMcETnq+8U 9AdrvkED6xF7MgMj/JbtmJYVSxG6Xnt4y2QMeX70iL/G1j5Pg3pNxh4CGT1sGFCU H7Ro0A2p5hEteU0CCusETFrRkceT2+y8omwXr1L1ZkI=; X-AuditID: c1b4fb3a-14fff7000000672c-5b-5c51b1c94a45 Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A9.14.26412.9C1B15C5; Wed, 30 Jan 2019 15:16:41 +0100 (CET) Received: from ESESBMR501.ericsson.se (153.88.183.129) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 30 Jan 2019 15:16:41 +0100 Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESBMR501.ericsson.se (153.88.183.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 30 Jan 2019 15:16:41 +0100 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 30 Jan 2019 15:16:40 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1Pfn2N9PdegatzBY7rD9LYLsqciiE+M7MlqcFa72muI=; b=bzWAuvpt5Ra+cYeslfnzgevQlPOLHomL7fPeY5sx7G1zt4RAYMc4eOEtMhx/Qe3bcCRGHSZHZuY87f3I3kVXO3DdOw0DndlJiaEsSzlSyBNebAhVihBdC4dyGVkidIP+cTFgTCcT/Nz916H+qRueMd0L3UQMJqTJU0la757I4eo= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4361.eurprd07.prod.outlook.com (20.176.167.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.6; Wed, 30 Jan 2019 14:16:39 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0%4]) with mapi id 15.20.1601.008; Wed, 30 Jan 2019 14:16:39 +0000 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Roman Shpount CC: RTCWeb IETF Thread-Topic: [rtcweb] Proposal to break the ICE impasse Thread-Index: AQHUtCoOCID4ifgvbk+6P/h8fwfLKaXBz0cAgAEnOzeAAlkQgIAAHScAgAADHICAAAKbgIAAA+MAgAAEr4CAAIGVgIAAMCmAgAAaH4CAAEXWAIAABXMAgAAHuACAAARIgIAABLmAgAAGVYCAAEFJgIABG4iA Date: Wed, 30 Jan 2019 14:16:39 +0000 Message-ID: <0219562B-8F36-4DC3-ACAF-E820B010981D@ericsson.com> References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.14.0.181208 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB4361; 6:BYoOypcxexMnWwSiHDGETSc3tWWlJz39hh12TaJ30lT4o62ACGR1tu0fn/wz4ESNh5kaepS9S09g2PuLJOM4CM9cmBRnLjs0xl2UCQsIy6gc1JMZguEcTms2rtBt0k37CJuZAz4UpCvDEOc3JrYUMaV1xaBpEeHF6a2c1BklOtb0nrydzu7Hz/u6e8icEUzaPuEBkNYi9GoyWlpMeawG5/7LCLOHCzqtbAbTAD0fz3qxrKycCx7U8LEmqmX0vorrdvC9VoSxuB93/5adru0hyOfLv+GM5W7KwcSY8Q5ArpZ32MLvSvexWaSsEsCQEJXfmskyM9pDL1/FpN/Y8Hc9GIdfkh7HAW+2LeiM6snHLFiSDhYO+HFpjHz8FGLO+KrTry1uS8WJ7Dwde1mhFLqG2i8Ol+VLupDxLgvVo4aI9T+ly0UqUlvHV7SN2J5rJAi0TomnjVJ+B/onkppfZclEbA==; 5:Lw/ZiG5SmJ35+SW9ruTgrArP+y+f7BvhhcEaorvwyAy5pO3lPA1cuwY/gh73mMgzgyA2iz5A661sZS5VNVPGU59zgkwaY/RV84KP4SyCjTS/DhJ6ss7lBTvLqnnev6YDWYCR+bDvqD6GTCiUmcaGIegDKwxfanSdraa5Il+thBlOn1/yGfQqoM4Z4DTHgH3y8bucd9bjMm6euRiWPMGPEQ==; 7:xRUluvA+63c4a+J3rcS7t65e9hiN7AfPcYXOtwNhGVAP/1aMvqttI5NVl3Kxet0UDDafIvLeqsHiY/W2Ca1+6FeRr2rYN/CMWZQmU7S6D9AtqMzEMeYRq0U5llyh0h8tI+xbYIVbEjgv/muBxgikuQ== x-ms-office365-filtering-correlation-id: cbdd041b-62bb-46e8-3918-08d686bd8d47 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4361; x-ms-traffictypediagnostic: HE1PR07MB4361: x-microsoft-antispam-prvs: x-forefront-prvs: 0933E9FD8D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(136003)(396003)(376002)(366004)(189003)(199004)(99286004)(93886005)(33656002)(8936002)(6116002)(83716004)(14454004)(11346002)(53936002)(486006)(66066001)(3846002)(81156014)(71200400001)(25786009)(71190400001)(76176011)(8676002)(81166006)(36756003)(66574012)(256004)(305945005)(82746002)(44832011)(7736002)(6246003)(446003)(2906002)(6486002)(4744005)(476003)(4326008)(26005)(966005)(68736007)(186003)(86362001)(102836004)(478600001)(97736004)(106356001)(229853002)(6436002)(2616005)(6512007)(110136005)(316002)(105586002)(58126008)(6506007)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4361; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: uPV05bnM+tG3aYuO/Iwb5R1WzZZPtHhgbKkPBlOVbKUzk8WkDfiAdW+uEl2sTyWGO1TMG5bGjmZyumMoYEmsaW3Pdzq1m6rNEgRwVEqP2GsjRwC42fQJmvWjNFJ3aYiKk9flKa6aEA8wcH3ey6Uo/8noyJ9Hnu7/Ldkbr78WAgWFyCDBmH6JHww+tW9CncQz8CtF7IKZCryFRpfKPSbH/TWwSEs/WhuipIa3R3z50np1ktYm3xf/0LVkrl1ihnRdN1Q8RWnNBOEpe+bevnaiiYWjvpLzdoIbMoYRUQlo1anz7co/z9eFBqZfyTxkc6QyKdPRQFijCkZx0UaGbEEUiJJfV1lBM+UTaWMJ9fA9L4ZB7hLhhy8v3Kr5GCs/2GIbeNm2j6ZtZRMsEsFXaAevEOzOJd2EbOqTqniBBXhe3Q0= Content-Type: text/plain; charset="utf-8" Content-ID: <88AC89A3147F2C4BB47370F1F7B2687D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cbdd041b-62bb-46e8-3918-08d686bd8d47 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2019 14:16:39.4748 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4361 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA01SbUhTYRTm3d3H3XTxujRPVpSDgsycmtAQP/JP2Y+whVDEKC96U1Gn7E7J iLJQLJdpaR+atMxpaoYYpmHmx9Jog3SJUdqIzaS0QiXXQg3Ju3uL/j3P+zznPOccXpJQ1IiC yEydgdbrqGylWCasOdadv9vaodGGf30TpL7VF6O+bb9BqB+tlkr2EYkjRfOSRLN5SZA4WZ13 mDgui0mjszMLaL0qLkWW0TJfJcprkp2ef/FKXISKZWVISgKOgrkhFypDMlKBhxA4bIM88SAw llcI/5GZxfsER8wC+H7X7SVCXEnAtZ7nYk65LoDiq8t8gykE4856URkiSTFWg3F1F5vojykw 19yRsJjAweB+YBKzlvV4L4y1h3IWNXjGy7zR/rgVQd+cQ8QKQrwdLlk8BIvlOB5G3CY+uEsG bUMzBNtIijXgrEthPQhvgF+2NgGXFQiT0yYBtzUGc+8oweEAmP206u0fgFXg/DEg4Wop6G91 8p5geD3n4mu3wJjJ6N0R8EUJNDR28KZDcKX3oZATJhC8nLXxFSFgHmUnZXEWfJ7q9w4KeDO4 3cmVKLz2v/lq1xQC74T2HhX3nAgfuhZEtfy5qo0uSa13fT+w1kwL7yFRKwpgaIbJSY+MDKP1 makMk6sL09GGx2jtwwx2rkQ/RYNfEiwIk0jpK3eZNFqFiCpgCnMsCEhC6S+PWEnSKuRpVOEZ Wp97Up+fTTMWtIkUKgPlvxV+WgVOpwx0Fk3n0fq/qoCUBhUh6lynqnvYRrYtn1hdii/323O2 OSlUW3rA7jOrkhw1SlNDGzU+9mcO3zqt+vy6kpa51PoGe7Qxfajd+i6qpPHmgOybPvb9hO1y ctx+wynDNlFTAibl41EJH4MLDnoWF/2pLM3PJxXFsSNvNy40464jwzscyGLtv1BVZ4rsp7cq hUwGFRFC6BnqD4cOsXwsAwAA Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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, 30 Jan 2019 14:17:31 -0000 SGksDQoNCkl0IGlzIGFsc28gd29ydGggbm90aW5nIHRoYXQgdGhpcyBpcyBub3Qgc29tZXRoaW5n IHRoYXQgaGFzIHJlY2VudGx5IGNoYW5nZWQgaW4gSUNFLCB3aGljaCBjb3VsZCBiZSBhIHJlYXNv biB3aHkgdGhlcmUgYXJlIGV4aXN0aW5nIGRlcGxveW1lbnRzIGRvaW5nIHRoaW5ncyBkaWZmZXJl bnRseS4gDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQrvu79PbiAzMC8wMS8yMDE5LCAx LjIyLCAicnRjd2ViIG9uIGJlaGFsZiBvZiBJw7Fha2kgQmF6IENhc3RpbGxvIiA8cnRjd2ViLWJv dW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGliY0BhbGlheC5uZXQ+IHdyb3RlOg0KDQogICAg T24gVHVlLCAyOSBKYW4gMjAxOSBhdCAyMDoyOCwgUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJp eC5jb20+IHdyb3RlOg0KICAgID4gV2ViUlRDIGNsaWVudHMgY2FuIGFkZCBhIGNvdXBsZSBsaW5l cyBvZiBjb2RlIGFuZCBiZWNvbWUgY29tcGxpYW50IHdpdGggdGhlIFJGQyB0aGV5IGRlY2lkZWQg dG8gaW1wbGVtZW50IGFuZCByZW1vdmUgdGhlIG5lZWQgZm9yIHBhdGNoaW5nLg0KICAgIA0KICAg IEkgY2FuIGp1c3QgYWdyZWUuIElmIHZlbmRvcnMgZG8gbm90IHdhbnQgdG8gaW1wbGVtZW50IHNv bWV0aGluZyBpbiB0aGUNCiAgICBzcGVjIHRoZXkgc2hvdWxkIGZpZ2h0IHRoZSBzcGVjIGl0c2Vs ZiBhbmQgbm90IHRob3NlIHdobyB0cnkgdG8NCiAgICBjb25mb3JtIHRvIGl0Lg0KICAgIA0KICAg IA0KICAgIC0tIA0KICAgIEnDsWFraSBCYXogQ2FzdGlsbG8NCiAgICA8aWJjQGFsaWF4Lm5ldD4N CiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KICAgIHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCiAgICBydGN3ZWJAaWV0Zi5vcmcNCiAgICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KICAgIA0KDQo= From nobody Wed Jan 30 06:21:37 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434D1128CF2 for ; Wed, 30 Jan 2019 06:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.853 X-Spam-Level: X-Spam-Status: No, score=-8.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=P63YdBZ6; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Zjx0pbRN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF3lYKndlcea for ; Wed, 30 Jan 2019 06:21:32 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61AD1123FFD for ; Wed, 30 Jan 2019 06:21:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1548858090; x=1551450090; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Lp13FCCtSuhd4v4o1nwoqP+60EKspGvEH0oUVjnuQ+k=; b=P63YdBZ6BvCK0ZEMb9ZqyL0eQhhe5FVQFQwM3c6FqgHPeDER+lhu/iIeec+ArXHT S6ezWmk1p19NwYxO/Fe7CmEbaDycXdsB4Bnprtdl9xs04oi38jXy0HA2s4f1MXpx i1hCP/ySue4nyfuyjBkSOLRG/ugHVTBD63wRuzbOHOQ=; X-AuditID: c1b4fb25-d89ff70000005ff7-6d-5c51b2ead860 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 86.5C.24567.AE2B15C5; Wed, 30 Jan 2019 15:21:30 +0100 (CET) Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 30 Jan 2019 15:21:30 +0100 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 30 Jan 2019 15:21:30 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Lp13FCCtSuhd4v4o1nwoqP+60EKspGvEH0oUVjnuQ+k=; b=Zjx0pbRNbpcVv8MTtTTytmjy7Sfr5AcrUILSU04usduC6dQd6WG5Hgp1kXkLWSBU0p3+wor5YL6V0vkpf0a5zTiHbEYyNNfOFVfQqIpllsjBWxY2gy3mXl90mAcUQg/cgVK5iQSiiWg9xyXBw3JqIbhn3e+HeuV2c8CznygSBN0= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3324.eurprd07.prod.outlook.com (10.170.247.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.7; Wed, 30 Jan 2019 14:21:29 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0%4]) with mapi id 15.20.1601.008; Wed, 30 Jan 2019 14:21:29 +0000 From: Christer Holmberg To: Eric Rescorla , Roman Shpount CC: RTCWeb IETF Thread-Topic: [rtcweb] Proposal to break the ICE impasse Thread-Index: AQHUtCoOCID4ifgvbk+6P/h8fwfLKaXBz0cAgAEnOzeAAlkQgIAAHScAgAADHICAAAKbgIAAA+MAgAAEr4CAAIGVgIAAMCmAgAAaH4CAAEXWAIAABXMAgAAHuACAAARIgIAABLmAgAAGVYCAAChigIABNcmA Date: Wed, 30 Jan 2019 14:21:29 +0000 Message-ID: References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.14.0.181208 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3324; 6:9RR85x4YMu3VE9f6P14RE7KSgXSZL3xTNNdHb90MUzYdoI85sHAc5QUAIH1wCrc7PKWvtx4WFW5a8uli23LGlRJIYwdQkq+VjetJhv8jcXVxKaXQMlE0QE2+66ldX0xJG9xw9edvegwRgySmgW+8YEVUkQNojvwuwsZmqAiHyyjWpOz1J/BIzXe0YYjhFc6MhWYx20QfwvVKIWQyyKcD+18kvR9pePCpBEfbFaX0rLM/v0VscorsXAKnfWEHnNE249dSrP1c8BfnlkNsizJrNgfuLgc8lAWU4H8mq6kWyz0U+lPGtnkhLWis0H1Ofmcy6lzkf3UvG881K/DFaCOyStTH20KDHBXwQgmwld37Dp+iO2qpSvUFOlHckpz/Snj/1qsYmXkjIfmqsuEahiQreYOVO3JdMfD5mlRDde6WePPvrcU+WSgj/WvboBlyY7dyluFKroeGWL+JqbsaIQ2KBQ==; 5:W12P6O+coFiOvYRXsh78BZrEBKUBPhMCSBeZ2FiYahwIpeXzKPKJIGY20nQdWLllXUQWinMdcMJcuVNdFODOVbduJONfoSBO8fmeQA9zP5gvlT/NeEimpwjHZTKkKa2hh172J3b+sU1i9XHWNifXAjZbnyq2CgxIPOqLsC/G05/AyQBny2Xk3zZZ26jNlGe9B2bwnVDBBMXG3j1dP0RflQ==; 7:BMXkEjJNW0tzc79tG1bpsSo274cNtoq8dja8YqAMsnnkPrbi9Ta+pJX3Z0YWl7oB3fRoLC9JQ+JwbYpkxwaZCpcAWmZW8JCe6Npu/bjYjQyJbdvg7bcVfziynKpijRoNkRADCS0KTv9vRCEYqrFBRg== x-ms-office365-filtering-correlation-id: 1819f816-1b0e-4774-2f67-08d686be3a17 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3324; x-ms-traffictypediagnostic: HE1PR07MB3324: x-microsoft-antispam-prvs: x-forefront-prvs: 0933E9FD8D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(376002)(346002)(136003)(39860400002)(189003)(199004)(316002)(68736007)(36756003)(6512007)(186003)(6306002)(6506007)(2906002)(8936002)(486006)(105586002)(53936002)(106356001)(14444005)(99286004)(8676002)(58126008)(81156014)(81166006)(256004)(86362001)(110136005)(76176011)(305945005)(26005)(7736002)(83716004)(66574012)(102836004)(478600001)(14454004)(71200400001)(11346002)(476003)(93886005)(229853002)(33656002)(71190400001)(446003)(25786009)(44832011)(97736004)(6486002)(6116002)(3846002)(2616005)(6436002)(4326008)(6246003)(82746002)(966005)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3324; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: XHvQlWOnURIYdjTPw9nDgRS5YXpI25a/3a81aMNne/0XL4WGM6G9ddkRICnz7WJWWmMTCobep14mBbUwHBllbdDL96rS+BBrXEUTQ5R9XreyNpbjb2J/s5Ag1aYSFT5/SncjuyHjnQ+Ctdpt0IX9w5LXCCq/MNJkcRpukp05vYO1XN0D1n/xcyXU7a+xjrFFStR8qCepCuVI7nQVt6nIlE9b5IGqiqCOhqMiOfS6Xfi9V2VX4gw7/mzK14GMFn7tKokAjGMNvTkmEsGJ4JYn2nhJTHlmHi63Hjja5bVUoO9gyoLdzCX9AG1YSvSCPYMYDyQ7f/sr4WcPYjpsODQwUjzC1TbKidIqWGeHpIo41gYlH3MY/g1v1S9B2pKEcrSWHiSXor0Yp4gf93dlhMZM8rltTpiLJx8637M2pr4GUBo= Content-Type: text/plain; charset="utf-8" Content-ID: <813BDE919949934EAB99CA224E87D72A@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1819f816-1b0e-4774-2f67-08d686be3a17 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2019 14:21:29.4969 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3324 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SW0gUYRTH+XZmZ8aljc/Ny/EWuqWQpWYWLt1M7GF7KLOCShZqzEnFKzsq 6UNqoMHui5hhSrWai8qibW1qEsmampVheS0UA2+5XsokdUOUJcfZoLf/Oed3zv98h48hFBVS byYlI5vTZrBpSkpGVl55yYcsWOI0B3VlQaqGxU+06kH/fULV5LhLnyLURuO6RH1vuoRQj5Vn nSfiZccTubSUXE4bdvK6LNlgmiOzhgNuGZ7b6EI0469DLgzgw9BW40A6JGMUuBuB3TwqFQM7 go9D87QYGCVgNTaTQkDiUgKKHzZQYqVMArr+FUIYpsBTCGq/7NYhhqGwCvSO/ULaDcfA+5I5 StAEDoDVegMlILtwJAyaD4iICuzDOlLUJgTdvSGCJnEgdPcNSQUtx1FQrf/pXLVVBuaFCkKY 44LjYKIjRWAQ9oA/vY0S0coTxmYMEvGZGIyvPxOidof5acf2THccBhO/O2ixlwWracLJBEDf 0qSz1w8GDfptX8B3aGhpH0GCL+CzMLGWKuZHEbzt1dNiQzD82qynRJ0KxfYBSuR9YXX1ksiv SaG3xUyWorCq/3at2sIIvA/Mr5xpNVgGDFSV83Ll+km6avsUrvChcoasRlITcuc5PiE96VBE KKdNucHzmRmhGVy2BW19lzfNG4FtaOhHdCfCDFLukF+ojtMopGwun5feiYAhlG7y8I1YjUKe yOblc9rMa9qcNI7vRD4MqfSUbypcNQqcxGZzqRyXxWn/VSWMi3chirbDuZInXsunn9rOXJZI fGtytbPxUUdivhaN9cUkezhGLCHjLMrZU6N7tu5bvFSw8kjRs9hktUe8i1Ix3m4aS49a9+Jx XePeyG9JCUs7j2ZO1dJ1jpII2/iJ1otXZ9miLqrCzyc2iMmzSW9a/QuWHbc3vRK6go7VtH/P T5/3VJJ8MhseTGh59i+AeuXwKgMAAA== Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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, 30 Jan 2019 14:21:35 -0000 SGksDQoNCj4+PiBJIHVuZGVyc3RhbmQgeW91ciBwb2ludC4gQnV0IHN0aWxsIEkgZG9uJ3QgdW5k ZXJzdGFuZCB0aGUgcHVycG9zZSBvZiB0aGUgbmV3IGRyYWZ0IChzZXQgVENQL0RUTFMvZXRjIGlu IHByb3RvIGxpbmUgaWYgdGhlcmUgYXJlIGp1c3QgVENQIGNhbmRpZGF0ZXMgaW4gdGhlIG9mZmVy KS4NCj4+wqANCj4+IFRoZSBwdXJwb3NlIGlzIHN0YW5kYXJkIGNvbXBsaWFuY2UuIElmIG5vbWlu YXRlZCBjYW5kaWRhdGUgaXMgVURQLCBwcm90byBsaW5lIHNob3VsZCBiZSBVRFAuIElmIG5vbWlu YXRlZCBjYW5kaWRhdGUgaXMgVENQLCBwcm90byBsaW5lIHNob3VsZCBiZSBUQ1AuIA0KPj4gSWYg eW91IGRvIG5vdCBjYXJlIGFib3V0IHRoZSBjPSBhbmQgbT0gbGluZSwgcHV0IHRoZSBkdW1teSB2 YWx1ZXMgYW5kIFVEUCB0aGVyZSwgYnV0IHRoaXMgYnJlYWtzIGxlZ2FjeSBpbnRlcm9wIGJ5IGNh dXNpbmcgSUNFIG1pc21hdGNoLg0KPj4NCj4+IFRoaXMgaXMgdHdvIHNlcGFyYXRlIHN0YXRlbWVu dHMgdGhhdCBkb24ndCBuZWNlc3NhcmlseSBmb2xsb3cgZm9ybSBlYWNoIG90aGVyDQo+Pg0KPj4x LiBUaGlzIGlzIGEgbWF0dGVyIG9mIHN0YW5kYXJkcyBjb21wbGlhbmNlLg0KPj4yLiBJdCBicmVh a3MgbGVnYWN5IGludGVyb3ANCj4NCj5JIGFncmVlIG9uIHBvaW50ICgxKS4gSSdtIHN0aWxsIHdh aXRpbmcgZm9yIHNvbWVvbmUgdG8gZGVtb25zdHJhdGUgcG9pbnQgKDIpDQoNClRoZXJlIGFyZSBu ZXR3b3JrcyB3aGVyZSBub2RlcyAobm90IGFsd2F5cyBTQkNzKSB1c2UgdGhlIGMvbS0gaW5mb3Jt YXRpb24gdG8gY29udHJvbCBuZXR3b3JrIHJlc291cmNlcyAoZS5nLiwgcmFkaW8gYmFuZHdpZHRo KS4gV2hldGhlciBVRFAgdnMgVENQIHdpbGwgaGF2ZSBhIG1ham9yIGltcGFjdCBJIGRvbid0IGtu b3csIGJ1dCB0aGUgcG9pbnQgaXMgdGhhdCB0aGUgYy9tLSBpbmZvcm1hdGlvbiBJUyB1c2VkLg0K DQpXaGV0aGVyIHRoZSBXRyBoYXMgYWdyZWVkIHRoYXQgdGhlIGMvbS0gaW5mb3JtYXRpb24gaXMg Im1lYW5pbmdsZXNzIiBpbiB0aGUgSlNFUCBBUEkgSSBkb24ndCBrbm93LCBidXQgaXQgZm9yIHN1 cmUgaXMgbm90ICJtZWFuaW5nbGVzcyIgb24gdGhlIHdpcmUuDQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQoNCg0KDQoNCg0KDQoNCg0KDQpQdXR0aW5nIFVEUCBwcm90byBhbmQgYWRkcmVzcyBmcm9t IFRDUCBjYW5kaWRhdGUgYnJlYWtzIGxlZ2FjeSBpbnRlcm9wIGFzIHdlbGwsIGJ1dCBpdCBpcyB0 eXBpY2FsbHkgbG9jYWxpemVkIHRvIHByb3ZpZGVyIG1hbmFnZWQgc2VydmVyLCBzbyBpdCBpcyBw b3NzaWJsZSB0byBwYXRjaCBhcm91bmQgdGhpcyBlaXRoZXIgaW4gSlMgY2xpZW50IG9yIG9uIHRo ZSBzZXJ2ZXIgdG8gdHJlYXQgV2ViUlRDIGNsaWVudHMgZGlmZmVyZW50bHkuIEFsdGVybmF0aXZl bHksIFdlYlJUQyBjbGllbnRzIGNhbiBhZGQgYSBjb3VwbGUgbGluZXMgb2YgY29kZSBhbmQgYmVj b21lIGNvbXBsaWFudCB3aXRoIHRoZSBSRkMgdGhleSBkZWNpZGVkIHRvIGltcGxlbWVudCBhbmQg cmVtb3ZlIHRoZSBuZWVkIGZvciBwYXRjaGluZy4NCg0KT2YgY291cnNlLCBpZiBicm93c2VyIGZv bGxvdyB0aGUgSUNFIHNwZWMgYW5kIHNldCB0aGUgc2VsZWN0ZWQgY2FuZGlkYXRlIGluIHRoZSBj L20gbGluZXMsIHRoZXkgbXVzdCBhbHNvIGluZGljYXRlIHdoZXRoZXIgdGhhdCBpcyBvdmVyIFVE UCBvciBUQ1AuIFRoZSBwcm9ibGVtIGhlcmUgaXMgd2hhdCBzdWNoIGEgcHJvdG8gbGluZSBpcyBp bnRlbmRlZCB0byBtZWFuIHdoZW4gdGhlcmUgaXMgSUNFIGNhbmRpZGF0ZXMgb2YgVURQIGFuZCBU Q1AuIEJ1dCBvaywgbGV0J3MgYXNzdW1lIHRoYXQgYnJvd3NlciBkbyB1cGRhdGUgYy9tIGxpbmVz IGluIHRoZSB0cmlnZ2VyIHdpdGggdGhlIHNlbGVjdGVkIGNhbmRpZGF0ZSwgYW5kIHRoZXkgSlVT VCBjaGFuZ2UgdGhlIHByb3RvIGxpbmUgdG8gVENQL0RUTFMgaWYgdGhlcmUgYXJlIGp1c3QgVENQ IGNhbmRpZGF0ZXMuIE5vdyB0aGluZyBhYm91dCB0aGlzIHNjZW5hcmlvOg0KDQoxKSBDbGllbnQg aW5pdGlhbCBvZmZlciB3aXRoIFVEUCBhbmQgVENQIGNhbmRpZGF0ZXMuDQoNCjIpIFNlcnZlciBh bnN3ZXJzIHdpdGggYm90aCBVRFAgYW5kIFRDUCBjYW5kaWRhdGVzLg0KDQozLjEpIFVEUCBpcyBz ZWxlY3RlZC4gUmUtb2ZmZXIgaXMgY3JlYXRlZCB3aXRoIGp1c3QgVURQIGNhbmRpZGF0ZXMgKGFz IHBlciBzcGVjKS4NCg0KMy4yKSBvciBUQ1AgaXMgc2VsZWN0ZWQuIFJlLW9mZmVyIGlzIGNyZWF0 ZWQgd2l0aCBqdXN0IFRDUCBjYW5kaWRhdGVzIChhcyBwZXIgc3BlY3MpLg0KDQpJbiBib3RoIDMu MSBhbmQgMy4yIHRoZSAibW9uaXRvcmluZyBOb2RlIiBkb2Vzbid0IG5lZWQgdG8gaW5zcGVjdCB0 aGUgcHJvdG8gbGluZS4gSXQgY2FuIGp1c3QgY2hlY2sgdGhlIHByb3RvY29sIChVRFAgb3IgVENQ KSBvZiAqYW55KiBjYW5kaWRhdGUgaW4gdGhlIG9mZmVyIHRvIGtub3cgd2hldGhlciBVRFAgb3Ig VENQIHdhcyBzZWxlY3RlZC4NCg0KQW0gSSB3cm9uZz8NCg0KWW91IGFyZSBjb3JyZWN0LiBDaGVj a2luZyBjPSBhbmQgbT0gbGluZSBpcyBzaW1wbHkgdG8gYXZvaWQgY2hlY2tpbmcgYW5kIHBhcnNp bmcgSUNFIGNhbmRpZGF0ZXMuIElmIG1vbml0b3JpbmcgY2xpZW50IHdvdWxkIGhhbmRsZSBJQ0Ug Y2FuZGlkYXRlcywgdGhlbiB0aGUgbW9uaXRvcmluZyBjbGllbnQgd291bGQgc3RpbGwgbmVlZCB0 byBmaWd1cmUgb3V0IHdoaWNoIGNhbmRpZGF0ZSBpcyBkZWZhdWx0IHRvIHJlY29yZCBjbGllbnQg bWVkaWEgSVAuLiBLZWVwaW5nIGM9IGFuZCBtPSBsaW5lIGluIHN5bmMgd2l0aCBkZWZhdWx0IGNh bmRpZGF0ZSBvbiB0aGUgY2xpZW50IHNlZW1lZCB0byBjYXVzZSB0aGUgbGVhc3QgYW1vdW50IG9m IHByb2JsZW1zIHdoaWNoIGlzIHdoeSBpdCB3YXMgbGVmdCBpbiBpY2Utc2lwLXNkcC4NCg0KUmVn YXJkcywNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCsKgDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KbWFp bHRvOnJ0Y3dlYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWINCg0K From nobody Wed Jan 30 07:58:43 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1F3126F72 for ; Wed, 30 Jan 2019 07:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trMb9J9t6FUa for ; Wed, 30 Jan 2019 07:58:39 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2ED112426E for ; Wed, 30 Jan 2019 07:58:39 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id j10so15118pga.1 for ; Wed, 30 Jan 2019 07:58:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nTqZPAcRJZp2T06sNHA8sHt268bS2Ro10QX22QHros4=; b=Tfn/DGfJUYFK0F3u15MTRlZtHD7jLSVa0GI2BlCGe68zz7Zro8WNirJBw6aEWqZ9ds yrkMkvnoTx70+YP43B/ChpoBDWRFhos1YqsjEBQbxjaTVR1oYjunlISeSBbJqhQXxDUm V1373LrSLjK4Uc8Y6E+MnGqSKQsMNei5jOnpElBjEI65+LK+L0o224HR/USfiMjCocXy vEU3f5KZ7J09mRuSmEnHrMd92UsJG5NHTcFWrPJlDPaAK2cNJt05FRwD3JXf1qd9w6Wk HQji5swQG+WO9nqwkWZVq9vpVyPcSg74FoVFJlFw3fmMp3rseJWgS2W4mmPUS3lXba25 mcfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nTqZPAcRJZp2T06sNHA8sHt268bS2Ro10QX22QHros4=; b=J8spvtifXq6kOyco/WJmSGzkOULZG/DcCEmNl+a9pRqtPVe11uwcUH8Ej9v9A24+JX LsL3wEgV1ZbufGlKciHpijsT3zooau+G0SB7rD09dXsRULf/I0HdLrBPNBSV3K0RNxEZ fNuSdQgFUOtocQGavfMpxgVAGH5WTQvj5g0/yQYnketrW2jzEV1Z8Aq4gKHAu6vzVKXw xVFFm2QCn9dHQVBzR5yH2uTX43kL5ng9WC63QC/8DcVz1e6VBMzW5Yz7Dz1nP5YpCCL/ MqxVcVgEk37i04APn9utj8cg5Lwxd5XiIhb17lcBsx6z8u+9YMoaCky5z2vZXtl4IVgI mW/w== X-Gm-Message-State: AJcUukcH1FGncQ2k7Q9L2vo1vBC6Eacu+kJykTxTGvWWsmZ5jFs4s5xO mjARqE7/fqgEaIl3iguJKfJlDmIDPPk= X-Google-Smtp-Source: ALg8bN6nmftapTdiad/J3AAHUeFBx58WuSAImvMTRRYv43HdYiAVk8TtRLEBLRzuINcwNlDa9xugtg== X-Received: by 2002:a63:f901:: with SMTP id h1mr28075019pgi.154.1548863919185; Wed, 30 Jan 2019 07:58:39 -0800 (PST) Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com. [209.85.215.182]) by smtp.gmail.com with ESMTPSA id g3sm5886455pfe.37.2019.01.30.07.58.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Jan 2019 07:58:38 -0800 (PST) Received: by mail-pg1-f182.google.com with SMTP id y4so10482022pgc.12 for ; Wed, 30 Jan 2019 07:58:38 -0800 (PST) X-Received: by 2002:a62:4bcf:: with SMTP id d76mr32462977pfj.170.1548863917776; Wed, 30 Jan 2019 07:58:37 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <937eade0-f126-472a-d990-aa4b65ea5a82@nostrum.com> In-Reply-To: From: Roman Shpount Date: Wed, 30 Jan 2019 10:58:27 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Cc: Adam Roach , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000009fe7070580aefbcf" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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, 30 Jan 2019 15:58:42 -0000 --0000000000009fe7070580aefbcf Content-Type: text/plain; charset="UTF-8" On Mon, Jan 28, 2019 at 8:25 PM Eric Rescorla wrote: > On Mon, Jan 28, 2019 at 5:10 PM Adam Roach wrote: > >> [as an individual] >> >> On 1/28/19 6:55 PM, Eric Rescorla wrote: >> > it's unnecessary complexity >> >> >> To make sure we're not all overlooking something that is obvious to you >> -- can you describe the complexity involved here? >> > Having to condition what you put in the proto line depending on the > candidates is more complexity than not having to do so. > > I just want to note that m= line containing the proto field already depends on ICE candidates present in the offer and that the port in m= line already required to be updated whenever default (active in JSEP which is even more common) candidate changes. We are talking about dynamically generated string and discussing complexity of updating one or two parts of this string based on the same condition while keeping them in sync. I would assume additional complexity required for this is minimal. Regards, _____________ Roman Shpount --0000000000009fe7070580aefbcf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jan 28, 2019 at 8:25 PM E= ric Rescorla <ekr@rtfm.com> wrote= :
On Mon, Jan 28, = 2019 at 5:10 PM Adam Roach <adam@nostrum.com> wrote:
[as an individual]

On 1/28/19 6:55 PM, Eric Rescorla wrote:
> it's unnecessary complexity


To make sure we're not all overlooking something that is obvious to you=
-- can you describe the complexity involved here?
Havi= ng to condition what you put in the proto line depending on the candidates = is more complexity than not having to do so.

=
I just want to note that m=3D line containing the p= roto field already depends on ICE candidates present in the offer and that = the port in m=3D line already required to be updated whenever default (acti= ve in JSEP which is even more common) candidate changes. We are talking abo= ut dynamically generated string and discussing complexity of updating one o= r two parts of this string based on the same condition while keeping them i= n sync. I would assume additional complexity required for this is minimal.<= /div>

Regards,
_____________
Roman Shpount
=C2=A0
--0000000000009fe7070580aefbcf-- From nobody Wed Jan 30 13:22:29 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56447130FF0 for ; Wed, 30 Jan 2019 13:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehQ62de9Sjax for ; Wed, 30 Jan 2019 13:22:24 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB78130FE6 for ; Wed, 30 Jan 2019 13:22:24 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id u89-v6so864269lje.1 for ; Wed, 30 Jan 2019 13:22:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5rzC0C5u0KGf2x/bMpynd2OaUCQgShh9NeF0j/56TkY=; b=gyzAyKuSdVtO+hiw8RFPdFXecNAaJBDgmoGOf+gE28I79plQbA5QL/o0YRMtiO513X zYEU3eYLAeUnUrmpcBrUNJogHEfs9KAQ+lljOdpfZZnRONTeag6RuIFsfxuRf3Q6hSbr kikdZulaJsbWZ93rDfGQQYP9rkCReOvg0ULvN6IMYWShCfS7zQvKheB2XOI0CiRl7pOe 4yURygkuY/5J5TYtHMHzRLNtSTAjAYwyBw9bdQD4/eTkPr7C5deChgOPEXuPV0sF0LK4 RfazfUxjru6JK2Idwon3hcYN8U0nTGLLTMmTonNM8VFeAbaRWpD37rsRGLXjKRk88sp5 +zJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5rzC0C5u0KGf2x/bMpynd2OaUCQgShh9NeF0j/56TkY=; b=WGA93w6oc/80Alu/0MdtAJ4qKJzmgzgb/j12I6eoQzrofBj01SESLe9O2MbUZ3nZGs O0FY6ppi95j/yPKg4uZzihbLFz6gHnjVFuw7YIT0CNVIkbfZEzS9p1v17NfHIxwCucMd fTkTBPiegcSDUQPtijP7mKUtSwiGqX11Oej/BazifJHp5xOCDegFXClouo7AjkstnbbS 8tGCcomvwyNxxU5s7rUGuIMjrL8MehLeV+sYbnjycXyTdJhgGhV/5rL0M+r/WyhTtVP/ lENfPuXIAgSRlEbnK0amYTU7PCrJXGAUabaUlxoGoMWpwjd6Kx8nOBi1R+/bqfkQWuo0 qYxA== X-Gm-Message-State: AJcUukchqdRZYD7fR8gJ2N/wgTxpNLYF/yMg0y7bTvtmtvVSkzuyg9Ps 3lcps2mMVgNRYORwWOhOsMTZzlLvakh/ghCSQDQ/Zw== X-Google-Smtp-Source: ALg8bN5wuMpXPWNqEkvO+eXFsPLnf63EGZ+/8Mwdu0OZ1t5M3hz67xoCCv4HehKiU6oCj2rFZ3IzbVx2/sU6CsR4sik= X-Received: by 2002:a2e:9dcb:: with SMTP id x11-v6mr22576318ljj.158.1548883342260; Wed, 30 Jan 2019 13:22:22 -0800 (PST) MIME-Version: 1.0 References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com> In-Reply-To: From: Eric Rescorla Date: Wed, 30 Jan 2019 13:21:44 -0800 Message-ID: To: Christer Holmberg Cc: Roman Shpount , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000006a0d250580b38106" Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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, 30 Jan 2019 21:22:27 -0000 --0000000000006a0d250580b38106 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 30, 2019 at 6:21 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>> I understand your point. But still I don't understand the purpose of > the new draft (set TCP/DTLS/etc in proto line if there are just TCP > candidates in the offer). > >> > >> The purpose is standard compliance. If nominated candidate is UDP, > proto line should be UDP. If nominated candidate is TCP, proto line should > be TCP. > >> If you do not care about the c= and m= line, put the dummy values and > UDP there, but this breaks legacy interop by causing ICE mismatch. > >> > >> This is two separate statements that don't necessarily follow form each > other > >> > >>1. This is a matter of standards compliance. > >>2. It breaks legacy interop > > > >I agree on point (1). I'm still waiting for someone to demonstrate point > (2) > > There are networks where nodes (not always SBCs) use the c/m- information > to control network resources (e.g., radio bandwidth). Whether UDP vs TCP > will have a major impact I don't know, but the point is that the c/m- > information IS used. > > Whether the WG has agreed that the c/m- information is "meaningless" in > the JSEP API I don't know, but it for sure is not "meaningless" on the wire. > We're talking solely about the format field in this discussion, and the whole import of the decision have a fixed field was that in fact we agreed it was meaningless. -Ekr > Regards, > > Christer > > > > > > > > > > Putting UDP proto and address from TCP candidate breaks legacy interop as > well, but it is typically localized to provider managed server, so it is > possible to patch around this either in JS client or on the server to treat > WebRTC clients differently. Alternatively, WebRTC clients can add a couple > lines of code and become compliant with the RFC they decided to implement > and remove the need for patching. > > Of course, if browser follow the ICE spec and set the selected candidate > in the c/m lines, they must also indicate whether that is over UDP or TCP. > The problem here is what such a proto line is intended to mean when there > is ICE candidates of UDP and TCP. But ok, let's assume that browser do > update c/m lines in the trigger with the selected candidate, and they JUST > change the proto line to TCP/DTLS if there are just TCP candidates. Now > thing about this scenario: > > 1) Client initial offer with UDP and TCP candidates. > > 2) Server answers with both UDP and TCP candidates. > > 3.1) UDP is selected. Re-offer is created with just UDP candidates (as per > spec). > > 3.2) or TCP is selected. Re-offer is created with just TCP candidates (as > per specs). > > In both 3.1 and 3.2 the "monitoring Node" doesn't need to inspect the > proto line. It can just check the protocol (UDP or TCP) of *any* candidate > in the offer to know whether UDP or TCP was selected. > > Am I wrong? > > You are correct. Checking c= and m= line is simply to avoid checking and > parsing ICE candidates. If monitoring client would handle ICE candidates, > then the monitoring client would still need to figure out which candidate > is default to record client media IP.. Keeping c= and m= line in sync with > default candidate on the client seemed to cause the least amount of > problems which is why it was left in ice-sip-sdp. > > Regards, > _____________ > Roman Shpount > > _______________________________________________ > rtcweb mailing list > mailto:rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --0000000000006a0d250580b38106 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 30, 2019 at 6:21 AM Chris= ter Holmberg <christer= .holmberg@ericsson.com> wrote:
Hi,

>>> I understand your point. But still I don't understand the = purpose of the new draft (set TCP/DTLS/etc in proto line if there are just = TCP candidates in the offer).
>>=C2=A0
>> The purpose is standard compliance. If nominated candidate is UDP,= proto line should be UDP. If nominated candidate is TCP, proto line should= be TCP.
>> If you do not care about the c=3D and m=3D line, put the dummy val= ues and UDP there, but this breaks legacy interop by causing ICE mismatch.<= br> >>
>> This is two separate statements that don't necessarily follow = form each other
>>
>>1. This is a matter of standards compliance.
>>2. It breaks legacy interop
>
>I agree on point (1). I'm still waiting for someone to demonstrate = point (2)

There are networks where nodes (not always SBCs) use the c/m- information t= o control network resources (e.g., radio bandwidth). Whether UDP vs TCP wil= l have a major impact I don't know, but the point is that the c/m- info= rmation IS used.

Whether the WG has agreed that the c/m- information is "meaningless&qu= ot; in the JSEP API I don't know, but it for sure is not "meaningl= ess" on the wire.

We're talkin= g solely about the format field in this discussion, and the whole import of= the decision have a fixed field was that in fact we agreed it was meaningl= ess.

-Ekr


Regards,

Christer









Putting UDP proto and address from TCP candidate breaks legacy interop as w= ell, but it is typically localized to provider managed server, so it is pos= sible to patch around this either in JS client or on the server to treat We= bRTC clients differently. Alternatively, WebRTC clients can add a couple li= nes of code and become compliant with the RFC they decided to implement and= remove the need for patching.

Of course, if browser follow the ICE spec and set the selected candidate in= the c/m lines, they must also indicate whether that is over UDP or TCP. Th= e problem here is what such a proto line is intended to mean when there is = ICE candidates of UDP and TCP. But ok, let's assume that browser do upd= ate c/m lines in the trigger with the selected candidate, and they JUST cha= nge the proto line to TCP/DTLS if there are just TCP candidates. Now thing = about this scenario:

1) Client initial offer with UDP and TCP candidates.

2) Server answers with both UDP and TCP candidates.

3.1) UDP is selected. Re-offer is created with just UDP candidates (as per = spec).

3.2) or TCP is selected. Re-offer is created with just TCP candidates (as p= er specs).

In both 3.1 and 3.2 the "monitoring Node" doesn't need to ins= pect the proto line. It can just check the protocol (UDP or TCP) of *any* c= andidate in the offer to know whether UDP or TCP was selected.

Am I wrong?

You are correct. Checking c=3D and m=3D line is simply to avoid checking an= d parsing ICE candidates. If monitoring client would handle ICE candidates,= then the monitoring client would still need to figure out which candidate = is default to record client media IP.. Keeping c=3D and m=3D line in sync w= ith default candidate on the client seemed to cause the least amount of pro= blems which is why it was left in ice-sip-sdp.

Regards,
_____________
Roman Shpount
=C2=A0
_______________________________________________
rtcweb mailing list
mailto:rtcweb@ietf.org=
https://www.ietf.org/mailman/listinfo/rtcweb

--0000000000006a0d250580b38106-- From nobody Wed Jan 30 13:56:46 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58330130FF9 for ; Wed, 30 Jan 2019 13:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.853 X-Spam-Level: X-Spam-Status: No, score=-8.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=KgwwDoeO; dkim=pass (1024-bit key) header.d=ericsson.com header.b=FeOyX7+4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdDUAyi57Slf for ; Wed, 30 Jan 2019 13:56:42 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE15A130F0D for ; Wed, 30 Jan 2019 13:56:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1548885399; x=1551477399; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=d9kuXHVLaN3ylB6W687yzFea1HAEzjDn3v0m+G1vfjU=; b=KgwwDoeOM5kHa19PgLst3wL96XiN/vaDJkZL63553RamXVtMqbJVVRbGtijIaIAU KJ8UgRe/q9wSXALRCLplMV8EWDP55nZu7rcDFiywvzNZOKVEIapDxM+iffcl5bep ST/XUf46lC0PISbduil/n2f5F6btjjHFpCksTsEz++s=; X-AuditID: c1b4fb30-41b3a9e00000355c-37-5c521d97d85c Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6E.A2.13660.79D125C5; Wed, 30 Jan 2019 22:56:39 +0100 (CET) Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 30 Jan 2019 22:56:37 +0100 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 30 Jan 2019 22:56:37 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=d9kuXHVLaN3ylB6W687yzFea1HAEzjDn3v0m+G1vfjU=; b=FeOyX7+4whJA/IucWGVSNj4IC/VugZsNIcu2Q+cjL4Qff620gpKe8gW0apyi8ynTK7gvZJgNBlV5RIoIgTn0hpDm8J12PjdSFAaaBJhPrJB4724zFO6EKI1u3iTeR0VR3oLKnxXUZI/eRugvyQjqKYQOM2jPks+IZOENi4aotE4= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4202.eurprd07.prod.outlook.com (20.176.166.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.15; Wed, 30 Jan 2019 21:56:34 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0%4]) with mapi id 15.20.1601.008; Wed, 30 Jan 2019 21:56:34 +0000 From: Christer Holmberg To: Eric Rescorla CC: Roman Shpount , RTCWeb IETF Thread-Topic: [rtcweb] Proposal to break the ICE impasse Thread-Index: AQHUtCoOCID4ifgvbk+6P/h8fwfLKaXBz0cAgAEnOzeAAlkQgIAAHScAgAADHICAAAKbgIAAA+MAgAAEr4CAAIGVgIAAMCmAgAAaH4CAAEXWAIAABXMAgAAHuACAAARIgIAABLmAgAAGVYCAAChigIABNcmAgABT5ACAAAZo7A== Date: Wed, 30 Jan 2019 21:56:34 +0000 Message-ID: References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [37.136.56.89] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB4202; 6:lsqooMA6y5g5LpPYHOezpa3z1v+dBViuM7AjFKRSwgqlGV1dYDG3XE8X0GPYbpA9g1rTgsfLAjjmoBJI0lAaUl9KZT2JQtXWEUjoy9sjHlokz62oFWRd/PzMxlnIDPCKfZhIDln3vDWmzCYtvc4S/RZ6W43iIxLjCYI2UyXwF9z4Zw02dsvz76eKaFPybIH9osSnm0lkbdR49yw4hjSI8NSYvXCm7IME3keesSEvh0UaxS9kplcJwYf9hqm0KoX8Vkn13ccgOlfbjozlD/qy1YG7nFmvaJus9PpIrUCFiKa1OpoT78X0TkZtLQApoLgFhPzYEhc0fCT26Scom5ndCUUOi3X5DvaMo3JCJADlQO/gYDVoKOBe37cfa+jyH2kqkI4U+BMIHNfu/FN8jjC1Mm0Kr0nZQDBlqpcJg0dha5Bne5DD7vRedAmFW6tFPuaIGYj8wSczdXm2hzTv+ALWdA==; 5:gnMI3d+cYPD3wEuCvcFCtz63+5OkHm6d04UEbbThlH0t7zJ51f7qX+zG1lhGuL/5F0qeCpOKVqFQof5pPN0mhlMcKnWtCxmFaE8+op5ettyv7Sg3qCnALSOrJlkGlyF8HyHxY6yhas5SOd4gzaqwwhVqAJT6FO0gw9utKdP9KrfvZ8sVVpqzg6+qQ6cyX2iUi4J9S4xxU0FFfFiR4tEBng==; 7:R+5P2R292wr95PK0IGuC+dhKT4jbi9lydBS41mFcYnlrNfOcaCtRzhVIgsRNmFDACm9bbjAG2vQvgf4JVpYyI25vUs8bGpst0XhOmWUud5qjP/USe0YfXD3VxRtAe1nrSNYgIugnKNh/4g+9jaRxsA== x-ms-office365-filtering-correlation-id: 246074aa-8290-4a32-586a-08d686fdcd40 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4202; x-ms-traffictypediagnostic: HE1PR07MB4202: x-microsoft-antispam-prvs: x-forefront-prvs: 0933E9FD8D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(136003)(366004)(396003)(376002)(189003)(199004)(256004)(3846002)(6116002)(33656002)(93886005)(106356001)(6246003)(19627405001)(55016002)(478600001)(6436002)(2906002)(229853002)(6916009)(8936002)(316002)(8676002)(81166006)(14454004)(86362001)(81156014)(54906003)(99286004)(105586002)(97736004)(7736002)(76176011)(102836004)(186003)(54896002)(71190400001)(71200400001)(26005)(7696005)(6506007)(9686003)(11346002)(476003)(68736007)(486006)(4744005)(44832011)(74316002)(66066001)(446003)(53936002)(6606003)(4326008)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4202; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 11k/WgAI753vLzKB1lX3dyJ3qhY2MVZsy7Um96PBrRvipE3RkudUvKG7wNLWL1pa0+hEPb1D2idd0fzNlE8621/GaQpg1qD2l/lXNpyeyUV7Xz7SI6OrXsEuTcgLVfo5cSgIRrJMbuyZ7QQV/uaOU7eEgjZj4hc2vGcG9KILLZQx8yCato4/J5jbj0sOkNhn7zs3QPh31FeHVpH8yJzeKUOnUo/Tv7x2BhcoiYBOp8z+bv6IqmlFrHrJ9W0yhktNHiqqgijQM4ld1N7MqM9fPEZWl9fzwuDMTrU7r9AAFtoMJXojdyzyu8aaBcIA86RyXBYEq8wXv56T924uK/bIKeMpEb+OmboWXiWLR0Z+9y4LDnv7FfMlDdH0T3YUuKndApgiQ6HQ/jjZYJXwgOBZyQpzfHJw8cJTvXINgp/Xkzo= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3161B70E7CA6FD9AED3B8EC093900HE1PR07MB3161eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 246074aa-8290-4a32-586a-08d686fdcd40 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2019 21:56:34.6296 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4202 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SX0hTYRjG+c45246rxbep+WIJsvRGzX9YzShRChpFZBakMtDVDirq1HNM Mryw1NQpYSwzTZvhtOUfxLmyrNBkkX/S1vCmXVSoJKYh5bBMG7WdBd793vd54Pmel48mZYOC QDpHW8ywWnWeXCimmlOH2P1NQSmqaOv3eIVpeUakuGtrJBV9rmpRIqk0GjcIpX7+Bql03C5M JtPFRzRMXk4Jw0YlZIqzp6cryMJnQVf6V2qpcvQDdMiHBhwHZutLoQ6JaRm2Ihhor/IO6whs fZUkPxgJ6Jm0eBQKN5Dg+vQE8YqegHvNN722OQSL5mpCh2haiBVQ5wp3h/jhYPi9NU65mcTH oXL4LXJbfPEhsPdH8BYFrM/qKJ6HETQPF7mZwqHg+NWF3CzBKhipH/FGDeyALxXjArfgg89C 1evHhJsR3g0/J3sJPisAHAsGgi+KwfjiHcmzPyzNuwS8Xw0j3Z+9+2B483EB8RwEdkOdpyTg 6yKoqp31mk7DqG5KyAsfECwb7CJeCANLfY83LRdsw9c8hwC8F5zO816/AGyjfzwJMszAw74q 1IAiWrY9lucCcD76ilo8raUw0bxA8ftoWJ0xkDyHQ9eDZS9HwYBzGm3ftyNRN/LnGO5iflZs bCTD5lziuAJtpJYpNqN/X+mVZTP6KVpaTBpDmEbynRLr2lmVTKAu4UrzxxDQpNxPErN5RiWT aNSlVxm2IIO9nMdwY2gPTckDJFsyqUqGs9TFTC7DFDLsf5WgfQLLkdR/IynxxGpGqr2sTd+x YkKWKdNqelHY4EyLviaw7VtyyHpv68HSA4b72Y3xwQll8XfShk5Ns5qS9GMp5y60i5XOicxO Yk3sf3Lrvfl5PxOmMcTVbFj9CgM2kqM6w9vMYpmv6bBDlWe5Fau1zO46uh7MSVPSljWhIfs6 mlrn5BSXrY4JI1lO/RfDdxZpRgMAAA== Archived-At: Subject: Re: [rtcweb] Proposal to break the ICE impasse X-BeenThere: rtcweb@ietf.org 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, 30 Jan 2019 21:56:44 -0000 --_000_HE1PR07MB3161B70E7CA6FD9AED3B8EC093900HE1PR07MB3161eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, =85 >>There are networks where nodes (not always SBCs) >> use the c/m- information to control network >> resources (e.g., radio bandwidth). Whether UDP vs >> TCP will have a major impact I don't know, but the >> point is that the c/m- information IS used. >> >> Whether the WG has agreed that the c/m- >> information is "meaningless" in the JSEP API I don't >> know, but it for sure is not "meaningless" on the >> wire. > >We're talking solely about the format field in this >discussion, I assume you meant the proto field? > and the whole import of the decision have a fixed > field was that in fact we agreed it was >meaningless. Perhaps it's meaningless in the JSEP API, and even for WebRTC endpoints, as= they are required to support ICE, but I don't agree on a general statement= that it is meaningless on the wire. There are entities that make policy de= cisions based on the information in the c/m- lines. Regards, Christer --_000_HE1PR07MB3161B70E7CA6FD9AED3B8EC093900HE1PR07MB3161eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


Hi,

=85

>>There are networks where nodes (not always SBCs)
>> use the c/m- information to control network 
>> resources (e.g., radio bandwidth). Whether UDP vs
>> TCP will have a major impact I don't know, but the 
>> point is that the c/m- information IS used.
>>
>> Whether the WG has agreed that the c/m- 
>> information is "meaningless" in the JSEP API I don'= t
>> know, but it for sure is not "meaningless" on the&n= bsp;
>> wire.
>
>We're talking solely about the format field in this 
>discussion, 

I assume you meant the proto field?

> and the whole import of the decision have a fixed
> field was that in fact we agreed it was 
>meaningless.

Perhaps it's meaningless in the JSEP API, and even for WebRTC endpoint= s, as they are required to support ICE, but I don't agree on a general stat= ement that it is meaningless on the wire. There are entities that make poli= cy decisions based on the information in the c/m- lines.
 
Regards,

Christer

--_000_HE1PR07MB3161B70E7CA6FD9AED3B8EC093900HE1PR07MB3161eurp_-- From nobody Thu Jan 31 19:14:26 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9307130ECF for ; Thu, 31 Jan 2019 19:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHG9l8BhfbE9 for ; Thu, 31 Jan 2019 19:14:23 -0800 (PST) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52EB126C01 for ; Thu, 31 Jan 2019 19:14:22 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id u6so2447566plm.8 for ; Thu, 31 Jan 2019 19:14:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bzI9e6dhSaNyiNuyS+bmjXvde8O/aNUPbXnpY/0DOnU=; b=COqs5h2beNETnzLa++GD7RJghu6wMIbOa3mLnodvLjVH977tNkOQXYTtMEFGRmYYtm 04IqZYRyEnfI1nDGzeGqn5/hrRa9FuZRge21cOHypA9ZdKZz1bdJcesI1c5gWrIz5aB/ gOc76L18bQxXsE6zuau1JZavJfHwq3yUqbQSHFeyva50ZOJTXi4Oo842/Tk0IbjvfZ13 s+rVNeAW9Qf2+JOTju//bEtZ3wyGGVKXUJ/iCMSMl4UZplmT0SMZbMd91I0Wmio3hPsn 28hKBlc+32OqFhvVsKh7kapHJlLX8ex+BEjJPL4O5WQ7XMfp2HscMmmIbViBmSjJLA5G yQKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bzI9e6dhSaNyiNuyS+bmjXvde8O/aNUPbXnpY/0DOnU=; b=Cs1EcZjp5S49nzLLUEIdSzYm39lorDllAXlE6UJ21ZniM5U7FX7l+GEz6NhN/QMnX3 Lg6V6cyxJc2oOrckbZJh8kBnQ7je4HuxDLDuN/kpsmb1zzKIt/Ojag9QjgDRJduaWzK3 H9FMzF4TYcKKuJWk6Iwt+ji45WdOiLeDr4of9APxkhxHTLMnfWxT0zlP2IVWo21zD6Hp WGNk5BW51pScvKRxFBz5lTXDFfIucgcjnQOMUX+64NEGkj0nrCtrZOlDUvjFk1HksuxY /vo8x/fzbVkEyJIeenW1zuok1BYugJb8MZqgqE35aBgLtl46/JnZLJ7synJ9AQ/Ui1mH /oUw== X-Gm-Message-State: AJcUukd7NQ5RQmzDNWxVImVCAPO0U2i1kayvmh20A2B1CA5zX0J0rxt7 m+FNK3NmpcReDYaMWE4dV+iQhg== X-Google-Smtp-Source: ALg8bN5qkhAN+E29NChoEtBWlpg3IGO+5IUqxeBtZgS1YDO6f7iRuGKjLy4qGAotW7RhiqZvsU/ILg== X-Received: by 2002:a17:902:2969:: with SMTP id g96mr37345142plb.295.1548990862280; Thu, 31 Jan 2019 19:14:22 -0800 (PST) Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com. [209.85.210.175]) by smtp.gmail.com with ESMTPSA id h74sm15017473pfd.35.2019.01.31.19.14.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Jan 2019 19:14:21 -0800 (PST) Received: by mail-pf1-f175.google.com with SMTP id h3so2466306pfg.1; Thu, 31 Jan 2019 19:14:21 -0800 (PST) X-Received: by 2002:a63:df13:: with SMTP id u19mr34028331pgg.294.1548990861376; Thu, 31 Jan 2019 19:14:21 -0800 (PST) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> In-Reply-To: <874l9ousuk.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Thu, 31 Jan 2019 22:14:11 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Dale R. Worley" Cc: mmusic WG , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000000d81c10580cc8a6b" Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org 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: Fri, 01 Feb 2019 03:14:26 -0000 --0000000000000d81c10580cc8a6b Content-Type: text/plain; charset="UTF-8" Hi Dale, This is exactly what I've thought. I have added RtcWeb group to the email, since they have a draft which describes using MDNS candidates: rtcweb-mdns-ice-candidates ( https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02). This draft talks about replacing host candidates addresses with MDNS FQDN. What it does not talk about is what ends up in c=/m= line in this case. In the currently Chrome MDNS experiment, Chrome produces something like this: v=0 o=- 5433632304511147701 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio a=msid-semantic: WMS 6bb347f4-f699-4522-99ea-215c10022f50 m=audio 59372 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126 *c=IN IP6* a=rtcp:9 IN IP4 0.0.0.0 a=candidate:1962264367 1 udp 2122260223 3557773f-5f01-46a4-aa14-54ab35b3d778.local 59372 typ host generation 0 network-id 1 network-cost 10 a=candidate:980827103 1 tcp 1518280447 3557773f-5f01-46a4-aa14-54ab35b3d778.local 9 typ host tcptype active generation 0 network-id 1 network-cost 10 a=ice-ufrag:3iia a=ice-pwd:HMo0mGLq8nYb9pfnG/nH3pNI a=ice-options:trickle a=fingerprint:sha-256 8D:22:EF:E4:8B:7F:B3:F0:69:2E:B2:1D:4B:F1:6F:DE:62:BE:B8:DC:92:A3:F7:E5:1B:E8:87:6D:BE:E2:44:48 a=setup:actpass a=mid:audio a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=sendrecv a=rtcp-mux a=rtpmap:111 opus/48000/2 a=rtcp-fb:111 transport-cc a=fmtp:111 minptime=10;useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:110 telephone-event/48000 a=rtpmap:112 telephone-event/32000 a=rtpmap:113 telephone-event/16000 a=rtpmap:126 telephone-event/8000 a=ssrc:4224017887 cname:aHDhJbcPUEXkWfRL a=ssrc:4224017887 msid:6bb347f4-f699-4522-99ea-215c10022f50 ffd9edfb-e99c-4cc3-a1dd-817f0327d021 a=ssrc:4224017887 mslabel:6bb347f4-f699-4522-99ea-215c10022f50 a=ssrc:4224017887 label:ffd9edfb-e99c-4cc3-a1dd-817f0327d021 As you can see c= line is "c=IN IP6" and is missing the contact address, which so far breaks every client except Chrome, including Firefox. I was curious what should go into the c= line and if this would work anywhere, or if this is completely misguided Regards, _____________ Roman Shpount On Thu, Jan 31, 2019 at 9:48 PM Dale R. Worley wrote: > Roman Shpount writes: > > I wanted to see if it was ever decided if c= line should contain IN IP4 > or > > IN IP6 when default ICE candidate address contains FQDN. > > > > For instance, in the following SDP: > > > > m=audio 59372 UDP/TLS/RTP/SAVPF 0 > > *c=IN IP6 3557773f-5f01-46a4-aa14-54ab35b3d778.local * > > a=rtcp:9 IN IP4 0.0.0.0 > > a=candidate:1962264367 1 udp 2122260223 > > 3557773f-5f01-46a4-aa14-54ab35b3d778.local 59372 typ host > > a=ice-ufrag:3iia > > a=ice-pwd:HMo0mGLq8nYb9pfnG/nH3pNI > > a=rtcp-mux > > > > Is it correct to use "c=IN IP6 > 3557773f-5f01-46a4-aa14-54ab35b3d778.local " > > or should it be "c=IN IP4 3557773f-5f01-46a4-aa14-54ab35b3d778.local"? > > In regard to ICE *candidates*, RFC 8445 makes it clear that a candidate > is an IP address, not an FQDN: > > 2.1. Gathering Candidates > > In order to execute ICE, an ICE agent identifies and gathers one or > more address candidates. A candidate has a transport address -- a > combination of IP address and port for a particular transport > protocol (with only UDP specified here). There are different types > of candidates; some are derived from physical or logical network > interfaces, and others are discoverable via STUN and TURN. > > The discussion of "default candidates" is a little vague due to the fact > that the ICE specification factors out ICE from any protocol that uses > it, but the default candidate is always a *candidate* and thus an > address, not an FQDN: > > 5.2. Lite Implementation Procedures > > Next, an agent chooses a default candidate for each component of each > data stream. If a host is IPv4 only, there would only be one > candidate for each component of each data stream; therefore, that > candidate is the default. If a host is IPv6 only, the default > candidate would typically be a globally scoped IPv6 address. Dual- > stack hosts SHOULD allow configuration whether IPv4 or IPv6 is used > for the default candidate, and the configuration needs to be based on > which one its administrator believes has a higher chance of success > in the current network environment. > > > 5.3. Exchanging Candidate Information > > The using protocol may (or may not) need to deal with backwards > compatibility with older implementations that do not support ICE. If > a fallback mechanism to non-ICE is supported and is being used, then > presumably the using protocol provides a way of conveying the default > candidate (its IP address and port) in addition to the ICE > parameters. > > Dale > --0000000000000d81c10580cc8a6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dale,

<= div>This is exactly what I've thought. I have added RtcWeb group to the= email, since they have a draft which describes using MDNS candidates:=C2= =A0rtcweb-mdns-ice-candidates (https://tools.ietf.o= rg/html/draft-ietf-rtcweb-mdns-ice-candidates-02). This draft talks abo= ut replacing host candidates addresses with MDNS FQDN. What it does not tal= k about is what ends up in c=3D/m=3D line in this case. In the currently Ch= rome MDNS experiment, Chrome produces something like this:

v=3D0
o=3D- 5433632304511147701 2 IN IP4 127.0.0.1
s=3D-
t=3D0 0
a=3Dgroup:BUNDLE audio
a=3Dmsid-semantic: WMS 6bb347f4-f699-4522-99ea-215c10022f50
m=3Daudio 59372 UDP/TLS/RTP/SAVPF 111 1= 03 104 9 0 8 106 105 13 110 112 113 126
c=3DIN IP6
a=3Drtcp:9 IN IP4 = 0.0.0.0
a=3Dcandidate:1962264367 1 udp= 2122260223 3557773f-5f01-46a4-aa14-54ab35b3d778.local 59372 typ host gener= ation 0 network-id 1 network-cost 10
a= =3Dcandidate:980827103 1 tcp 1518280447 3557773f-5f01-46a4-aa14-54ab35b3d77= 8.local 9 typ host tcptype active generation 0 network-id 1 network-cost 10=
a=3Dice-ufrag:3iia
a=3Dice-pwd:HMo0mGLq8nYb9pfnG/nH3pNI
a=3Dice-options:trickle
a=3Dfingerprint:sha-256 8D:22:EF:E4:8B:7F:B3:F0:69:2E:B2:1D:4B:F1:6F:DE= :62:BE:B8:DC:92:A3:F7:E5:1B:E8:87:6D:BE:E2:44:48
a=3Dsetup:actpass
a=3Dmid:a= udio
a=3Dextmap:1 urn:ietf:params:rtp-= hdrext:ssrc-audio-level
a=3Dsendrecv
a=3Drtcp-mux
a=3Drtpmap:111 opus/48000/2
a=3Drtcp-fb:111 transport-cc
a=3Dfmtp= :111 minptime=3D10;useinbandfec=3D1
a= =3Drtpmap:103 ISAC/16000
a=3Drtpmap:10= 4 ISAC/32000
a=3Drtpmap:9 G722/8000
a=3Drtpmap:0 PCMU/8000
a=3Drtpmap:8 PCMA/8000
a=3Drtpmap:106 CN/32000
a=3Drtp= map:105 CN/16000
a=3Drtpmap:13 CN/8000=
a=3Drtpmap:110 telephone-event/48000<= /div>
a=3Drtpmap:112 telephone-event/32000
a=3Drtpmap:113 telephone-event/16000
a=3Drtpmap:126 telephone-event/8000
a=3Dssrc:4224017887 cname:aHDhJbcPUEXkWfRL=
a=3Dssrc:4224017887 msid:6bb347f4-f69= 9-4522-99ea-215c10022f50 ffd9edfb-e99c-4cc3-a1dd-817f0327d021
a=3Dssrc:4224017887 mslabel:6bb347f4-f699-4522-99ea= -215c10022f50
a=3Dssrc:4224017887 labe= l:ffd9edfb-e99c-4cc3-a1dd-817f0327d021

As you can see c= =3D line is "c=3DIN IP6" and is missing the contact addres= s, which so far breaks every client except Chrome, including Firefox.
=

I was curious what should go into= the c=3D line and if this would work anywhere, or if this is completely mi= sguided

Regards,
<= div>
______= _______
Roman Shpount


On Thu, Jan 31, 2= 019 at 9:48 PM Dale R. Worley <worley@ariadne.com> wrote:
Roman Shpount <roman@telurix.com> writes:
> I wanted to see if it was ever decided if c=3D line should contain IN = IP4 or
> IN IP6 when default ICE candidate address contains FQDN.
>
> For instance, in the following SDP:
>
> m=3Daudio 59372 UDP/TLS/RTP/SAVPF 0
> *c=3DIN IP6 3557773f-5f01-46a4-aa14-54ab35b3d778.local *
> a=3Drtcp:9 IN IP4 0.0.0.0
> a=3Dcandidate:1962264367 1 udp 2122260223
> 3557773f-5f01-46a4-aa14-54ab35b3d778.local 59372 typ host
> a=3Dice-ufrag:3iia
> a=3Dice-pwd:HMo0mGLq8nYb9pfnG/nH3pNI
> a=3Drtcp-mux
>
> Is it correct to use "c=3DIN IP6 3557773f-5f01-46a4-aa14-54ab35b3= d778.local "
> or should it be "c=3DIN IP4 3557773f-5f01-46a4-aa14-54ab35b3d778.= local"?

In regard to ICE *candidates*, RFC 8445 makes it clear that a candidate
is an IP address, not an FQDN:

=C2=A0 =C2=A02.1.=C2=A0 Gathering Candidates

=C2=A0 =C2=A0In order to execute ICE, an ICE agent identifies and gathers o= ne or
=C2=A0 =C2=A0more address candidates.=C2=A0 A candidate has a transport add= ress -- a
=C2=A0 =C2=A0combination of IP address and port for a particular transport<= br> =C2=A0 =C2=A0protocol (with only UDP specified here).=C2=A0 There are diffe= rent types
=C2=A0 =C2=A0of candidates; some are derived from physical or logical netwo= rk
=C2=A0 =C2=A0interfaces, and others are discoverable via STUN and TURN.

The discussion of "default candidates" is a little vague due to t= he fact
that the ICE specification factors out ICE from any protocol that uses
it, but the default candidate is always a *candidate* and thus an
address, not an FQDN:

=C2=A0 =C2=A05.2.=C2=A0 Lite Implementation Procedures

=C2=A0 =C2=A0Next, an agent chooses a default candidate for each component = of each
=C2=A0 =C2=A0data stream.=C2=A0 If a host is IPv4 only, there would only be= one
=C2=A0 =C2=A0candidate for each component of each data stream; therefore, t= hat
=C2=A0 =C2=A0candidate is the default.=C2=A0 If a host is IPv6 only, the de= fault
=C2=A0 =C2=A0candidate would typically be a globally scoped IPv6 address.= =C2=A0 Dual-
=C2=A0 =C2=A0stack hosts SHOULD allow configuration whether IPv4 or IPv6 is= used
=C2=A0 =C2=A0for the default candidate, and the configuration needs to be b= ased on
=C2=A0 =C2=A0which one its administrator believes has a higher chance of su= ccess
=C2=A0 =C2=A0in the current network environment.


=C2=A0 =C2=A05.3.=C2=A0 Exchanging Candidate Information

=C2=A0 =C2=A0The using protocol may (or may not) need to deal with backward= s
=C2=A0 =C2=A0compatibility with older implementations that do not support I= CE.=C2=A0 If
=C2=A0 =C2=A0a fallback mechanism to non-ICE is supported and is being used= , then
=C2=A0 =C2=A0presumably the using protocol provides a way of conveying the = default
=C2=A0 =C2=A0candidate (its IP address and port) in addition to the ICE
=C2=A0 =C2=A0parameters.

Dale
--0000000000000d81c10580cc8a6b-- From nobody Thu Jan 31 19:57:17 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE53B131200 for ; Thu, 31 Jan 2019 19:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.641 X-Spam-Level: X-Spam-Status: No, score=-17.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KorP4rL780K4 for ; Thu, 31 Jan 2019 19:57:06 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4A61311F8 for ; Thu, 31 Jan 2019 19:57:06 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id l14so4641874ioj.5 for ; Thu, 31 Jan 2019 19:57:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8U1Y4Ye3Ux1+pPT9bvBcAgNlPZFyZiff9QTX9l+takY=; b=ZEvwGHqZfpyJ4yqnCF5ux54koFnbgW7XNVT78ufLLujczLQYzpfNketZmgeltON66j vAZEJgb3aTUbZ88CNkCV1UBjEQncu4uxUYGP6MYxB+Tz4YateEFqCY7pVewDlKm3vbyJ wlQN90TdIvVF8RjbBwwZBGkT35ietmjew6ksKWf/dm4ki8cR5jXSYINkRpXeHWdnUAGY ul/TL9QzU4Z7+xz2RFe9C35Ge6l0gm44RZci7apV5ByRHtT0Z/JL4FzlHg93tROGgffl 2gRW13PDBZnfuBW1T2Q99YD3fDV/xiql8UrIu/F2Ee3c132lx0HMeWyNfLXfZMkVnEKu MWAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8U1Y4Ye3Ux1+pPT9bvBcAgNlPZFyZiff9QTX9l+takY=; b=njrQOI6B78tPLTQ5E/BGLyCctcxxrwtdhh4gHTOz63h+GpdRM0L0a6aoPqRjNCbmFg k31Ka74fFrrcWsq4+g1Y9KmbClUqVWKi87ZQdv1xIGmJiHY1NyDBjuKC/TEUkvQxYuR4 +pX1YAv/dd77+WZ1AQhwYmmum/PsZ1EVg5F/hMdqCsLgONbbz5QSUwRs8vKwnedP5Jqw GkKG1BW7sOBB8iCP59aJcRzDCDYFZRqYwtmWXchRgFzCZp9MEvk07L4AfV9X6f6jkKdb bdLusGhaVcgdb5udCMeau5q5uvT4lLrHJIA88k9l6sH2JWoeTm8bH9DA0jUQwCjCsnQK o8YA== X-Gm-Message-State: AHQUAuZDlImPN6nOME9Bp+cY404i4bDf+rx/05izAEjV7eSAHEioTlCe u8JA/HSqhRXRK6GxCJX98esfYiR9OXW5xxIoPHv42mJaX1Y= X-Google-Smtp-Source: AHgI3IaSooz+NGerzgAwtQJ0kqWIcftYFZN8Qm3Bt9yqv9o6zW8XXny1sxVFvPXxfJs4WJGlGGFSxGljXgRzvR39I1c= X-Received: by 2002:a5e:920d:: with SMTP id y13mr19975520iop.95.1548993425106; Thu, 31 Jan 2019 19:57:05 -0800 (PST) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> In-Reply-To: From: Justin Uberti Date: Thu, 31 Jan 2019 19:56:52 -0800 Message-ID: To: Roman Shpount Cc: "Dale R. Worley" , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="000000000000dd91f00580cd2251" Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org 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: Fri, 01 Feb 2019 03:57:10 -0000 --000000000000dd91f00580cd2251 Content-Type: text/plain; charset="UTF-8" I looked into this before and it's pretty clear that ICE candidate and c= line can both contain FQDN. On Thu, Jan 31, 2019 at 7:14 PM Roman Shpount wrote: > Hi Dale, > > This is exactly what I've thought. I have added RtcWeb group to the email, > since they have a draft which describes using MDNS > candidates: rtcweb-mdns-ice-candidates ( > https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02). > This draft talks about replacing host candidates addresses with MDNS FQDN. > What it does not talk about is what ends up in c=/m= line in this case. In > the currently Chrome MDNS experiment, Chrome produces something like this: > > v=0 > o=- 5433632304511147701 2 IN IP4 127.0.0.1 > s=- > t=0 0 > a=group:BUNDLE audio > a=msid-semantic: WMS 6bb347f4-f699-4522-99ea-215c10022f50 > m=audio 59372 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 > 126 > *c=IN IP6* > a=rtcp:9 IN IP4 0.0.0.0 > a=candidate:1962264367 1 udp 2122260223 > 3557773f-5f01-46a4-aa14-54ab35b3d778.local 59372 typ host generation 0 > network-id 1 network-cost 10 > a=candidate:980827103 1 tcp 1518280447 > 3557773f-5f01-46a4-aa14-54ab35b3d778.local 9 typ host tcptype active > generation 0 network-id 1 network-cost 10 > a=ice-ufrag:3iia > a=ice-pwd:HMo0mGLq8nYb9pfnG/nH3pNI > a=ice-options:trickle > a=fingerprint:sha-256 > 8D:22:EF:E4:8B:7F:B3:F0:69:2E:B2:1D:4B:F1:6F:DE:62:BE:B8:DC:92:A3:F7:E5:1B:E8:87:6D:BE:E2:44:48 > a=setup:actpass > a=mid:audio > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=sendrecv > a=rtcp-mux > a=rtpmap:111 opus/48000/2 > a=rtcp-fb:111 transport-cc > a=fmtp:111 minptime=10;useinbandfec=1 > a=rtpmap:103 ISAC/16000 > a=rtpmap:104 ISAC/32000 > a=rtpmap:9 G722/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=rtpmap:106 CN/32000 > a=rtpmap:105 CN/16000 > a=rtpmap:13 CN/8000 > a=rtpmap:110 telephone-event/48000 > a=rtpmap:112 telephone-event/32000 > a=rtpmap:113 telephone-event/16000 > a=rtpmap:126 telephone-event/8000 > a=ssrc:4224017887 cname:aHDhJbcPUEXkWfRL > a=ssrc:4224017887 msid:6bb347f4-f699-4522-99ea-215c10022f50 > ffd9edfb-e99c-4cc3-a1dd-817f0327d021 > a=ssrc:4224017887 mslabel:6bb347f4-f699-4522-99ea-215c10022f50 > a=ssrc:4224017887 label:ffd9edfb-e99c-4cc3-a1dd-817f0327d021 > > As you can see c= line is "c=IN IP6" and is missing the contact address, > which so far breaks every client except Chrome, including Firefox. > > I was curious what should go into the c= line and if this would work > anywhere, or if this is completely misguided > > Regards, > _____________ > Roman Shpount > > > On Thu, Jan 31, 2019 at 9:48 PM Dale R. Worley wrote: > >> Roman Shpount writes: >> > I wanted to see if it was ever decided if c= line should contain IN IP4 >> or >> > IN IP6 when default ICE candidate address contains FQDN. >> > >> > For instance, in the following SDP: >> > >> > m=audio 59372 UDP/TLS/RTP/SAVPF 0 >> > *c=IN IP6 3557773f-5f01-46a4-aa14-54ab35b3d778.local * >> > a=rtcp:9 IN IP4 0.0.0.0 >> > a=candidate:1962264367 1 udp 2122260223 >> > 3557773f-5f01-46a4-aa14-54ab35b3d778.local 59372 typ host >> > a=ice-ufrag:3iia >> > a=ice-pwd:HMo0mGLq8nYb9pfnG/nH3pNI >> > a=rtcp-mux >> > >> > Is it correct to use "c=IN IP6 >> 3557773f-5f01-46a4-aa14-54ab35b3d778.local " >> > or should it be "c=IN IP4 3557773f-5f01-46a4-aa14-54ab35b3d778.local"? >> >> In regard to ICE *candidates*, RFC 8445 makes it clear that a candidate >> is an IP address, not an FQDN: >> >> 2.1. Gathering Candidates >> >> In order to execute ICE, an ICE agent identifies and gathers one or >> more address candidates. A candidate has a transport address -- a >> combination of IP address and port for a particular transport >> protocol (with only UDP specified here). There are different types >> of candidates; some are derived from physical or logical network >> interfaces, and others are discoverable via STUN and TURN. >> >> The discussion of "default candidates" is a little vague due to the fact >> that the ICE specification factors out ICE from any protocol that uses >> it, but the default candidate is always a *candidate* and thus an >> address, not an FQDN: >> >> 5.2. Lite Implementation Procedures >> >> Next, an agent chooses a default candidate for each component of each >> data stream. If a host is IPv4 only, there would only be one >> candidate for each component of each data stream; therefore, that >> candidate is the default. If a host is IPv6 only, the default >> candidate would typically be a globally scoped IPv6 address. Dual- >> stack hosts SHOULD allow configuration whether IPv4 or IPv6 is used >> for the default candidate, and the configuration needs to be based on >> which one its administrator believes has a higher chance of success >> in the current network environment. >> >> >> 5.3. Exchanging Candidate Information >> >> The using protocol may (or may not) need to deal with backwards >> compatibility with older implementations that do not support ICE. If >> a fallback mechanism to non-ICE is supported and is being used, then >> presumably the using protocol provides a way of conveying the default >> candidate (its IP address and port) in addition to the ICE >> parameters. >> >> Dale >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000dd91f00580cd2251 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I looked into this before and it's pretty clear that I= CE candidate and c=3D line can both contain FQDN.

On Thu, Jan 31, 2019 at 7:= 14 PM Roman Shpount <roman@telurix.= com> wrote:
Hi Dale,

This is exactly what I've thought. I have added RtcWeb group to = the email, since they have a draft which describes using MDNS candidates:= =C2=A0rtcweb-mdns-ice-candidates (https://tools.iet= f.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02). This draft talks = about replacing host candidates addresses with MDNS FQDN. What it does not = talk about is what ends up in c=3D/m=3D line in this case. In the currently= Chrome MDNS experiment, Chrome produces something like this:
v=3D0
o=3D- 5433632304511147701 2 IN IP4 127.0.0.1
s=3D-
t=3D0 0
=
a=3Dgroup:BUNDLE audio
a=3Dmsid-semantic: WMS 6bb347f4-f699-4522-99ea-215c10022f5= 0
m=3Daudio 59372 UDP/TLS/RTP/SAVPF 11= 1 103 104 9 0 8 106 105 13 110 112 113 126
c=3DIN IP6
a=3Drtcp:9 IN I= P4 0.0.0.0
a=3Dcandidate:1962264367 1 = udp 2122260223 3557773f-5f01-46a4-aa14-54ab35b3d778.local 59372 typ host ge= neration 0 network-id 1 network-cost 10
a=3Dcandidate:980827103 1 tcp 1518280447 3557773f-5f01-46a4-aa14-54ab35b3= d778.local 9 typ host tcptype active generation 0 network-id 1 network-cost= 10
a=3Dice-ufrag:3iia
a=3Dice-pwd:HMo0mGLq8nYb9pfnG/nH3pNI
a=3Dice-options:trickle
a=3Dfingerprint:sha-256 8D:22:EF:E4:8B:7F:B3:F0:69:2E:B2:1D:4B:F1:6= F:DE:62:BE:B8:DC:92:A3:F7:E5:1B:E8:87:6D:BE:E2:44:48
a=3Dsetup:actpass
a=3Dm= id:audio
a=3Dextmap:1 urn:ietf:params:= rtp-hdrext:ssrc-audio-level
a=3Dsendre= cv
a=3Drtcp-mux
a=3Drtpmap:111 opus/48000/2
a=3Drtcp-fb:111 transport-cc
a=3D= fmtp:111 minptime=3D10;useinbandfec=3D1
a=3Drtpmap:103 ISAC/16000
a=3Drtpmap= :104 ISAC/32000
a=3Drtpmap:9 G722/8000=
a=3Drtpmap:0 PCMU/8000
a=3Drtpmap:8 PCMA/8000
a=3Drtpmap:106 CN/32000
a=3Drt= pmap:105 CN/16000
a=3Drtpmap:13 CN/800= 0
a=3Drtpmap:110 telephone-event/48000=
a=3Drtpmap:112 telephone-event/32000<= /div>
a=3Drtpmap:113 telephone-event/16000
a=3Drtpmap:126 telephone-event/8000
a=3Dssrc:4224017887 cname:aHDhJbcPUEXkWfR= L
a=3Dssrc:4224017887 msid:6bb347f4-f6= 99-4522-99ea-215c10022f50 ffd9edfb-e99c-4cc3-a1dd-817f0327d021
a=3Dssrc:4224017887 mslabel:6bb347f4-f699-4522-99e= a-215c10022f50
a=3Dssrc:4224017887 lab= el:ffd9edfb-e99c-4cc3-a1dd-817f0327d021

As you can see c=3D line is = "c=3DIN IP6" and is missing the contact address, which so = far breaks every client except Chrome, including Firefox.

I was curious what should go into the c=3D line and if this would w= ork anywhere, or if this is completely misguided

R= egards,
_____________
Roman Shpount


On Thu, Jan 31, 20= 19 at 9:48 PM Dale R. Worley <worley@ariadne.com> wrote:
Roman Shpount <roman@telurix.com> writes:
> I wanted to see if it was ever decided if c=3D line should contain IN = IP4 or
> IN IP6 when default ICE candidate address contains FQDN.
>
> For instance, in the following SDP:
>
> m=3Daudio 59372 UDP/TLS/RTP/SAVPF 0
> *c=3DIN IP6 3557773f-5f01-46a4-aa14-54ab35b3d778.local *
> a=3Drtcp:9 IN IP4 0.0.0.0
> a=3Dcandidate:1962264367 1 udp 2122260223
> 3557773f-5f01-46a4-aa14-54ab35b3d778.local 59372 typ host
> a=3Dice-ufrag:3iia
> a=3Dice-pwd:HMo0mGLq8nYb9pfnG/nH3pNI
> a=3Drtcp-mux
>
> Is it correct to use "c=3DIN IP6 3557773f-5f01-46a4-aa14-54ab35b3= d778.local "
> or should it be "c=3DIN IP4 3557773f-5f01-46a4-aa14-54ab35b3d778.= local"?

In regard to ICE *candidates*, RFC 8445 makes it clear that a candidate
is an IP address, not an FQDN:

=C2=A0 =C2=A02.1.=C2=A0 Gathering Candidates

=C2=A0 =C2=A0In order to execute ICE, an ICE agent identifies and gathers o= ne or
=C2=A0 =C2=A0more address candidates.=C2=A0 A candidate has a transport add= ress -- a
=C2=A0 =C2=A0combination of IP address and port for a particular transport<= br> =C2=A0 =C2=A0protocol (with only UDP specified here).=C2=A0 There are diffe= rent types
=C2=A0 =C2=A0of candidates; some are derived from physical or logical netwo= rk
=C2=A0 =C2=A0interfaces, and others are discoverable via STUN and TURN.

The discussion of "default candidates" is a little vague due to t= he fact
that the ICE specification factors out ICE from any protocol that uses
it, but the default candidate is always a *candidate* and thus an
address, not an FQDN:

=C2=A0 =C2=A05.2.=C2=A0 Lite Implementation Procedures

=C2=A0 =C2=A0Next, an agent chooses a default candidate for each component = of each
=C2=A0 =C2=A0data stream.=C2=A0 If a host is IPv4 only, there would only be= one
=C2=A0 =C2=A0candidate for each component of each data stream; therefore, t= hat
=C2=A0 =C2=A0candidate is the default.=C2=A0 If a host is IPv6 only, the de= fault
=C2=A0 =C2=A0candidate would typically be a globally scoped IPv6 address.= =C2=A0 Dual-
=C2=A0 =C2=A0stack hosts SHOULD allow configuration whether IPv4 or IPv6 is= used
=C2=A0 =C2=A0for the default candidate, and the configuration needs to be b= ased on
=C2=A0 =C2=A0which one its administrator believes has a higher chance of su= ccess
=C2=A0 =C2=A0in the current network environment.


=C2=A0 =C2=A05.3.=C2=A0 Exchanging Candidate Information

=C2=A0 =C2=A0The using protocol may (or may not) need to deal with backward= s
=C2=A0 =C2=A0compatibility with older implementations that do not support I= CE.=C2=A0 If
=C2=A0 =C2=A0a fallback mechanism to non-ICE is supported and is being used= , then
=C2=A0 =C2=A0presumably the using protocol provides a way of conveying the = default
=C2=A0 =C2=A0candidate (its IP address and port) in addition to the ICE
=C2=A0 =C2=A0parameters.

Dale
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000dd91f00580cd2251-- From nobody Thu Jan 31 19:58:17 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACDD131202 for ; Thu, 31 Jan 2019 19:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.641 X-Spam-Level: X-Spam-Status: No, score=-17.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfHNjVxvKtJO for ; Thu, 31 Jan 2019 19:58:12 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65FF2131200 for ; Thu, 31 Jan 2019 19:58:12 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id x6so4615557ioa.9 for ; Thu, 31 Jan 2019 19:58:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=an/LZCMR+bP2cstiffAtPAyest139CRV7uKfXwuy9+E=; b=GazrANe1WVcrivlVLaeuQe3ZY5QLIyHzEKM/7RlaJqLaOY/XtmECfcHQON5nSfjZga zj83A1mo4N37Qe+SxxT1F9Cr3PGjBzgs+PAMqsCVAyioZtRnbbynUPNoDf/iv9ykjiNp DL0c162UUnLiHJ5F7q5hSH+LTc/R0RwNznMknA3LZ8sI2oys38nZoDQo5EUrTOX6cl/s 23zMzycDDHDP3N/jEgZIFeeof8YPgorbLXIf9rcqURddiSKeHYIfh2nBx82wtgBcRCKi myKNyStYapR626AyY+uz6CkR3pj/7xAbRy4o25/JSLwU4LAY0r/Dgtb7zPXoI0x7aCct Cq7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=an/LZCMR+bP2cstiffAtPAyest139CRV7uKfXwuy9+E=; b=VGTqTdc9nk0ch0SEevfVPZWRN4tQ6Uq3/jEcYGIJhEJSTPcRdPHwOvw8ioUq3MZlk7 f3zKrWOLk/MuICdJmpR83xe4vLsSBgYerOPYvLOTTe44eNtwhLkoBBlPl7eLS9PFe/Xj S4BksZdvZnkQ0OI/ny3epkJuZYKmffj4w00DBzQDTAbG+bN6CU/Gp5QoNYGNS6c/Ol+K pY3L0FMG0NCWg8Gmhbg5L9eeDVTz6wVELPpziCpLZaJVd+VePVgCi/Tf6blehKR1FJ+Q 4Lz0xvx7T+z2YNqqtU6BV1M95trIwCqmNAFp8gMjm2s1LfqYTGT15FbN62qwfFIqeWFx Dt7A== X-Gm-Message-State: AJcUukeWQNmnfnq2lQKMZUeddVCfu56aVyjJTnkQ40L71NBwrncL2mrv 5jCTE9RIc3ZNyR9dYgNgsAP3DulmvyCggH1v2LLNELYpLXPx4A== X-Google-Smtp-Source: ALg8bN7oJn+oNRKxY7zirP1rUCoyvMdcHnDmMkB3jhVyCtCCji3rHnyII1qvFscPWp7VruG1Njx/0cKw8hhZivY5AnE= X-Received: by 2002:a6b:da10:: with SMTP id x16mr21621372iob.101.1548993491206; Thu, 31 Jan 2019 19:58:11 -0800 (PST) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> In-Reply-To: From: Justin Uberti Date: Thu, 31 Jan 2019 19:57:59 -0800 Message-ID: To: Roman Shpount Cc: "Dale R. Worley" , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="000000000000cdf5ca0580cd262f" Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org 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: Fri, 01 Feb 2019 03:58:16 -0000 --000000000000cdf5ca0580cd262f Content-Type: text/plain; charset="UTF-8" We can however all agree that "c=IN IP6" is busted: https://bugs.chromium.org/p/chromium/issues/detail?id=927309 On Thu, Jan 31, 2019 at 7:56 PM Justin Uberti wrote: > I looked into this before and it's pretty clear that ICE candidate and c= > line can both contain FQDN. > > On Thu, Jan 31, 2019 at 7:14 PM Roman Shpount wrote: > >> Hi Dale, >> >> This is exactly what I've thought. I have added RtcWeb group to the >> email, since they have a draft which describes using MDNS >> candidates: rtcweb-mdns-ice-candidates ( >> https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02). >> This draft talks about replacing host candidates addresses with MDNS FQDN. >> What it does not talk about is what ends up in c=/m= line in this case. In >> the currently Chrome MDNS experiment, Chrome produces something like this: >> >> v=0 >> o=- 5433632304511147701 2 IN IP4 127.0.0.1 >> s=- >> t=0 0 >> a=group:BUNDLE audio >> a=msid-semantic: WMS 6bb347f4-f699-4522-99ea-215c10022f50 >> m=audio 59372 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 >> 126 >> *c=IN IP6* >> a=rtcp:9 IN IP4 0.0.0.0 >> a=candidate:1962264367 1 udp 2122260223 >> 3557773f-5f01-46a4-aa14-54ab35b3d778.local 59372 typ host generation 0 >> network-id 1 network-cost 10 >> a=candidate:980827103 1 tcp 1518280447 >> 3557773f-5f01-46a4-aa14-54ab35b3d778.local 9 typ host tcptype active >> generation 0 network-id 1 network-cost 10 >> a=ice-ufrag:3iia >> a=ice-pwd:HMo0mGLq8nYb9pfnG/nH3pNI >> a=ice-options:trickle >> a=fingerprint:sha-256 >> 8D:22:EF:E4:8B:7F:B3:F0:69:2E:B2:1D:4B:F1:6F:DE:62:BE:B8:DC:92:A3:F7:E5:1B:E8:87:6D:BE:E2:44:48 >> a=setup:actpass >> a=mid:audio >> a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level >> a=sendrecv >> a=rtcp-mux >> a=rtpmap:111 opus/48000/2 >> a=rtcp-fb:111 transport-cc >> a=fmtp:111 minptime=10;useinbandfec=1 >> a=rtpmap:103 ISAC/16000 >> a=rtpmap:104 ISAC/32000 >> a=rtpmap:9 G722/8000 >> a=rtpmap:0 PCMU/8000 >> a=rtpmap:8 PCMA/8000 >> a=rtpmap:106 CN/32000 >> a=rtpmap:105 CN/16000 >> a=rtpmap:13 CN/8000 >> a=rtpmap:110 telephone-event/48000 >> a=rtpmap:112 telephone-event/32000 >> a=rtpmap:113 telephone-event/16000 >> a=rtpmap:126 telephone-event/8000 >> a=ssrc:4224017887 cname:aHDhJbcPUEXkWfRL >> a=ssrc:4224017887 msid:6bb347f4-f699-4522-99ea-215c10022f50 >> ffd9edfb-e99c-4cc3-a1dd-817f0327d021 >> a=ssrc:4224017887 mslabel:6bb347f4-f699-4522-99ea-215c10022f50 >> a=ssrc:4224017887 label:ffd9edfb-e99c-4cc3-a1dd-817f0327d021 >> >> As you can see c= line is "c=IN IP6" and is missing the contact address, >> which so far breaks every client except Chrome, including Firefox. >> >> I was curious what should go into the c= line and if this would work >> anywhere, or if this is completely misguided >> >> Regards, >> _____________ >> Roman Shpount >> >> >> On Thu, Jan 31, 2019 at 9:48 PM Dale R. Worley >> wrote: >> >>> Roman Shpount writes: >>> > I wanted to see if it was ever decided if c= line should contain IN >>> IP4 or >>> > IN IP6 when default ICE candidate address contains FQDN. >>> > >>> > For instance, in the following SDP: >>> > >>> > m=audio 59372 UDP/TLS/RTP/SAVPF 0 >>> > *c=IN IP6 3557773f-5f01-46a4-aa14-54ab35b3d778.local * >>> > a=rtcp:9 IN IP4 0.0.0.0 >>> > a=candidate:1962264367 1 udp 2122260223 >>> > 3557773f-5f01-46a4-aa14-54ab35b3d778.local 59372 typ host >>> > a=ice-ufrag:3iia >>> > a=ice-pwd:HMo0mGLq8nYb9pfnG/nH3pNI >>> > a=rtcp-mux >>> > >>> > Is it correct to use "c=IN IP6 >>> 3557773f-5f01-46a4-aa14-54ab35b3d778.local " >>> > or should it be "c=IN IP4 3557773f-5f01-46a4-aa14-54ab35b3d778.local"? >>> >>> In regard to ICE *candidates*, RFC 8445 makes it clear that a candidate >>> is an IP address, not an FQDN: >>> >>> 2.1. Gathering Candidates >>> >>> In order to execute ICE, an ICE agent identifies and gathers one or >>> more address candidates. A candidate has a transport address -- a >>> combination of IP address and port for a particular transport >>> protocol (with only UDP specified here). There are different types >>> of candidates; some are derived from physical or logical network >>> interfaces, and others are discoverable via STUN and TURN. >>> >>> The discussion of "default candidates" is a little vague due to the fact >>> that the ICE specification factors out ICE from any protocol that uses >>> it, but the default candidate is always a *candidate* and thus an >>> address, not an FQDN: >>> >>> 5.2. Lite Implementation Procedures >>> >>> Next, an agent chooses a default candidate for each component of each >>> data stream. If a host is IPv4 only, there would only be one >>> candidate for each component of each data stream; therefore, that >>> candidate is the default. If a host is IPv6 only, the default >>> candidate would typically be a globally scoped IPv6 address. Dual- >>> stack hosts SHOULD allow configuration whether IPv4 or IPv6 is used >>> for the default candidate, and the configuration needs to be based on >>> which one its administrator believes has a higher chance of success >>> in the current network environment. >>> >>> >>> 5.3. Exchanging Candidate Information >>> >>> The using protocol may (or may not) need to deal with backwards >>> compatibility with older implementations that do not support ICE. If >>> a fallback mechanism to non-ICE is supported and is being used, then >>> presumably the using protocol provides a way of conveying the default >>> candidate (its IP address and port) in addition to the ICE >>> parameters. >>> >>> Dale >>> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > --000000000000cdf5ca0580cd262f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We can however all agree= that "c=3DIN IP6" is busted:=C2=A0https://bugs.chromium.org/p/ch= romium/issues/detail?id=3D927309

= On Thu, Jan 31, 2019 at 7:56 PM Justin Uberti <juberti@google.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
I looked = into this before and it's pretty clear that ICE candidate and c=3D line= can both contain FQDN.

On Thu, Jan 31, 2019 at 7:14 PM Roman Shpount <roman@telurix.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Hi Dale,

This is exactly what = I've thought. I have added RtcWeb group to the email, since they have a= draft which describes using MDNS candidates:=C2=A0rtcweb-mdns-ice-candidat= es (https://tools.ietf.org/html/draft-ietf-rtcweb-m= dns-ice-candidates-02). This draft talks about replacing host candidate= s addresses with MDNS FQDN. What it does not talk about is what ends up in = c=3D/m=3D line in this case. In the currently Chrome MDNS experiment, Chrom= e produces something like this:

v=3D0
o=3D- 543363230451= 1147701 2 IN IP4 127.0.0.1
s=3D-
=
t=3D0 0
a=3Dgroup:BUNDLE audio
a=3Dmsid-sema= ntic: WMS 6bb347f4-f699-4522-99ea-215c10022f50
m=3Daudio 59372 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110= 112 113 126
c=3DIN IP6
a=3Drtcp:9 IN IP4 0.0.0.0
a=3Dcandidate:1962264367 1 udp 2122260223 3557773f-5f01-4= 6a4-aa14-54ab35b3d778.local 59372 typ host generation 0 network-id 1 networ= k-cost 10
a=3Dcandidate:980827103 1 tc= p 1518280447 3557773f-5f01-46a4-aa14-54ab35b3d778.local 9 typ host tcptype = active generation 0 network-id 1 network-cost 10
a=3Dice-ufrag:3iia
a=3Dice-= pwd:HMo0mGLq8nYb9pfnG/nH3pNI
a=3Dice-o= ptions:trickle
a=3Dfingerprint:sha-256= 8D:22:EF:E4:8B:7F:B3:F0:69:2E:B2:1D:4B:F1:6F:DE:62:BE:B8:DC:92:A3:F7:E5:1B= :E8:87:6D:BE:E2:44:48
a=3Dsetup:actpas= s
a=3Dmid:audio
a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=3Dsendrecv
a=3Drtcp-mux
a=3Drtpmap:111 o= pus/48000/2
a=3Drtcp-fb:111 transport-= cc
a=3Dfmtp:111 minptime=3D10;useinban= dfec=3D1
a=3Drtpmap:103 ISAC/16000
a=3Drtpmap:104 ISAC/32000
a=3Drtpmap:9 G722/8000
a=3Drtpmap:0 PCMU/8000
a=3Drtpm= ap:8 PCMA/8000
a=3Drtpmap:106 CN/32000=
a=3Drtpmap:105 CN/16000
a=3Drtpmap:13 CN/8000
a=3Drtpmap:110 telephone-event/48000
a=3Drtpmap:112 telephone-event/32000
a=3Drtpmap:113 telephone-event/16000
a=3Drtpmap:126 telephone-event/8000
a=3Dssrc:4224017887 cname:aHDhJbcPUEXkWfRL
a=3Dssrc:4224017887 msid:6bb347f4-f699-4522-99ea-215c10022f50 ffd9e= dfb-e99c-4cc3-a1dd-817f0327d021
a=3Dss= rc:4224017887 mslabel:6bb347f4-f699-4522-99ea-215c10022f50
a=3Dssrc:4224017887 label:ffd9edfb-e99c-4cc3-a1dd-817= f0327d021

As you can see c=3D line is "c=3DIN IP6" = and is missing the contact address, which so far breaks every client except= Chrome, including Firefox.

I was curious what sho= uld go into the c=3D line and if this would work anywhere, or if this is co= mpletely misguided

Regards,
___________= __
Roman Shpount


On Thu, Jan 31= , 2019 at 9:48 PM Dale R. Worley <worley@ariadne.com> wrote:
Roman Shpount <roman@telurix.com> writes:
> I wanted to see if it was ever decided if c=3D line should contain IN = IP4 or
> IN IP6 when default ICE candidate address contains FQDN.
>
> For instance, in the following SDP:
>
> m=3Daudio 59372 UDP/TLS/RTP/SAVPF 0
> *c=3DIN IP6 3557773f-5f01-46a4-aa14-54ab35b3d778.local *
> a=3Drtcp:9 IN IP4 0.0.0.0
> a=3Dcandidate:1962264367 1 udp 2122260223
> 3557773f-5f01-46a4-aa14-54ab35b3d778.local 59372 typ host
> a=3Dice-ufrag:3iia
> a=3Dice-pwd:HMo0mGLq8nYb9pfnG/nH3pNI
> a=3Drtcp-mux
>
> Is it correct to use "c=3DIN IP6 3557773f-5f01-46a4-aa14-54ab35b3= d778.local "
> or should it be "c=3DIN IP4 3557773f-5f01-46a4-aa14-54ab35b3d778.= local"?

In regard to ICE *candidates*, RFC 8445 makes it clear that a candidate
is an IP address, not an FQDN:

=C2=A0 =C2=A02.1.=C2=A0 Gathering Candidates

=C2=A0 =C2=A0In order to execute ICE, an ICE agent identifies and gathers o= ne or
=C2=A0 =C2=A0more address candidates.=C2=A0 A candidate has a transport add= ress -- a
=C2=A0 =C2=A0combination of IP address and port for a particular transport<= br> =C2=A0 =C2=A0protocol (with only UDP specified here).=C2=A0 There are diffe= rent types
=C2=A0 =C2=A0of candidates; some are derived from physical or logical netwo= rk
=C2=A0 =C2=A0interfaces, and others are discoverable via STUN and TURN.

The discussion of "default candidates" is a little vague due to t= he fact
that the ICE specification factors out ICE from any protocol that uses
it, but the default candidate is always a *candidate* and thus an
address, not an FQDN:

=C2=A0 =C2=A05.2.=C2=A0 Lite Implementation Procedures

=C2=A0 =C2=A0Next, an agent chooses a default candidate for each component = of each
=C2=A0 =C2=A0data stream.=C2=A0 If a host is IPv4 only, there would only be= one
=C2=A0 =C2=A0candidate for each component of each data stream; therefore, t= hat
=C2=A0 =C2=A0candidate is the default.=C2=A0 If a host is IPv6 only, the de= fault
=C2=A0 =C2=A0candidate would typically be a globally scoped IPv6 address.= =C2=A0 Dual-
=C2=A0 =C2=A0stack hosts SHOULD allow configuration whether IPv4 or IPv6 is= used
=C2=A0 =C2=A0for the default candidate, and the configuration needs to be b= ased on
=C2=A0 =C2=A0which one its administrator believes has a higher chance of su= ccess
=C2=A0 =C2=A0in the current network environment.


=C2=A0 =C2=A05.3.=C2=A0 Exchanging Candidate Information

=C2=A0 =C2=A0The using protocol may (or may not) need to deal with backward= s
=C2=A0 =C2=A0compatibility with older implementations that do not support I= CE.=C2=A0 If
=C2=A0 =C2=A0a fallback mechanism to non-ICE is supported and is being used= , then
=C2=A0 =C2=A0presumably the using protocol provides a way of conveying the = default
=C2=A0 =C2=A0candidate (its IP address and port) in addition to the ICE
=C2=A0 =C2=A0parameters.

Dale
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000cdf5ca0580cd262f-- From nobody Thu Jan 31 20:43:36 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFDD130DF1 for ; Thu, 31 Jan 2019 20:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyQmaEWFyjGD for ; Thu, 31 Jan 2019 20:43:26 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D5EF131203 for ; Thu, 31 Jan 2019 20:43:26 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id z11so2369476pgu.0 for ; Thu, 31 Jan 2019 20:43:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KU533c4k4G9BA5pVpb10aItcLkL4Zip6Pk/bXC77de8=; b=2TuPimj4C6YvywfK9QIyzctmdG9u2sUmmaKyOE1f4aNf7k/TvlkP9przhwaJyGZU/5 EWdJrCgy5M/7zv0jOvrA9kQ6+UW9DqDtbo90cSJI4v0i5OucS6OykJ7yPysoB+o3mhxI sKWQnbw1u3yIdgdI9DqGDlbE4eANPd4SJ/GEuZSSeouWsh2asSEyP6mOCSkuI4y15yNH WUAoUs19O5NpmBrCQ51Pp1xsJKCB4KcCEptvQ8+nZlXRKa7c5HV7rfn1g8sp+rpCT8o4 eYDVP/yetwJ7O6oWo5lXMzXWgViemPhuJtX2sTLvHGsKiQJ53QGWBuKfZ5gCh5kgUwDv Bz5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KU533c4k4G9BA5pVpb10aItcLkL4Zip6Pk/bXC77de8=; b=sxVRo9xV6z3yuHGYloh4TtSpMalYWJhvhPkl6YFDJx61vsw9hRNL1ppO4hR5jKEpy3 4QoYAEWsLPvAo5cwzJq5HoYVZ0T6iWqQ1c8eSlh8x1ZBskO8Lgauc/M8oCbYQjjGPUGe MgmYMVkHuPQ9Rg36Tsjc5f3cOPYlmQ0ACTc2RSkgWC7Go8zaovMRxFm/vOq3MPo0hUAg FBbWLBwtiqKzvZfIgwGpreNTSl4O8xqVXp4GVtDrrxtLDTkZu3Ms6+OdK94nBp+k8x35 no8GJsPP4qEqPLXOWSQG+/DsQbweYv+8+J9ob6TublPre8mLkR9XM8GP1tXBNu3Q4jeZ ILuQ== X-Gm-Message-State: AHQUAuafolDSmZRsJwgi+gDEu1z80kRtPffrG+85tYmErZQuc2jHc3Jj eRaLkAMoxH6V2SPHVIFjWiGLCRDXASk= X-Google-Smtp-Source: AHgI3IYA2067a5vmWKfSqg0mWr85xamkKY6EjSowk5GZqRFGyNEPjne1IpsOiquXPYUl5GI/3D3y7Q== X-Received: by 2002:a63:981:: with SMTP id 123mr768302pgj.444.1548996205720; Thu, 31 Jan 2019 20:43:25 -0800 (PST) Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com. [209.85.214.178]) by smtp.gmail.com with ESMTPSA id m198sm7289520pga.10.2019.01.31.20.43.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Jan 2019 20:43:24 -0800 (PST) Received: by mail-pl1-f178.google.com with SMTP id gn14so2544939plb.10; Thu, 31 Jan 2019 20:43:24 -0800 (PST) X-Received: by 2002:a17:902:8b88:: with SMTP id ay8mr38466463plb.55.1548996203897; Thu, 31 Jan 2019 20:43:23 -0800 (PST) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> In-Reply-To: From: Roman Shpount Date: Thu, 31 Jan 2019 23:43:13 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: "Dale R. Worley" , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="0000000000007debae0580cdc8dd" Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org 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: Fri, 01 Feb 2019 04:43:29 -0000 --0000000000007debae0580cdc8dd Content-Type: text/plain; charset="UTF-8" On Thu, Jan 31, 2019 at 10:58 PM Justin Uberti wrote: > We can however all agree that "c=IN IP6" is busted: > https://bugs.chromium.org/p/chromium/issues/detail?id=927309 > >> >>> I guess one way to interpret this that each address should have a MDNS alias. So, if you are dealing with dual stack host, it should provide two MDNS candidates, one of which is IPv4 and another IPv6. The c= line should specify FQDN for one of those candidates and specify the type (IP4 or IP6). There are two problems: 1. There is no way to know which address type is in the candidate-address when FQDN is used there. Guidance in ice-sip-sdp is talking about the presence of column in IP6 address, but this definitely does not apply to FQDN. It would've been better to specify something like local4 and local6 as FQDN suffix in MDNS alias to specify the candidate-address type so that correct DNS request can be issued. 2. A lot (if not most) SDP/ICE implementations do no support parsing FQDN in candidate-address or c= line. This might create interop problems since RFC 5245 specified that candidate-address is an IP Address. Regards, _____________ Roman Shpount --0000000000007debae0580cdc8dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jan 31, 2019 at = 10:58 PM Justin Uberti <juberti@google.com> wrote:
We can however all agree that &q= uot;c=3DIN IP6" is busted:=C2=A0https://bugs.chromiu= m.org/p/chromium/issues/detail?id=3D927309


I gues= s one way to interpret this that each address should have a MDNS alias. So,= if you are dealing with dual stack host, it should provide two MDNS candid= ates, one of which is IPv4 and another IPv6. The c=3D line should specify F= QDN for one of those candidates and specify the type (IP4 or IP6).

There are two problems:

1. There = is no way to know which address type is in the candidate-address when FQDN = is used there. Guidance in ice-sip-sdp is talking about the presence of col= umn in IP6 address, but this definitely does not apply to FQDN. It would= 9;ve been better to specify something like local4 and local6 as FQDN suffix= in MDNS alias to specify the candidate-address type so that correct DNS re= quest can be issued.

2. A lot (if not most) SDP/IC= E implementations do no support parsing FQDN in candidate-address or c=3D l= ine. This might create interop problems since RFC 5245 specified that candi= date-address is an IP Address.

Regards,
_____= ________
Roman Shpount
=C2=A0
--0000000000007debae0580cdc8dd-- From nobody Thu Jan 31 21:02:17 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCAC131219 for ; Thu, 31 Jan 2019 21:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.641 X-Spam-Level: X-Spam-Status: No, score=-17.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlQ3M8LHtsQy for ; Thu, 31 Jan 2019 21:02:13 -0800 (PST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1AE131216 for ; Thu, 31 Jan 2019 21:02:13 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id k7so4713727iob.6 for ; Thu, 31 Jan 2019 21:02:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AGECSDaObmgXidC19DhPF9AOVX9xM2GQ0+KGyKGTl3A=; b=PAHBp6zwxHORsuLi2xTqIk6aBsZqdvbbJXhK/0Wfl9uLayT8wMeyoQbhDsE/yUCGPq 1suYZ27y3gwuYRp1v2w2L9fxBzk58JminJF7UKATYZulp9ySVFDTEJQ2i9ntNuJG64xw 15qE57rpI0HBH05PmT4tnGdZ0D1QHnF4uO2wvsrbbw0KRK3D4/zC6yB6XOFHr1ef1XtI yred82YanWcWUrJPXzNa1NDNL0txkfPSDHV1fOMgHG9/hqUXT2ELGa/xIkYBwNNOFgw3 6H3ASMgQmO8gBjdikC8Lk/vQuqeuxgtpOZ+zoCtphK3e2H0LD0PU7V5uMkCbvyVj10gR H1jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AGECSDaObmgXidC19DhPF9AOVX9xM2GQ0+KGyKGTl3A=; b=EcfVGZZCqxApapl/FhZNramQqd6eFjjzpSCiCLgHxemG4/AwtrKDMizkQyUR0Kf9mI QtT8I4GCSIQzumOfcnX/MKtIcoBpOKLMMWyWiH2Ec+Epp1Kk7RfcqD7rvhOh4K/r0Y20 +FgDJFi3pqsdnQNjB2bKuEpFD8jfymRuJZYMTgh6ZpxDdI4ruUX8564GeEyNbv1vQ6QM tqFiNjU9ixDUl9kK7VReApIddWNm3NYVTG3ODNi1FHxuxqQl17kGrkVqOiF0gGL9SiOt Tjt0nSVZAW5plNy4sbZE9S/U7UOzsnl9okegx4TERRuwieQhL2FTvir6ATPJlJwKQJIy 3woQ== X-Gm-Message-State: AHQUAuZiuh+csEdm8Gt/t78cAzE3V5j2rQGUP/mqbr3hcJ7zCewUJ6KX N7eH3ahDuukaiFM65yAJ5pEakuA+1nKXNrVuWmeupg== X-Google-Smtp-Source: AHgI3IaijygWO/TXJ/DxRS8S0ne/F6JIDiVO2TPsEvtkJEnzI5A/HSPczHHeWurh+EUOSG2LeDxuOMnfWXgRanrT1XA= X-Received: by 2002:a5e:920d:: with SMTP id y13mr20044337iop.95.1548997331943; Thu, 31 Jan 2019 21:02:11 -0800 (PST) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> In-Reply-To: From: Justin Uberti Date: Thu, 31 Jan 2019 21:02:00 -0800 Message-ID: To: Roman Shpount Cc: "Dale R. Worley" , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="000000000000bb35320580ce0b7e" Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org 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: Fri, 01 Feb 2019 05:02:16 -0000 --000000000000bb35320580ce0b7e Content-Type: text/plain; charset="UTF-8" My recommendation here would be that we do c=IN IP6 3557773f-5f01-46a4-aa14-54ab35b3d778.local, with either IP4 or IP6 depending on which type of address is being wrapped. Re #1: RFC 4566 seems to indicate you can use either IP4 or IP6 for FQDN in the c= line. unicast-address = IP4-address / IP6-address / FQDN / extn-addr Re #2: Quoth 5245 : : is taken from RFC 4566 [RFC4566 ]. It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and *fully qualified domain names (FQDNs).* When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value - the presence of a colon indicates IPv6. An agent MUST ignore candidate lines that include candidates with IP address versions that are not supported or recognized. An IP address SHOULD be used, but an FQDN MAY be used in place of an IP address. In that case, when receiving an offer or answer containing an FQDN in an a=candidate attribute, the FQDN is looked up in the DNS first using an AAAA record (assuming the agent supports IPv6), and if no result is found or the agent only supports IPv4, using an A. If the DNS query returns more than one IP address, one is chosen, and then used for the remainder of ICE processing. On Thu, Jan 31, 2019 at 8:43 PM Roman Shpount wrote: > On Thu, Jan 31, 2019 at 10:58 PM Justin Uberti wrote: > >> We can however all agree that "c=IN IP6" is busted: >> https://bugs.chromium.org/p/chromium/issues/detail?id=927309 >> >>> >>>> > I guess one way to interpret this that each address should have a MDNS > alias. So, if you are dealing with dual stack host, it should provide two > MDNS candidates, one of which is IPv4 and another IPv6. The c= line should > specify FQDN for one of those candidates and specify the type (IP4 or IP6). > > There are two problems: > > 1. There is no way to know which address type is in the candidate-address > when FQDN is used there. Guidance in ice-sip-sdp is talking about the > presence of column in IP6 address, but this definitely does not apply to > FQDN. It would've been better to specify something like local4 and local6 > as FQDN suffix in MDNS alias to specify the candidate-address type so that > correct DNS request can be issued. > > 2. A lot (if not most) SDP/ICE implementations do no support parsing FQDN > in candidate-address or c= line. This might create interop problems since > RFC 5245 specified that candidate-address is an IP Address. > > Regards, > _____________ > Roman Shpount > > --000000000000bb35320580ce0b7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My recommendation here would be that= we do c=3DIN IP6 3557773f-5f01-46a4-aa14-54ab35b3d778.local, with either I= P4 or IP6 depending on which type of address is being wrapped.
Re #1:=C2=A0RFC 4566 seems to indicate you can use either IP4 = or IP6 for FQDN in the c=3D line.

     unicast-address =3D     IP4-addres=
s / IP6-address / FQDN / extn-addr

Re #2: Quoth 5245:

   <connection-address>:  is taken fr=
om RFC 4566 [RFC4566].  It is the
      IP address of the candidate, allowing for IPv4 addresses, IPv6
      addresses, and fully qualified domain names (FQDNs).  When par=
sing
      this field, an agent can differentiate an IPv4 address and an IPv6

      address by =
presence of a colon in its value - the presence of a
      colon indicates IPv6.  An agent MUST ignore candidate lines that
      include candidates with IP address versions that are not supported
      or recognized.  An IP address SHOULD be used, but an FQDN MAY be
      used in place of an IP address.  In that case, when receiving an
      offer or answer containing an FQDN in an a=3Dcandidate attribute,
      the FQDN is looked up in the DNS first using an AAAA record
      (assuming the agent supports IPv6), and if no result is found or
      the agent only supports IPv4, using an A.  If the DNS query
      returns more than one IP address, one is chosen, and then used for
      the remainder of ICE processing.








On Thu, Jan 31= , 2019 at 8:43 PM Roman Shpount <ro= man@telurix.com> wrote:
On Thu, Jan 31, 2019 at 10:58 PM Justin Uberti <juberti@google.com>= ; wrote:
We can however all agree that "c=3DIN IP6" is busted:=C2= =A0https://bugs.chromium.org/p/chromium/issues/detail?id= =3D927309


I guess one way to interpret this that e= ach address should have a MDNS alias. So, if you are dealing with dual stac= k host, it should provide two MDNS candidates, one of which is IPv4 and ano= ther IPv6. The c=3D line should specify FQDN for one of those candidates an= d specify the type (IP4 or IP6).

There are two pro= blems:

1. There is no way to know which address ty= pe is in the candidate-address when FQDN is used there. Guidance in ice-sip= -sdp is talking about the presence of column in IP6 address, but this defin= itely does not apply to FQDN. It would've been better to specify someth= ing like local4 and local6 as FQDN suffix in MDNS alias to specify the cand= idate-address type so that correct DNS request can be issued.
2. A lot (if not most) SDP/ICE implementations do no support pa= rsing FQDN in candidate-address or c=3D line. This might create interop pro= blems since RFC 5245 specified that candidate-address is an IP Address.

Regards,
_____________
Roman Shpount
=C2=A0
--000000000000bb35320580ce0b7e--