From nobody Mon Mar 2 08:23:23 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBA93A0A42 for ; Mon, 2 Mar 2020 08:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=fivn.onmicrosoft.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 9-f0Rk9cg5_S for ; Mon, 2 Mar 2020 08:23:19 -0800 (PST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2062a.outbound.protection.outlook.com [IPv6:2a01:111:f400:7eae::62a]) (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 5899D3A0A3C for ; Mon, 2 Mar 2020 08:23:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JBeeGxQnvhPoTmzGbSACkuULFoC35bsewfvuKL0UzRfmtz4SlPABWwMJjHmbGTkptKWYBBMop2wTs/2Kq0GRlgH4+y6UWGzysK/r7l13wGlnPEvpLRRotqBCGKi5DBK+j7WNSRT3UrSTWarXDd4aj32oJ7L6lBGAowJfUHFTa7hLEzFlsDprzFFoAaM3KPLNf9CYXQcq9IKHppjGUe0mmQJVgJgOrFhSBSYxgcp0Mv3GWlzGkVDiiIg3G5OGmAsibCvgnWBjBBzxLQYyzFtDZQvCpNPHKOzoeUlFhBctLnWRDcWoYm6YxBfE2EPQaWFjmtmrA1G0smg42hSAD+GNcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TVW0Cue63t9ViGsNW7SSO8hEgRAbSpWR6s3sON+0ODA=; b=eqmNUtL9P7WKfvrPpVVEFPcs06dSWxnEmfqHdZQOyPdd/DEipQIRicGYZHgtXY/7Eb/Go/Xv3lOMLY2EcIBOSO8VAJq5IdM2YTwnSPvzmeU7x06h6eZ74/qpLCfp7vdNyp/cRHkm5wRyWva0HtV0STcyom0nVtE9WyDaPwPWBCgI+cy+Arf2UdWpj2+Q1wQqLXGIk9jeZaKFDp52JAzZ1LP5OA4hM1KyyqP6BPF6DAGHpRbQUbPo4HoIdKOroL+HLyovJt1BhWvHb1501uG5NMC9ZZh/xh6TiIC4F74dwLo5Yc0SOLB9x+llDCfpnCVo+NAK6gve9wVry4GZ/v08sg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=five9.com; dmarc=pass action=none header.from=five9.com; dkim=pass header.d=five9.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fivn.onmicrosoft.com; s=selector2-fivn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TVW0Cue63t9ViGsNW7SSO8hEgRAbSpWR6s3sON+0ODA=; b=D2EPEcqam6sW6fps96uk2B3ivyzOUzT7jH10aBC14B4VDBHAoS80rUvjzaX9LxfwxTwNYO5j+aVLxkfac7UIaYD07R9BBRCztKP7SewLIK1b8Ethves1oPweEbIPOlHFAapJBJ6qUDlinWdQju5zM60SpHuvN183m7sT6/gZCPM= Received: from BYAPR06MB4391.namprd06.prod.outlook.com (2603:10b6:a03:12::26) by BYAPR06MB4853.namprd06.prod.outlook.com (2603:10b6:a03:7f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.19; Mon, 2 Mar 2020 16:23:17 +0000 Received: from BYAPR06MB4391.namprd06.prod.outlook.com ([fe80::21c5:6201:54:13d4]) by BYAPR06MB4391.namprd06.prod.outlook.com ([fe80::21c5:6201:54:13d4%2]) with mapi id 15.20.2772.019; Mon, 2 Mar 2020 16:23:17 +0000 From: Jonathan Rosenberg To: "Roni Even (A)" , "v3@ietf.org" CC: "Cullen Jennings (fluffy)" Thread-Topic: RIPT BoF approved for IETF 107 - Draft charter below Thread-Index: AdXjgeGz8imU79X0QTWjBiq5oM7qsgLUZ0xQAHbTf2A= Date: Mon, 2 Mar 2020 16:23:16 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD27DA8D2F@DGGEMM506-MBS.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD27DA8D2F@DGGEMM506-MBS.china.huawei.com> 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=jdrosen@five9.com; x-originating-ip: [108.35.46.157] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 87a75c42-7825-45cb-6d82-08d7bec603aa x-ms-traffictypediagnostic: BYAPR06MB4853: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(136003)(346002)(366004)(39850400004)(199004)(189003)(4326008)(478600001)(71200400001)(8936002)(81166006)(9686003)(81156014)(55016002)(8676002)(2906002)(7696005)(186003)(26005)(6506007)(53546011)(86362001)(316002)(33656002)(110136005)(52536014)(66946007)(76116006)(5660300002)(66446008)(66556008)(64756008)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR06MB4853; H:BYAPR06MB4391.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: five9.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Jy4il9AOZv92SyI9Xz3+ucptOMYQIZbOUuXhTmfBByIbZ/F1QXUsWCjo8CklN+KK7Pf0urnehrx7CR71U/yf4+7XHDzbuq+GSpqRMuiHvIjRQYICdN17iSnYTJnLvgyRqn++b1KXxawqNmdYcVKsLNvsdZRzwzWNh/PsI0fYK/JUW4YTLFC9EsHmbITageP/6MmrBMRa+1/3bB1+doOAFXdz1jYugkao++Szs8/0wT3IT2WhK4I0UuV0c/vYL2w0xEwvtt/OO9KaZmFXqH6H6CvJ8KlAJEdmwWRXjkwLxgXYh+YH1arH0HXPc2T0RJg8D/wGCLk5f2wST67PZpESqv04C4bKr9seTsybbB5pXy8VZAn3fSc5ezKHTdVXlKgkVpueaSte3rfMHyvbyrXEUhPOr3TMjqmebXHT1H07UdNeKrnSrc6mfzz2eDSog0aQ x-ms-exchange-antispam-messagedata: oKpM9iI/oXEoe+VbTnciLg2RIMmqQr14h/GonSMUD0OnLTIB8iZjONeKfJ2mbhggsirpeHw/YKd7fry13flPxc9vmpuAGA1/tMT5xzVic99f19iH8grWiWIxos8vSCVMkQD9510Vw1L6ohCgk6qkrw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR06MB4391FDE2E2B710DCA49D741BFBE70BYAPR06MB4391namp_" MIME-Version: 1.0 X-OriginatorOrg: five9.com X-MS-Exchange-CrossTenant-Network-Message-Id: 87a75c42-7825-45cb-6d82-08d7bec603aa X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2020 16:23:16.9198 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f6c5114f-7396-4a09-af1e-98ee46f99bdb X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /KhiBaL9AcXHe9UtPZLrV0XzcPuOBIe1uFlOaSHh96ujw0acMYDFzTu4LkWBAl1e9+GURJB1RcaylTFvlZ8CyA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB4853 Archived-At: Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 16:23:22 -0000 --_000_BYAPR06MB4391FDE2E2B710DCA49D741BFBE70BYAPR06MB4391namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Roni. I think its clear we want datagrams for media in general. The = trick here is how to get them while utilizing http3 as the transport. From: Roni Even (A) Sent: Saturday, February 29, 2020 2:51 AM To: Jonathan Rosenberg ; v3@ietf.org Cc: Cullen Jennings (fluffy) Subject: RE: RIPT BoF approved for IETF 107 - Draft charter below Hi, I read the drafts. I like the idea of having the endpoint capabilities know= n in advance making call establishment simpler. We have the must support co= decs in RTCweb and this is a step forwards. Maybe it is also about time to = deprecate the "MUST support H.261/G.711" in older documents (H.323,...). As for media transport, I think that Jorge and Colin document provide good = starting point and motivation why to use datagrams for the media and it is = my preference for conversional services to have the application layer decid= e if to retransmit. My view is that for audio it is not needed (use redund= ancy, the best retransmission is for the listener to say "I could not hear = it, can you please repeat". As for video my view is that the requirement is not retransmission but re-s= ynchronize. For "talking heads" video conference just resynch and continue. Roni From: V3 [mailto:v3-bounces@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Saturday, February 15, 2020 12:00 AM To: v3@ietf.org Cc: Cullen Jennings (fluffy) Subject: [V3] RIPT BoF approved for IETF 107 - Draft charter below Good news folks - RIPT bof was approved for IETF107 and we'll be meeting. G= oal is to try and get a WG formed. As such, charter discussion is in order.= Cullen, myself and Justin worked a draft charter. Comments please: This working group will standardize a protocol, capable of operating atop HTTP/3, which supports real-time voice and video communications, including signaling, media negotiation, and transmission of media packets. The primary rationale for this new protocol is to enable deployment of real-time communications services on modern "cloud" systems. These systems are built around HTTP, and for HTTP-based applications, they enable load balancing, HA, auto-scaling, and so on. However, real-time communications protocols are based on SIP and RTP, and they cannot take advantage of these HTTP-based capabilities. It is a non-goal of this working group to replicate all of SIP and its many extensions into HTTP. The group will limit itself to supporting the functionality in widespread actual usage today. The protocol uses HTTP techniques for authentication and authorization (notably OAuth), and requires hop by hop encryption (i.e., https). The protocol will also allow for e2e media encryption, although keying is out of scope, and is expected to be handled by other protocols such as MLS. This extension will also utilize STIR for callerID. This protocol should be implementable in browsers, thick desktop clients, mobile apps and servers. The group will standardize an extension to the baseline protocol that automates the configuration necessary to achieve calling between on organization which is a customer of the other (for example, enterprise to service provider). [OPEN ISSUE: Is P2P media in or out? If in, ICE or something else ?] The group will do its work in conjunction with active software development efforts, so that implementation experience feeds directly into protocol development. The group will coordinate with the Webtranport, QUIC, HTTPbis and STIR working groups. Milestones: Dec 2020: Submit baseline protocol to IESG Mar 2021: Submit autoconfiguration protocol to IESG Thx, Jonathan R. -- Jonathan Rosenberg CTO and Head of AI, Five9 ________________________________ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= . ________________________________ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= . --_000_BYAPR06MB4391FDE2E2B710DCA49D741BFBE70BYAPR06MB4391namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Roni. I think its clear we want datagrams for= media in general. The trick here is how to get them while utilizing http3 = as the transport.

 

From: Roni Even (A) <roni.even@huawei.com&= gt;
Sent: Saturday, February 29, 2020 2:51 AM
To: Jonathan Rosenberg <jdrosen@five9.com>; v3@ietf.org
Cc: Cullen Jennings (fluffy) <fluffy@cisco.com>
Subject: RE: RIPT BoF approved for IETF 107 - Draft charter below

 

Hi,<= /p>

I read the drafts. I l= ike the idea of having the endpoint capabilities known in advance making ca= ll establishment simpler. We have the must support codecs in RTCweb and thi= s is a step forwards. Maybe it is also about time to deprecate the “MUST support H.261/G.711” in olde= r documents (H.323,…).

As for media transport= , I think that Jorge and Colin document provide good starting point and mot= ivation why to use datagrams for the media and it is my preference for conv= ersional services to have the application layer decide if to retransmit.  My view is that for audio it is not n= eeded (use redundancy, the best retransmission is for the listener to say &= #8220;I could not hear it, can you please repeat”.<= /p>

As for video my view i= s that the requirement is not retransmission but re-synchronize. For “= ;talking heads” video conference just resynch and continue.

 

Roni  =

 

 

From: V3 [mailto:v3-bounces@ietf.org] On Behalf Of Jonathan Rosenberg
Sent: Saturday, February 15, 2020 12:00 AM
To: v3@ietf.org
Cc: Cullen Jennings (fluffy)
Subject: [V3] RIPT BoF approved for IETF 107 - Draft charter below

 

Good news folks – RIPT bof was approved for IE= TF107 and we’ll be meeting. Goal is to try and get a WG formed. As su= ch, charter discussion is in order. Cullen, myself and Justin worked a draf= t charter. Comments please:

 

 

This working group will standardize a protocol, capa= ble of operating

atop HTTP/3, which supports real-time voice and vide= o communications,

including signaling, media negotiation, and transmis= sion of media

packets.

 

The primary rationale for this new protocol is to en= able deployment of

real-time communications services on modern "cl= oud" systems. These

systems are built around HTTP, and for HTTP-based ap= plications, they

enable load balancing, HA, auto-scaling, and so on. = However, real-time

communications protocols are based on SIP and RTP, a= nd they cannot take

advantage of these HTTP-based capabilities.

 

It is a non-goal of this working group to replicate = all of SIP and its

many extensions into HTTP. The group will limit itse= lf to supporting the

functionality in widespread actual usage today.=

 

The protocol uses HTTP techniques for authentication= and authorization

(notably OAuth), and requires hop by hop encryption = (i.e., https). The

protocol will also allow for e2e media encryption, a= lthough keying is

out of scope, and is expected to be handled by other= protocols such as

MLS. This extension will also utilize STIR for calle= rID.

 

This protocol should be implementable in browsers, t= hick desktop

clients, mobile apps and servers.

 

The group will standardize an extension to the basel= ine protocol that

automates the configuration necessary to achieve cal= ling between on

organization which is a customer of the other (for e= xample, enterprise

to service provider).

 

[OPEN ISSUE: Is P2P media in or out? If in, ICE or s= omething else ?]

 

The group will do its work in conjunction with activ= e software

development efforts, so that implementation experien= ce feeds directly

into protocol development.

 

The group will coordinate with the Webtranport, QUIC= , HTTPbis and STIR

working groups.

 

Milestones:

 

Dec 2020: Submit baseline protocol to IESG

Mar 2021: Submit autoconfiguration protocol to IESG<= o:p>

 

Thx,

Jonathan R.

 

--

Jonathan Rosenberg

CTO and Head of AI, Five9

 

 


CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are= not the intended recipient, please notify the sender immediately, destroy = the original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the information in any medium. Copyright= in this e-mail and any attachments belongs to Five9 and/or its affiliated = entities.



CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are= not the intended recipient, please notify the sender immediately, destroy = the original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the information in any medium. Copyright= in this e-mail and any attachments belongs to Five9 and/or its affiliated = entities.
--_000_BYAPR06MB4391FDE2E2B710DCA49D741BFBE70BYAPR06MB4391namp_-- From nobody Mon Mar 2 23:02:42 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F83F3A19D3 for ; Mon, 2 Mar 2020 23:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 jG-v0NMyDkuF for ; Mon, 2 Mar 2020 23:02:39 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 BDEB73A19D5 for ; Mon, 2 Mar 2020 23:02:38 -0800 (PST) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 73CC3E82CDD7029AC145 for ; Tue, 3 Mar 2020 07:02:37 +0000 (GMT) Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 3 Mar 2020 07:02:36 +0000 Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.227]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0439.000; Tue, 3 Mar 2020 15:02:32 +0800 From: "Roni Even (A)" To: Jonathan Rosenberg , "v3@ietf.org" CC: "Cullen Jennings (fluffy)" Thread-Topic: RIPT BoF approved for IETF 107 - Draft charter below Thread-Index: AdXjgeGz8imU79X0QTWjBiq5oM7qsgLUZ0xQAHbTf2AAHpF4oA== Date: Tue, 3 Mar 2020 07:02:32 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD27DAE805@dggemm526-mbx.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD27DA8D2F@DGGEMM506-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.198] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD27DAE805dggemm526mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2020 07:02:42 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD27DAE805dggemm526mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jonathan, I think we also need to look how to convey the RTP extensions that may be n= eeded (RFC5104) and the RTCP feedback, I found Jorge and Colin suggestion t= o use the QUIC reliable streams as a good direction, also unlike UDP when u= sing QUIC you create a bi-directional connection. I am not that good with HTTP3, I probably need to learn more Regards Roni From: V3 [mailto:v3-bounces@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Monday, March 02, 2020 6:23 PM To: Roni Even (A); v3@ietf.org Cc: Cullen Jennings (fluffy) Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below Thanks Roni. I think its clear we want datagrams for media in general. The = trick here is how to get them while utilizing http3 as the transport. From: Roni Even (A) > Sent: Saturday, February 29, 2020 2:51 AM To: Jonathan Rosenberg >; v3@ie= tf.org Cc: Cullen Jennings (fluffy) > Subject: RE: RIPT BoF approved for IETF 107 - Draft charter below Hi, I read the drafts. I like the idea of having the endpoint capabilities know= n in advance making call establishment simpler. We have the must support co= decs in RTCweb and this is a step forwards. Maybe it is also about time to = deprecate the "MUST support H.261/G.711" in older documents (H.323,...). As for media transport, I think that Jorge and Colin document provide good = starting point and motivation why to use datagrams for the media and it is = my preference for conversional services to have the application layer decid= e if to retransmit. My view is that for audio it is not needed (use redund= ancy, the best retransmission is for the listener to say "I could not hear = it, can you please repeat". As for video my view is that the requirement is not retransmission but re-s= ynchronize. For "talking heads" video conference just resynch and continue. Roni From: V3 [mailto:v3-bounces@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Saturday, February 15, 2020 12:00 AM To: v3@ietf.org Cc: Cullen Jennings (fluffy) Subject: [V3] RIPT BoF approved for IETF 107 - Draft charter below Good news folks - RIPT bof was approved for IETF107 and we'll be meeting. G= oal is to try and get a WG formed. As such, charter discussion is in order.= Cullen, myself and Justin worked a draft charter. Comments please: This working group will standardize a protocol, capable of operating atop HTTP/3, which supports real-time voice and video communications, including signaling, media negotiation, and transmission of media packets. The primary rationale for this new protocol is to enable deployment of real-time communications services on modern "cloud" systems. These systems are built around HTTP, and for HTTP-based applications, they enable load balancing, HA, auto-scaling, and so on. However, real-time communications protocols are based on SIP and RTP, and they cannot take advantage of these HTTP-based capabilities. It is a non-goal of this working group to replicate all of SIP and its many extensions into HTTP. The group will limit itself to supporting the functionality in widespread actual usage today. The protocol uses HTTP techniques for authentication and authorization (notably OAuth), and requires hop by hop encryption (i.e., https). The protocol will also allow for e2e media encryption, although keying is out of scope, and is expected to be handled by other protocols such as MLS. This extension will also utilize STIR for callerID. This protocol should be implementable in browsers, thick desktop clients, mobile apps and servers. The group will standardize an extension to the baseline protocol that automates the configuration necessary to achieve calling between on organization which is a customer of the other (for example, enterprise to service provider). [OPEN ISSUE: Is P2P media in or out? If in, ICE or something else ?] The group will do its work in conjunction with active software development efforts, so that implementation experience feeds directly into protocol development. The group will coordinate with the Webtranport, QUIC, HTTPbis and STIR working groups. Milestones: Dec 2020: Submit baseline protocol to IESG Mar 2021: Submit autoconfiguration protocol to IESG Thx, Jonathan R. -- Jonathan Rosenberg CTO and Head of AI, Five9 ________________________________ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= . ________________________________ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= . --_000_6E58094ECC8D8344914996DAD28F1CCD27DAE805dggemm526mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jonathan,

I think we also need t= o look how to convey the RTP extensions that may be needed (RFC5104) and th= e RTCP feedback, I found Jorge and Colin suggestion to use the QUIC reliabl= e streams as a good direction, also unlike UDP when using QUIC you create a bi-directional connection.

I am not that good wit= h HTTP3, I probably need to learn more

Regards

Roni=

 

From: V3 [mail= to:v3-bounces@ietf.org] On Behalf Of Jonathan Rosenberg
Sent: Monday, March 02, 2020 6:23 PM
To: Roni Even (A); v3@ietf.org
Cc: Cullen Jennings (fluffy)
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter bel= ow

 

Thanks Roni. I think its clear we want datagrams for= media in general. The trick here is how to get them while utilizing http3 = as the transport.

 

From: Roni Even (A) <roni.even@huawei.com>
Sent: Saturday, February 29, 2020 2:51 AM
To: Jonathan Rosenberg <jdro= sen@five9.com>; v3@ietf.org
Cc: Cullen Jennings (fluffy) <fluffy@cisco.com>
Subject: RE: RIPT BoF approved for IETF 107 - Draft charter below

 

Hi,<= /p>

I read the drafts. I l= ike the idea of having the endpoint capabilities known in advance making ca= ll establishment simpler. We have the must support codecs in RTCweb and thi= s is a step forwards. Maybe it is also about time to deprecate the “MUST support H.261/G.711” in olde= r documents (H.323,…).

As for media transport= , I think that Jorge and Colin document provide good starting point and mot= ivation why to use datagrams for the media and it is my preference for conv= ersional services to have the application layer decide if to retransmit.  My view is that for audio it is not n= eeded (use redundancy, the best retransmission is for the listener to say &= #8220;I could not hear it, can you please repeat”.<= /p>

As for video my view i= s that the requirement is not retransmission but re-synchronize. For “= ;talking heads” video conference just resynch and continue.

 

Roni  =

 

 

From: V3 [mailto:v3-bounces@ietf.org] On Behalf Of Jonathan Rosenberg
Sent: Saturday, February 15, 2020 12:00 AM
To: v3@ietf.org
Cc: Cullen Jennings (fluffy)
Subject: [V3] RIPT BoF approved for IETF 107 - Draft charter below

 

Good news folks – RIPT bof was approved for IE= TF107 and we’ll be meeting. Goal is to try and get a WG formed. As su= ch, charter discussion is in order. Cullen, myself and Justin worked a draf= t charter. Comments please:

 

 

This working group will standardize a protocol, capa= ble of operating

atop HTTP/3, which supports real-time voice and vide= o communications,

including signaling, media negotiation, and transmis= sion of media

packets.

 

The primary rationale for this new protocol is to en= able deployment of

real-time communications services on modern "cl= oud" systems. These

systems are built around HTTP, and for HTTP-based ap= plications, they

enable load balancing, HA, auto-scaling, and so on. = However, real-time

communications protocols are based on SIP and RTP, a= nd they cannot take

advantage of these HTTP-based capabilities.

 

It is a non-goal of this working group to replicate = all of SIP and its

many extensions into HTTP. The group will limit itse= lf to supporting the

functionality in widespread actual usage today.=

 

The protocol uses HTTP techniques for authentication= and authorization

(notably OAuth), and requires hop by hop encryption = (i.e., https). The

protocol will also allow for e2e media encryption, a= lthough keying is

out of scope, and is expected to be handled by other= protocols such as

MLS. This extension will also utilize STIR for calle= rID.

 

This protocol should be implementable in browsers, t= hick desktop

clients, mobile apps and servers.

 

The group will standardize an extension to the basel= ine protocol that

automates the configuration necessary to achieve cal= ling between on

organization which is a customer of the other (for e= xample, enterprise

to service provider).

 

[OPEN ISSUE: Is P2P media in or out? If in, ICE or s= omething else ?]

 

The group will do its work in conjunction with activ= e software

development efforts, so that implementation experien= ce feeds directly

into protocol development.

 

The group will coordinate with the Webtranport, QUIC= , HTTPbis and STIR

working groups.

 

Milestones:

 

Dec 2020: Submit baseline protocol to IESG

Mar 2021: Submit autoconfiguration protocol to IESG<= o:p>

 

Thx,

Jonathan R.

 

--

Jonathan Rosenberg

CTO and Head of AI, Five9

 

 


CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are= not the intended recipient, please notify the sender immediately, destroy = the original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the information in any medium. Copyright= in this e-mail and any attachments belongs to Five9 and/or its affiliated = entities.

 


CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are= not the intended recipient, please notify the sender immediately, destroy = the original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the information in any medium. Copyright= in this e-mail and any attachments belongs to Five9 and/or its affiliated = entities.

--_000_6E58094ECC8D8344914996DAD28F1CCD27DAE805dggemm526mbxchi_-- From nobody Fri Mar 13 13:59:55 2020 Return-Path: X-Original-To: v3@ietf.org Delivered-To: v3@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5573A0FE0; Fri, 13 Mar 2020 13:59:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: adam@nostrum.com, v3@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158413315016.3136.17762502500607927356@ietfa.amsl.com> Date: Fri, 13 Mar 2020 13:59:10 -0700 Archived-At: Subject: [V3] ript - Requested session has been scheduled for IETF 107 X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 20:59:24 -0000 Dear Amy Vezza, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ript Session 1 (2:00 requested) Thursday, 26 March 2020, Session II 2210-0010 Room Name: Virtual Track 1 size: None --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/ript.ics Request Information: --------------------------------------------------------- Working Group Name: Realtime Internet Peering for Telephony Area Name: Applications and Real-Time Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Technology Overlap: httpbis quic sipcore tls wpack webtrans People who must be present: Adam Roach Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Mar 18 01:11:58 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C553A089D for ; Wed, 18 Mar 2020 01:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lowentropy.net header.b=EIpjJGx7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QYPKqSMc 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 i0Qf-_ys4xoy for ; Wed, 18 Mar 2020 01:11:52 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F283A08AB for ; Wed, 18 Mar 2020 01:11:52 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2BB645C01BF for ; Wed, 18 Mar 2020 04:11:51 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 18 Mar 2020 04:11:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=8mV6447nYTckaefgZNF4S3F4RATEjKOK5ImcoVmJE0o=; b=EIpjJGx7 +hUSkLO+iNRU8V+e2Nz6QIFyEY3UET1Iy7qyeO8kzZOdMun/+mpHwGH/jSlhKcML qxu8kR+RA5mb/MZ9chprYmQp+SxJD8X2qtbYZvYxnBz+KH9cadh3Qa4EOxiwZpkg jwan3ZFTyk5skTzcltR+yMtIcCEqhwkNrIf6GtlO34BgAf3ZLK+VxTcmtQ7oA1py 9BXROVS4ZmHjEX/AK1tb4Gzi66HVtUBbidOMjeZTPHSShSpSvZ7xU7CdYyDaud8i OISkNgs4D+TRC/cAmRPw0Qh7WH/QGu2gBH21s1OZmX8oi/W6jh3+VWfHlWbDI8Jy 1He2v3K1+dkwWQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=8mV6447nYTckaefgZNF4S3F4RATEj KOK5ImcoVmJE0o=; b=QYPKqSMcim0nmxr3Lx1CNK/LP522DPbAtqLVfCbkdfuFO EBRxhSDSHMn+rhsuPhLuwhMmzoSinIu80IFq8lQa6A2tfZ7T06hbzdd/L8VGlJsN jODKAUcxzrieFB9sEtpUUapGgC+dxG//zC2eNPPgHu4rZzEzCbf9PUZQYw2ZnJz6 1zfdRp40+5db5MIhvl8RPL8dvJjk/K+11XGSW2av8lDvx+Ad1bhOM+KrjITZ7mmh HOQzpA91XrxQCzJi255dqj2bX9p9E3Ng9AjEYAHLgSoPJ7+wlAjr8uOSARis4i20 7SQKgjVaQtDddqUqqe5ZzIvxJxVrgwzyQL77ye5Eg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudefiedguddufecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhht rhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B2A46E00AC; Wed, 18 Mar 2020 04:11:50 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3 Mime-Version: 1.0 Message-Id: <89363ee0-57c1-4a96-8faf-39171d968ad1@www.fastmail.com> Date: Wed, 18 Mar 2020 19:11:31 +1100 From: "Martin Thomson" To: v3@ietf.org Content-Type: text/plain Archived-At: Subject: [V3] RIPT BoF agenda added X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 08:11:54 -0000 Hey everyone, I've added an agenda to the datatracker. https://datatracker.ietf.org/meeting/107/materials/agenda-107-ript-00 I couldn't find webex details, but please prepare for the meeting in advance, using the linked guide. If you are listed as presenting, please provide slides as soon as possible. -- Realtime Internet Peering for Telephony (RIPT) BoF IETF 107 2020-03-26 22:10-00:10 UTC (ends 2020-03-27) Virtual Track 1: (link TBA) Guide to participation: https://www.ietf.org/how/meetings/107/session-participant-guide/ Agenda Administrivia [Chairs] 10m Problem Statement [Jonathan R.] 15m High Level Protocol summary [Jonathan R.] 15m Implementation Experiences at Google [Justin U.] 15m Freeswitch use cases and needs [Anthony M.] 10m Charter review and questions [Cullen J.] 30m Drafts https://tools.ietf.org/html/draft-rosenbergjennings-dispatch-ript-00 https://tools.ietf.org/html/draft-rosenbergjennings-dispatch-ript-00 https://tools.ietf.org/html/draft-rosenberg-dispatch-ript-sipdiffs-00 https://tools.ietf.org/html/draft-rosenberg-dispatch-ript-webrtc-00 From nobody Wed Mar 18 14:57:21 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9F73A1CFE for ; Wed, 18 Mar 2020 14:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=RT9Y5Lty; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=ta95w4ef 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 Gha3Euz3kRTz for ; Wed, 18 Mar 2020 14:57:14 -0700 (PDT) Received: from outbound2r.ore.mailhop.org (outbound2r.ore.mailhop.org [54.200.129.228]) (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 AF61F3A1CFA for ; Wed, 18 Mar 2020 14:57:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584568630; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=OT3YPOWW7UQzzZ9rSO49W6Ua0LAQH1g+sqt9ZjLOqxWwljxjvCZhU7tjBCryzSKPWnhAdAo9XJ7p4 j+LlyC0CMgb9QnuS0RWlTsViyM7MSu/TIuzMEwELFf1T5p5th7eZrbIZMPLL7Gz7watt0mOVqGZxpK 29RUBYm1sQnbT9G4mK0HqBGkc7Xskjjqu0mwvLYEigKCrFNM09YQLTBRFb7dyEWEhDpvteWJoD/bDY sr672NJ0kX0c++ArxkdgVQO4eoBrfWmQZIQghndn7t9fp07zCKBlHgGe9dyZRDV7W7t6Ri+kZW6+bJ DHGK1eIjs9/HbwkHMmaIBLqLsIsVriQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:to:subject:message-id:date:from:mime-version:dkim-signature: dkim-signature:from; bh=cRUhQaBw7YzwPyuGui/nk0FMe8GRRpAhFzELfrit8TE=; b=CqqJ48pF8Nf3v84E3NU7fiRn78TOH2v4Xn2DGEhi592Cy5t0whCpCcM24cGkCGzNDdoy+XL9VTyB6 frpdl0pU5vjYDXZuDpOkUsxHmbuQgwXUYK79Qr4i732SqxpU2iHWEc6uXao2bZByxVQC2Tw0n4HYGq rBryqDLPLr8hVov+faNdKzeRMg8d9gkmLV+pgsqeQk/vIzF/RAfpl5d7x7NemdXaApShI5ao96bhel wmjm5vXCRGcchJ8s6Y21KP3RbJxzrCo9DGkRUJ9Ok5Wy/NZew//CmyANa0FYGo2qqbSJsKWze/FVLG 8fWjEUQnTaKxgmjgEF+yNB6Uyv11g5A== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.167.174; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:to:subject:message-id:date:from:mime-version:from; bh=cRUhQaBw7YzwPyuGui/nk0FMe8GRRpAhFzELfrit8TE=; b=RT9Y5LtyZVig4QoLrMAXYjuwKTk3yFXYdiCcbkOOLK6FpBPgpuq9cmgwMkidtzT8rk35bhjSH63h+ J0bQejzneEi0LRro4tW56Mc2ctUHVQY6plztCiKlRP+E1P3BWYQ/6CeORPl7igyj1VxmrMwG9bvn32 qInql9wyCjQHQwO8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:to:subject:message-id:date:from:mime-version:from; bh=cRUhQaBw7YzwPyuGui/nk0FMe8GRRpAhFzELfrit8TE=; b=ta95w4efeOc3vkRaUtcH34zE32Vgk8wQE5B99sPEYmNa2BLX3oCub7nBHsA+1SzrsvV/EeVBetF6S x/bEysjuw+NTWUzS70wfHsRkWyX8kCNLyZBmZvHQrGxeFeizG2/f8FXXKX2qF/SLX4h6EpjDb3HzCA AfL1yJ4hy2Grnd2mb9is3F0UhJ/tsljZ6OniB+QOZvWZezbRSy9/4mXsDxrbI6W1LJDCz5MddTyvDQ 8knAzrRc/y0rfQTbJuqvQ/0MiB94WwrFukOR1d7geD2ckTRaQoAB3/jB5ZjnWtthdXjrEXVGpRKZ8l flnP4fD7TX9SI/QXcBFop4mV0o8KaBQ== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 69efeda1-6963-11ea-9eb3-25e2dfa9fa8d X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.167.174 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-oi1-f174.google.com (unknown [209.85.167.174]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 69efeda1-6963-11ea-9eb3-25e2dfa9fa8d; Wed, 18 Mar 2020 21:57:09 +0000 (UTC) Received: by mail-oi1-f174.google.com with SMTP id w13so509484oih.4 for ; Wed, 18 Mar 2020 14:57:09 -0700 (PDT) X-Gm-Message-State: ANhLgQ0vlL5ioKDZ3Vi5DbwivnwOXdNldjuJvtEx2UhyQUMalmZ2URqG TnB12pWmovXjBz4++9yEfBsUNZ94XHbYZtoBDnE= X-Google-Smtp-Source: ADFU+vvu+l/JlWH7yBYSsjxvgVnsE46J4ax7z+FIBQ1b+4MH2PueanxzNxJM3p35M7Ouya9vE1hceMXUVdO5wyYAgug= X-Received: by 2002:aca:b1d4:: with SMTP id a203mr53201oif.91.1584568628558; Wed, 18 Mar 2020 14:57:08 -0700 (PDT) MIME-Version: 1.0 From: Patrick McManus Date: Wed, 18 Mar 2020 17:56:57 -0400 X-Gmail-Original-Message-ID: Message-ID: To: v3@ietf.org Content-Type: multipart/alternative; boundary="0000000000003a405805a12822b8" Archived-At: Subject: [V3] Dispatch-WG Draft On SRT (Secure Reliable Transport) FYI X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 21:57:20 -0000 --0000000000003a405805a12822b8 Content-Type: text/plain; charset="UTF-8" Hello my ript friends. I'm looking forward to the BoF! But today, as co-chair of the ART Dispatch WG I am writing to let you know about a draft that will be presented in that group on a 'as time allowed basis' during the virtual meeting next week. We believe you may have some interest and expertise in its content. The draft is https://datatracker.ietf.org/doc/draft-sharabayko-mops-srt/ Abstract This document specifies Secure Reliable Transport (SRT) protocol. SRT is a user-level protocol over User Datagram Protocol and provides reliability and security optimized for low latency live video streaming, as well as generic bulk data transfer. For this, SRT introduces control packet extension, improved flow control, enhanced congestion control and a mechanism for data encryption. After consultation with the transport and art AD's we believe this may be of interest to both communities. The goal of the dispatch WG is to help identify the next step of a draft that is not currently adopted by a WG (possibilities include but are not limited to a BoF, an existing WG, a new WG, or more refinement on mailing lists). The group makes recommendations but cannot actually require any of those actions. Come be part of our group! Information on the Dispatch WG mailing list is here: https://www.ietf.org/mailman/listinfo/dispatch The virtual meeting is Monday at 22:10 UTC aka https://www.timeanddate.com/worldclock/fixedtime.html?msg=dispatch+meeting&iso=20200323T2210&p1=1440&ah=2 This work at least intersects with the interests of several areas and groups, so please tolerate multiple copies of this invitation. -Patrick --0000000000003a405805a12822b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello my ript friends. I'm looking forward to the= BoF!

But today, as co-chair of the ART Dispatch W= G I am writing to let you know about a draft that will be presented in that= group on a 'as time allowed basis' during the virtual meeting next= week. We believe you may have some interest and expertise in its content.<= br>
The draft is=C2=A0https://datatracker.ietf.org/doc/draft-sharabayko-mop= s-srt/

Abstract

   This document specifies Secure Reliable Transport (SRT) protocol.
   SRT is a user-level protocol over User Datagram Protocol and provides
   reliability and security optimized for low latency live video
   streaming, as well as generic bulk data transfer.  For this, SRT
   introduces control packet extension, improved flow control, enhanced
   congestion control and a mechanism for data encryption.
After consultation with the transport and art AD's we believe thi= s may be of interest to both communities. The goal of the dispatch WG is to= help identify the next step of a draft that is not currently adopted by a = WG (possibilities include but are not limited to a BoF, an existing WG, a n= ew WG, or more refinement on mailing lists). The group makes recommendation= s but cannot actually require any of those actions. Come be part of our gro= up!

Information on the Dispatch WG mailing list is= here:=C2=A0http= s://www.ietf.org/mailman/listinfo/dispatch


This work at least intersec= ts with the interests of several areas and groups, so please tolerate multi= ple copies of this invitation.

-Patrick
--0000000000003a405805a12822b8-- From nobody Fri Mar 20 10:30:10 2020 Return-Path: X-Original-To: v3@ietf.org Delivered-To: v3@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 750863A0D59; Fri, 20 Mar 2020 10:29:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Agenda To: X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158472539746.13570.11062487766981484925@ietfa.amsl.com> Date: Fri, 20 Mar 2020 10:29:57 -0700 Archived-At: Subject: [V3] Virtual IETF 107 Meeting WebEx Invitation: RIPT X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 17:30:09 -0000 RIPT Session at IETF 107 Thursday, March 26, 2020 22:10-00:10 UTC Join meeting: Meeting number (access code): 646 916 587 Meeting password: avEzuWXp427 IETF 107 Agenda: From nobody Mon Mar 23 07:21:11 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBEB3A05A0 for ; Mon, 23 Mar 2020 07:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.364 X-Spam-Level: X-Spam-Status: No, score=-3.364 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-1.463, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fivn.onmicrosoft.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 x5aaXi2j4TUg for ; Mon, 23 Mar 2020 07:21:04 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2081.outbound.protection.outlook.com [40.107.93.81]) (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 8482F3A0745 for ; Mon, 23 Mar 2020 07:21:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fQJ4JhBdG2CSbPsjyFHjQ1rpnQ6JSpIlOKkmvAZoKdgb8ZWPw6LGaB/5s2b5bgg2sS6t32Xr7jb5bdKm/1NyaA0wCXxgs9he7McsxpkZ43pTDDYe/odNW6bBWIij1TexlCd3QWxrfXjiGK3Vc7950Bz1dO2L6SxsvIWUXd8GtuogrAY+uyj1MCefd/pzcdhbTeQWQ+qlUoZRYOan7+OzeGjjejun7mccgsuOTAW+pQ21aQW7p1/3t+BLCggMggRpzc+x226Hg+9oRqGalL7W+xcyOtJIbREZcCwc0KcVLaByVZflHanKOWI79dV8svUuOuQZZtMlvZP64OmtEEa9aQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xOGbBd3qe9U5n0F+yy0hKqOgJiHbanhJA9XVafdFMEE=; b=HnAuR+SWjHOv3LRvhtm3FHl7pXKRlaaK7NgLp4LzKZI0gHyPWiv65IlocM/y1rDZ40dRHFuzThhH0Co7CgZZ+bl3eW3gUwYoONmequpf8ndJG0kFs5WN0nxzAyvp28aimnCfUdbypfjdHSI2+g0LwcwMZ46VgNLWkdLyaQOATUpZhR+2mWN2U9Zb5f7aykMzLO3n0ImHpGyatuJVEM5NZKT1y0ppSwKU9/uTKJ6oUVeZPiMbv3pDZJWhBYD8jMX3DrLM5h5V/jo3nF2eCQIqq+yEGnJnAgoeqZld+evIvbMVrCnaDOOqg3Pt6APVoQGI2uvDWRSDHRSNZMs0rGK3CQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=five9.com; dmarc=pass action=none header.from=five9.com; dkim=pass header.d=five9.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fivn.onmicrosoft.com; s=selector2-fivn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xOGbBd3qe9U5n0F+yy0hKqOgJiHbanhJA9XVafdFMEE=; b=IbHQ5vkNYYJbovsCx3om/DStHoiZhHMqRO6iOXSguotYHJVoz4ggkHzaGSdwrmSnq+us0N3lu6jCI97L/oeZMx+7i5L+2uT1Wm8ZzIA1ziwz26SFVuadeX13tuRoihd1ZDGaXk8ywzarid/NNUJUlHrfu150RTjAaRJidUa+w4s= Received: from BYAPR06MB4391.namprd06.prod.outlook.com (2603:10b6:a03:12::26) by BYAPR06MB5480.namprd06.prod.outlook.com (2603:10b6:a03:dc::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.20; Mon, 23 Mar 2020 14:21:01 +0000 Received: from BYAPR06MB4391.namprd06.prod.outlook.com ([fe80::21c5:6201:54:13d4]) by BYAPR06MB4391.namprd06.prod.outlook.com ([fe80::21c5:6201:54:13d4%2]) with mapi id 15.20.2835.021; Mon, 23 Mar 2020 14:21:00 +0000 From: Jonathan Rosenberg To: "v3@ietf.org" Thread-Topic: Thoughts on scope for ript Thread-Index: AdYBHf0Yy+O2W8g+RMGhiSdyDOSXPQ== Date: Mon, 23 Mar 2020 14:21:00 +0000 Message-ID: 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=jdrosen@five9.com; x-originating-ip: [108.35.46.157] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3123bb56-16d8-4035-f605-08d7cf356975 x-ms-traffictypediagnostic: BYAPR06MB5480: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(396003)(39850400004)(376002)(346002)(199004)(76116006)(66446008)(66476007)(8676002)(81166006)(81156014)(7696005)(52536014)(316002)(2906002)(5660300002)(478600001)(6506007)(6916009)(26005)(186003)(66946007)(64756008)(66556008)(8936002)(9686003)(71200400001)(86362001)(55016002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR06MB5480; H:BYAPR06MB4391.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: five9.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QH4ozZPQFSikFHF4knZYkyInHQajnsCOTVAhhxruOjY8RUPXZ6vZRDLRN8I1w6gdcLB+3MN8wjq4Prbo2yk7MlKT6TK+4RQg5IkMjLbX9efGk2hx1k3rlYU7Wb2y+WbOZW5le7pqH5V9+KBHNyDsi2LPgSVkdSfJbe5mO4SCHIB4WesObiNLmumyiV8u6ADz4D6AlL3HzdPShjhqVUCmRFrGSSbiLjM4bZjZsCFdooIvjBMQF7l16QU4ss530vRz+F0sOKI0KIbCrz/K4tcYjrKlsgrZLxeRd8k9ValELVM7/vpDkWUPPg1zknUaYuchU2XlZlmbcYmr8qSroLufFv9To6FwhPvQNdgch2vtq2gbtoZLLlo/IH3fqYgPTGboZ+m8NHEVqLTcRm7A2bzvifmlHU33Oy/V4PV8MQClhzDJsSbc5JZWBpECZzF73t+G x-ms-exchange-antispam-messagedata: omkzvRqX5pcOyAQKxl28Tl0TL5LkMnBEBQxKco3b/WXEtgyUjDLSf6qlzGRUfoGt9xaF5Ai0rPnsJtpenuUz2QkzNxV/4X5oHtXdKLeSKfzNQpMEwMAdr8PgU4rlMp1o2klR7oYbMKyAcQzXCaolnA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: five9.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3123bb56-16d8-4035-f605-08d7cf356975 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2020 14:21:00.4250 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f6c5114f-7396-4a09-af1e-98ee46f99bdb X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: e8nKY2oUzXT4jqCXeJcbIM3+sxnkrFSv1amQvpMlxbSFgc1jpBNbzd2ANd9S4duwxmCnDZKQnuGT8TNLGNo1Sg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB5480 Archived-At: Subject: [V3] Thoughts on scope for ript X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 14:21:09 -0000 With our BoF coming up this Thursday, I thought the time is right to restar= t discussions with a focus in particular on SCOPE of the effort. For me its defined entirely by the GOAL. The goal is: It is possible to implement a ript server in public cloud, such that it is = nothing more than a web application as far as public cloud is concerned, an= d therefore works with web-centric features such as Kubernetes, global http= load balancers, and service meshes - to name a few. The server implements = everything needed to make and receive voice and video calls. I do think the scope needs to be inclusive of server to server peering, not= just client to server. The client-to-server stuff defines the core, but fo= r me I'm really interested in building an alternative to sip trunking and t= hat requires solving for additional things (inbound load balancing, inbound= authentication, number routing). I think those can easily be in a separate= draft but I think they should be in scope. Thx, Jonathan R. -- Jonathan Rosenberg CTO and Head of AI, Five9 ________________________________ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= . From nobody Mon Mar 23 07:50:14 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8153A08C7 for ; Mon, 23 Mar 2020 07:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 Tqz20B8q8IJK for ; Mon, 23 Mar 2020 07:49:59 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 9EF083A08AD for ; Mon, 23 Mar 2020 07:49:58 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id r24so14931813ljd.4 for ; Mon, 23 Mar 2020 07:49:58 -0700 (PDT) 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=zCigoqCO8pYn81XHHrh4/LMnQoXwnhAkr1fMi9oBSag=; b=IWNNxcYKd7BjFlm9gmjeFLcsD9x0F5ldxody+yE9Su3Govbjb4DHAJaMGXHoMaazAc VFAFRsloQ/88ih8lJwUIvOV1poeRYDBNCl1ERQLuEPRzqQCjR7QFDhgJZn8A2pTnqNaZ 1cVEWGffg3SHokmQP132WpmG2mwSvvQzJMNQdehhqzSR57PuX3oLpw6BsgnHW7f38SI9 fieqh45ZTlk03Hyi11c5IeFvXoPbkcM1BGbBkNmY7+OQqPDrYFx9+9AJlNkIU7Ve1bYH k25MCFRHaImpeU1SHGoZfxj7AIi3fTh4Sb5Q/Rirdr7Wi0mvFYGB1uwTNtKReJ0aBf3M CVSA== 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=zCigoqCO8pYn81XHHrh4/LMnQoXwnhAkr1fMi9oBSag=; b=qhk0fhsQFxp+dciB7FNKYuqNIjusbhWu+dMS/lL8I5fEj4agaGwsHISccxNNsKIi2P I4tOOrvdjHVpTqDxu5QS7Lx/gScuFV1FxEZhwbQ237KSYj4biVTSEROooDtrsekOA7Xv vBcHNNQQuUZE2jO1g5TYZxgpw/getHYHF2YmEX7BcOiJnWBs+nG7ObrYJhlJbauTqHeu zp0ACgIzCuyxLXYHuIyJ3hMrFiT/hA0e+nUR+PA1+GqsexzA8/I7CTpRGIuvku5MFabD 9vrWc/86BmABjKWY4rDeBBVITwNGi3n10nbOsXqBh7IolxGpXNKyJtRkuuGrYGkYsvJA d/+Q== X-Gm-Message-State: ANhLgQ00GWBsGk6IONPq/aNUDwbuN7PeHVbusk4YGLlGyzsZSIx+DGil xropIzyy9tAmRgkqPHUjGkRfe8MyvmmpMceFqnnYNc2F90A= X-Google-Smtp-Source: ADFU+vukrq86JOh/P0f4tLMeO1Z7DW3Ia/P6A6r4aBN9+Ri3QMxtCviQi2eSbx/HjHAJPg6wxDAHDpUhloldJLkmZwA= X-Received: by 2002:a2e:81cc:: with SMTP id s12mr14434257ljg.35.1584974995678; Mon, 23 Mar 2020 07:49:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Mon, 23 Mar 2020 07:49:19 -0700 Message-ID: To: Jonathan Rosenberg Cc: "v3@ietf.org" Content-Type: multipart/alternative; boundary="00000000000098786f05a186bf8e" Archived-At: Subject: Re: [V3] Thoughts on scope for ript X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 14:50:11 -0000 --00000000000098786f05a186bf8e Content-Type: text/plain; charset="UTF-8" Hi Jonathan, As I said in my review [0] I don't think that the current draft achieves this, and I think it's lead to a number of fairly misguided design decisions (with byways being perhaps the most obvious). More to the point, the future is bigger than the past. H3 is not widely deployed yet, and so we should think about how we want things to look, not tie ourselves in knots trying to fit the precise current environment copied onto H3. -Ekr [0] https://mailarchive.ietf.org/arch/msg/v3/V2BuGEZJpEMcAKcYLNHDMtV3i70/ On Mon, Mar 23, 2020 at 7:21 AM Jonathan Rosenberg wrote: > With our BoF coming up this Thursday, I thought the time is right to > restart discussions with a focus in particular on SCOPE of the effort. > > For me its defined entirely by the GOAL. The goal is: > > It is possible to implement a ript server in public cloud, such that it is > nothing more than a web application as far as public cloud is concerned, > and therefore works with web-centric features such as Kubernetes, global > http load balancers, and service meshes - to name a few. The server > implements everything needed to make and receive voice and video calls. > > I do think the scope needs to be inclusive of server to server peering, > not just client to server. The client-to-server stuff defines the core, but > for me I'm really interested in building an alternative to sip trunking and > that requires solving for additional things (inbound load balancing, > inbound authentication, number routing). I think those can easily be in a > separate draft but I think they should be in scope. > > Thx, > Jonathan R. > > -- > Jonathan Rosenberg > CTO and Head of AI, Five9 > > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain > confidential information of Five9 and/or its affiliated entities. Access by > the intended recipient only is authorized. Any liability arising from any > party acting, or refraining from acting, on any information contained in > this e-mail is hereby excluded. If you are not the intended recipient, > please notify the sender immediately, destroy the original transmission and > its attachments and do not disclose the contents to any other person, use > it for any purpose, or store or copy the information in any medium. > Copyright in this e-mail and any attachments belongs to Five9 and/or its > affiliated entities. > > -- > V3 mailing list > V3@ietf.org > https://www.ietf.org/mailman/listinfo/v3 > --00000000000098786f05a186bf8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jonathan,

As I said in my= review [0] I don't think that the current draft achieves this, and I t= hink it's lead to a number of fairly misguided design decisions (with b= yways being perhaps the most obvious).

More to the= point, the future is bigger than the past. H3 is not widely deployed yet, = and so we should think about how we want things to look, not tie ourselves = in knots trying to fit the precise current environment copied onto H3.
<= /div>

-Ekr



On Mon, Mar 23, 2020 at 7:21 AM = Jonathan Rosenberg <jdrosen@five9.com> wrote:
With our BoF coming up this Thursday, I thought the tim= e is right to restart discussions with a focus in particular on SCOPE of th= e effort.

For me its defined entirely by the GOAL. The goal is:

It is possible to implement a ript server in public cloud, such that it is = nothing more than a web application as far as public cloud is concerned, an= d therefore works with web-centric features such as Kubernetes, global http= load balancers, and service meshes - to name a few. The server implements = everything needed to make and receive voice and video calls.

I do think the scope needs to be inclusive of server to server peering, not= just client to server. The client-to-server stuff defines the core, but fo= r me I'm really interested in building an alternative to sip trunking a= nd that requires solving for additional things (inbound load balancing, inb= ound authentication, number routing). I think those can easily be in a sepa= rate draft but I think they should be in scope.

Thx,
Jonathan R.

--
Jonathan Rosenberg
CTO and Head of AI, Five9


________________________________

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= .

--
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3
--00000000000098786f05a186bf8e-- From nobody Mon Mar 23 10:09:46 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE66E3A0C83 for ; Mon, 23 Mar 2020 10:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 0LFmUM3yvDRI for ; Mon, 23 Mar 2020 10:09:37 -0700 (PDT) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 3A7903A0C67 for ; Mon, 23 Mar 2020 10:09:37 -0700 (PDT) Received: by mail-ua1-x929.google.com with SMTP id 9so5241002uav.12 for ; Mon, 23 Mar 2020 10:09:37 -0700 (PDT) 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=Fj5u0D8vphH+KOiNq62iiaqPjH4Yy0xIkpAsI9bF4uU=; b=pxsJiCl45+wZ+2okeWf26Ey0Y/TAPzFhz3k/XKjq6xhYyMm7p7SX6n/Uh/DG0F6rY4 X9bE1pdKzCyzDRm98/W9vcvhXv6cEvV0d5K5terTOLWoJmma3CStOaxUTo94Jr11g3g/ W0M2+8ZoNweK9qx2B1jCCvTf4Gl+BL1EN+iOgOwHQ/7EBxTMfbYYrxRoyrSz+Ic4DbY0 Tg+ylaueG5ZbbqdwECEkdiBwGMJiP+ielLYBzJWoJ0z8uPnOaGmq8728pcqNL+DuFnPq 5dEtN/g5hP2aGDGC0poFBh2dSLvBfSS8NFpPOE2C7DQIV6O1fMXqgGTOYBYL5Nl2mu9g V6Cw== 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=Fj5u0D8vphH+KOiNq62iiaqPjH4Yy0xIkpAsI9bF4uU=; b=QfMMN2ziv1OnM5AUSgF1e1EnfVB9R3qEzOumOJNiG1s7DpLY36pTjkyEvMRMT92ZxS Pu+Frv0+8urVYa8J9BvWCcC+3FpbOqWKInwkCIiX4jnINe2XdOSWlXD+3oVLGOG/ZyJN Sz71FuSrBiRg3eY6GzOBT7Xh2ukvjanPhh0EDg8ZJp6T+XGNh2UBB26nW2VGlElImuZ5 HjoX0gkrYtgOjwqJ0IfYqGhfXd3P5q5NS4bif/iK+aAYVD90apqHEHWAxY7GDukBj0xW 5Tw227MBUFwu2Vc5AjtLOzSWqYahJtr1K0RTgUy/+pSIFI3PLlWEl5fskwUF6wGwWnSa aFWA== X-Gm-Message-State: ANhLgQ0+S5IWs3zeB8N94WKn8xLxLLpjVvYbCOearmf7ZiAPC9PQdmlD E3hN7WekhbaatVmflkTG0nIaX3XnoDkAF3JicCGHGlj74lE= X-Google-Smtp-Source: ADFU+vsK/WejJyFsHe66TLcHJ7AzJnUyHPOyMyayZdTBn2Rpf250UtX2FnI5aQg53e6sMCJmVY5hlSM1ChAGnQnanXc= X-Received: by 2002:ab0:21ce:: with SMTP id u14mr14614437uan.23.1584983375455; Mon, 23 Mar 2020 10:09:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Mon, 23 Mar 2020 10:09:22 -0700 Message-ID: To: Jonathan Rosenberg Cc: "v3@ietf.org" Content-Type: multipart/alternative; boundary="00000000000012347205a188b3fa" Archived-At: Subject: Re: [V3] Thoughts on scope for ript X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 17:09:43 -0000 --00000000000012347205a188b3fa Content-Type: text/plain; charset="UTF-8" In addition to Eric's comments, I think the biggest question regarding goals and scope is whether we focus on both client-to-server and server-to-server. If we are taking a fresh look at how all of IP calling works, we could find ourselves looking at: a) a replacement for SIP "RPCs" (i.e, how are commands reliably exchanged) b) a replacement for SIP operations and routing (i.e., the specific commands and routing mechanisms) c) a replacement for offer-answer (i.e., how do both sides agree on media formats) d) a replacement for SDP (i.e., the details of how media formats are described) e) a replacement for SRTP (i.e., how media is transmitted from point A to B) f) a replacement for RTP packetization (i.e., how media is encapsulated when transmitted) I think that server-to-server, essentially a NNI, requires us to consider all of these items, and that may ultimately make sense. However, if we focus initially on client-to-server, we can get by by only focusing on e) and f), as a-d) are under application control This could still provide a lot of value, since moving to a world where even private RTC services can be built atop HTTP would still be quite an accomplishment. (Compared to the current state of the world, where people deploying cloud RTC services need to source and deploy their own ICE/DTLS/SCTP/SRTP stacks and all the load balancing/authentication/failover tech that Jonathan mentions). It would also be complementary to WebRTC, which works pretty well for p2p applications, but struggles in c2s environments for the aforementioned reasons. On Mon, Mar 23, 2020 at 7:21 AM Jonathan Rosenberg wrote: > With our BoF coming up this Thursday, I thought the time is right to > restart discussions with a focus in particular on SCOPE of the effort. > > For me its defined entirely by the GOAL. The goal is: > > It is possible to implement a ript server in public cloud, such that it is > nothing more than a web application as far as public cloud is concerned, > and therefore works with web-centric features such as Kubernetes, global > http load balancers, and service meshes - to name a few. The server > implements everything needed to make and receive voice and video calls. > > I do think the scope needs to be inclusive of server to server peering, > not just client to server. The client-to-server stuff defines the core, but > for me I'm really interested in building an alternative to sip trunking and > that requires solving for additional things (inbound load balancing, > inbound authentication, number routing). I think those can easily be in a > separate draft but I think they should be in scope. > > Thx, > Jonathan R. > > -- > Jonathan Rosenberg > CTO and Head of AI, Five9 > > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain > confidential information of Five9 and/or its affiliated entities. Access by > the intended recipient only is authorized. Any liability arising from any > party acting, or refraining from acting, on any information contained in > this e-mail is hereby excluded. If you are not the intended recipient, > please notify the sender immediately, destroy the original transmission and > its attachments and do not disclose the contents to any other person, use > it for any purpose, or store or copy the information in any medium. > Copyright in this e-mail and any attachments belongs to Five9 and/or its > affiliated entities. > > -- > V3 mailing list > V3@ietf.org > https://www.ietf.org/mailman/listinfo/v3 > --00000000000012347205a188b3fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In addition to Eric's comments, I think the biggest qu= estion regarding goals and scope is whether we focus on both client-to-serv= er and server-to-server.=C2=A0

If we are taking a fresh = look at how all of IP calling works, we could find ourselves looking at:
a) a replacement for=C2=A0SIP=C2=A0"RPCs" (i.e, how are commands reliably= exchanged)
b) a replacement for SIP operations and routing (i.e.= , the specific commands and routing mechanisms)
c) a replacement = for offer-answer (i.e., how do both sides agree on media formats)
=
d) a replacement for=C2=A0SDP (i.e., the deta= ils of how media formats are described)
e) a replaceme= nt for SRTP (i.e., how media is transmitted from point A to B)
f)= a replacement for RTP packetization (i.e., how media is encapsulated when = transmitted)

I think that server-to-server, essent= ially a NNI, requires us to consider all of these items, and that may ultim= ately make sense. However, if we focus initially on client-to-server, we ca= n get by by only focusing on e) and f), as a-d) are under application contr= ol

This could still provide a lot of value, since = moving to a world where even private RTC services can be built atop HTTP wo= uld still be quite an accomplishment. (Compared to the current state of the= world, where people deploying cloud RTC services need to source and deploy= their own ICE/DTLS/SCTP/SRTP stacks and all the load balancing/authenticat= ion/failover tech that Jonathan mentions). It would also be complementary t= o WebRTC, which works pretty well for p2p applications, but struggles in c2= s environments for the aforementioned reasons.


On= Mon, Mar 23, 2020 at 7:21 AM Jonathan Rosenberg <jdrosen@five9.com> wrote:
With our BoF coming up this Thursday, I th= ought the time is right to restart discussions with a focus in particular o= n SCOPE of the effort.

For me its defined entirely by the GOAL. The goal is:

It is possible to implement a ript server in public cloud, such that it is = nothing more than a web application as far as public cloud is concerned, an= d therefore works with web-centric features such as Kubernetes, global http= load balancers, and service meshes - to name a few. The server implements = everything needed to make and receive voice and video calls.

I do think the scope needs to be inclusive of server to server peering, not= just client to server. The client-to-server stuff defines the core, but fo= r me I'm really interested in building an alternative to sip trunking a= nd that requires solving for additional things (inbound load balancing, inb= ound authentication, number routing). I think those can easily be in a sepa= rate draft but I think they should be in scope.

Thx,
Jonathan R.

--
Jonathan Rosenberg
CTO and Head of AI, Five9


________________________________

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= .

--
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3
--00000000000012347205a188b3fa-- From nobody Mon Mar 23 15:23:15 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4693A0E87 for ; Mon, 23 Mar 2020 15:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=signalwire.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 ZDv0NLVStdSc for ; Mon, 23 Mar 2020 15:22:48 -0700 (PDT) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 00DB83A0E7C for ; Mon, 23 Mar 2020 15:22:44 -0700 (PDT) Received: by mail-ua1-x92a.google.com with SMTP id v24so111478uak.0 for ; Mon, 23 Mar 2020 15:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=signalwire.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p2R65nWdH1q4cp0PyoMkhWzckrjWGedYmhDJpOt5G3I=; b=MyabwxgK6IFN950qGZMamrRAC7oSaRqZ0q4HenRRtEBLOlfGw7Qr1rwrs0033UCckj Fx0y5etN5OMQMP3AoLqQ32v6cRz+73ohNyfwy0xhBoQHbtXHV5NVBvOzfa1ijf22fQn6 ZG8TQjHAkdkz4cuWnHLB0kNLB66RfgTrcc1Uk= 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=p2R65nWdH1q4cp0PyoMkhWzckrjWGedYmhDJpOt5G3I=; b=A12457+dfag52J8azvRqJynKcOoAIPpjpC1HB1diwXLe/ZCMCf8P8ZdP7mPMoX3ipi uNMWqFrP2fB3ZqzswCNWIr7xjYWDIGXUKouUkRRAxZbDEzcGXcJubGFbmWEqLHu1nBx5 mcR7EOS5Fn/VPLtMKV9GYLr5WZmmr//iEkgCNL+dMi6NM9lAPcZf9XbQKWGDR7CJOX/N ABl/c7V/miCkk9Nlb92B8uGbXiXfE0ZO0I8Jox8Q1jKWUU6Tz9xb7fm5G6IVqQZ+TofB WZkjob4BDned3iRqPeqfWo4ETYTGw8UsmpqZ/zSuaWcyfoimCtRM7HoZFdpi6xypuQb2 l/6Q== X-Gm-Message-State: ANhLgQ1Tl/TFmwliwecETg3X6U5PTt7CDTu1FuGlJlPah2pquBs17XmX XoqrxS+HQ9jh+ytknVT3s9kOB/DAJGsPVD/aDmQi8w== X-Google-Smtp-Source: ADFU+vuftilL6ecWJuH/ZelmC71Bl09r3UUcPmRVTnrWu+TFH9Cv4bESS2kzrkvlTum+TuSMhUUu2R814bgWTvH8tBs= X-Received: by 2002:ab0:2a1a:: with SMTP id o26mr15648234uar.62.1585002163523; Mon, 23 Mar 2020 15:22:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Anthony Minessale Date: Mon, 23 Mar 2020 17:22:31 -0500 Message-ID: To: Justin Uberti Cc: Jonathan Rosenberg , "v3@ietf.org" Content-Type: multipart/related; boundary="000000000000ed4f8805a18d1217" Archived-At: Subject: Re: [V3] Thoughts on scope for ript X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 22:23:14 -0000 --000000000000ed4f8805a18d1217 Content-Type: multipart/alternative; boundary="000000000000ed4f8605a18d1216" --000000000000ed4f8605a18d1216 Content-Type: text/plain; charset="UTF-8" Also more consideration for live translation to sip/rtp/webrtc and back-to-back scenarios. If calls are being loaded balanced to many servers you still probably will want a way to keep track of what calls are on what server in a way that goes out of scope of HTTP so the application doing the clustering will bear a pretty big burden of solving that problem from behind the cluster. I read the memo about replacing SIP and was slightly disturbed that RFC2833 (4733/4734) is the one thing salvaged ;) That would be the first to go IMHO, its the leading cause of interop issues in all of telephony and very rarely implemented to its full potential not to mention there are some timestamp translation issues I pointed out on the github discussion so that is it's own can of worms. Also, the description seems to be evolving more towards considerations about making calls behave like a web app which is fine because that's the GOAL but there is little consideration of actual trunking so far. SIP trunking is just a made-up marketing term to mirror original TDM trunking which was actual trunking (bundling many calls into one stream to reduce overhead) In reality SIP trunking is often just (a lot of SIP calls) We have our SIP setup so you can send many calls to many different phone numbers over a single registration and that causes introp issues because most people don't comprehend this lol. So it seems like there could be some improvements that could clean up issues with WebRTC and how web-app type environments can bust through nat etc. WebRTC is still compatible with SIP in the sense that you can carry a WebRTC SDP over sip and set up calls but most of the time its SIP over WebSockets (though FS and Kamailio can translate and negotiate WebRTC sessions to other SIP transports) >From a server perspective with density being a major concern, removing all the need for dialogs and route headers is a good thing. What I also think is critical to preserve is the server's ability to limit the media formats etc sent by the sender. Killing Offer/Answer is ok but the replacement should at least preserve the notions that a client can offer what it can do, the server can narrow that scope with its own requirements and the client must work within those shared formats. The server is the one who has to create thousands of connections etc and must not be treated as a simple peer-to-peer agent. Removing SRTP is another concern because it's pretty widely used now, it's required in WebRTC and decryption in the middle was something I was hoping we would go the other direction on and find ways to route encrypted packets without needing to decode them. I think if you want to replace SIP trunking more considerations have to be made for the mass translation of TDM/SIP/SS7 and how that works with routing and clustering. I think some of that is how we got into that boat with SIP because it was only later that this was tried and then workarounds abounded for years. On Mon, Mar 23, 2020 at 12:09 PM Justin Uberti wrote: > In addition to Eric's comments, I think the biggest question regarding > goals and scope is whether we focus on both client-to-server and > server-to-server. > > If we are taking a fresh look at how all of IP calling works, we could > find ourselves looking at: > a) a replacement for SIP "RPCs" (i.e, how are commands reliably exchanged) > b) a replacement for SIP operations and routing (i.e., the specific > commands and routing mechanisms) > c) a replacement for offer-answer (i.e., how do both sides agree on media > formats) > d) a replacement for SDP (i.e., the details of how media formats are > described) > e) a replacement for SRTP (i.e., how media is transmitted from point A to > B) > f) a replacement for RTP packetization (i.e., how media is encapsulated > when transmitted) > > I think that server-to-server, essentially a NNI, requires us to consider > all of these items, and that may ultimately make sense. However, if we > focus initially on client-to-server, we can get by by only focusing on e) > and f), as a-d) are under application control > > This could still provide a lot of value, since moving to a world where > even private RTC services can be built atop HTTP would still be quite an > accomplishment. (Compared to the current state of the world, where people > deploying cloud RTC services need to source and deploy their own > ICE/DTLS/SCTP/SRTP stacks and all the load > balancing/authentication/failover tech that Jonathan mentions). It would > also be complementary to WebRTC, which works pretty well for p2p > applications, but struggles in c2s environments for the aforementioned > reasons. > > > On Mon, Mar 23, 2020 at 7:21 AM Jonathan Rosenberg > wrote: > >> With our BoF coming up this Thursday, I thought the time is right to >> restart discussions with a focus in particular on SCOPE of the effort. >> >> For me its defined entirely by the GOAL. The goal is: >> >> It is possible to implement a ript server in public cloud, such that it >> is nothing more than a web application as far as public cloud is concerned, >> and therefore works with web-centric features such as Kubernetes, global >> http load balancers, and service meshes - to name a few. The server >> implements everything needed to make and receive voice and video calls. >> >> I do think the scope needs to be inclusive of server to server peering, >> not just client to server. The client-to-server stuff defines the core, but >> for me I'm really interested in building an alternative to sip trunking and >> that requires solving for additional things (inbound load balancing, >> inbound authentication, number routing). I think those can easily be in a >> separate draft but I think they should be in scope. >> >> Thx, >> Jonathan R. >> >> -- >> Jonathan Rosenberg >> CTO and Head of AI, Five9 >> >> >> ________________________________ >> >> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain >> confidential information of Five9 and/or its affiliated entities. Access by >> the intended recipient only is authorized. Any liability arising from any >> party acting, or refraining from acting, on any information contained in >> this e-mail is hereby excluded. If you are not the intended recipient, >> please notify the sender immediately, destroy the original transmission and >> its attachments and do not disclose the contents to any other person, use >> it for any purpose, or store or copy the information in any medium. >> Copyright in this e-mail and any attachments belongs to Five9 and/or its >> affiliated entities.. >> >> -- >> V3 mailing list >> V3@ietf.org >> https://www.ietf.org/mailman/listinfo/v3 >> > -- > V3 mailing list > V3@ietf.org > https://www.ietf.org/mailman/listinfo/v3 > -- Anthony Minessale | Founder and CEO SignalWire: *228 Hamilton Ave 3rd Floor, Palo Alto, CA 94303 * *https://youtu.be/WKjZkzgK4pc * https://youtu.be/MwqpSl7luSM https://youtu.be/l82JtCECkog Email: anthm@signalwire.com Phone: 262-309-8501 Website: https://www.signalwire.com --000000000000ed4f8605a18d1216 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Also more consideration for live transla= tion to sip/rtp/webrtc and back-to-back scenarios.
<= br>
If calls are being loaded balanced to many servers you still = probably will want a way to keep track of what calls are on what server in = a way that goes out of scope of HTTP so the application doing the clusterin= g will bear a pretty big burden of solving that problem from behind the clu= ster.

I read the memo about replacing= SIP and was slightly disturbed that RFC2833 (4733/4734) is the one thing s= alvaged ;)
That would be the first to go IMHO, its the leading ca= use of interop issues in all of telephony and very rarely implemented to it= s full potential not to mention there are some timestamp translation issues= I pointed out on the github discussion so that is it's own can of worm= s.

Also, the description seems to be evolving more= towards considerations about making calls behave like a web app which is f= ine because that's the GOAL but there is little consideration of actual= trunking so far.=C2=A0 SIP trunking is just a made-up marketing term to mi= rror original TDM trunking which was actual trunking (bundling many calls i= nto one stream to reduce overhead) In reality SIP trunking is often just (a= lot of SIP calls) We have our SIP setup so you can send many calls to many= different phone numbers over a single registration and that causes introp = issues because most people don't comprehend this lol.

So it seems like there could be some improvements that could clean = up issues with WebRTC and how web-app type environments can bust through na= t etc.
WebRTC is still compatible with SIP in the sense that you = can carry a WebRTC SDP over sip and set up calls but most of the time its S= IP over WebSockets (though FS and Kamailio can translate and negotiate WebR= TC sessions to other SIP transports)

From a se= rver perspective with density being a major concern, removing all the need = for dialogs and route headers is a good thing. What I also think is critica= l to preserve is the server's ability to limit the media formats etc se= nt by the sender.=C2=A0 Killing Offer/Answer is ok but the replacement shou= ld at least preserve the notions that a client can offer what it can do, th= e server can narrow that scope with its own requirements and the client mus= t work within those shared formats.=C2=A0 The server is the one who has to = create thousands of connections etc and must not be treated as a simple pee= r-to-peer agent.

Removing SRTP is another concern = because it's pretty widely used now, it's required in WebRTC and de= cryption in the middle was something I was hoping we would go the other dir= ection on and find ways to route encrypted packets without needing to decod= e them.

I think if you want to replace SIP trunkin= g more considerations have to be made for the mass translation of TDM/SIP/S= S7 and how that works with routing and clustering.=C2=A0 I think some of th= at is how we got into that boat with SIP because it was only later that thi= s was tried and then workarounds abounded for years.

On Mon, Mar 23, 2= 020 at 12:09 PM Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:
In addition to = Eric's comments, I think the biggest question regarding goals and scope= is whether we focus on both client-to-server and server-to-server.=C2=A0
If we are taking a fresh look at how all of IP calling wo= rks, we could find ourselves looking at:
a) a replacement for=C2=A0SIP=C2=A0"RPCs" (i.e, h= ow are commands reliably exchanged)
b) a replacement for SIP oper= ations and routing (i.e., the specific commands and routing mechanisms)
c) a replacement for offer-answer (i.e., how do both sides agree on = media formats)
d) a replacement for=C2=A0SDP (i.e., the= details of how media formats are described)
e) a repl= acement for SRTP (i.e., how media is transmitted from point A to B)
f) a replacement for RTP packetization (i.e., how media is encapsulated = when transmitted)

I think that server-to-server, e= ssentially a NNI, requires us to consider all of these items, and that may = ultimately make sense. However, if we focus initially on client-to-server, = we can get by by only focusing on e) and f), as a-d) are under application = control

This could still provide a lot of value, s= ince moving to a world where even private RTC services can be built atop HT= TP would still be quite an accomplishment. (Compared to the current state o= f the world, where people deploying cloud RTC services need to source and d= eploy their own ICE/DTLS/SCTP/SRTP stacks and all the load balancing/authen= tication/failover tech that Jonathan mentions). It would also be complement= ary to WebRTC, which works pretty well for p2p applications, but struggles = in c2s environments for the aforementioned reasons.


On Mon, Mar 23, 2020 at 7:21 AM Jonathan Rosenberg <jdrosen@five9.com> wrote:
<= /div>
With our BoF coming = up this Thursday, I thought the time is right to restart discussions with a= focus in particular on SCOPE of the effort.

For me its defined entirely by the GOAL. The goal is:

It is possible to implement a ript server in public cloud, such that it is = nothing more than a web application as far as public cloud is concerned, an= d therefore works with web-centric features such as Kubernetes, global http= load balancers, and service meshes - to name a few. The server implements = everything needed to make and receive voice and video calls.

I do think the scope needs to be inclusive of server to server peering, not= just client to server. The client-to-server stuff defines the core, but fo= r me I'm really interested in building an alternative to sip trunking a= nd that requires solving for additional things (inbound load balancing, inb= ound authentication, number routing). I think those can easily be in a sepa= rate draft but I think they should be in scope.

Thx,
Jonathan R.

--
Jonathan Rosenberg
CTO and Head of AI, Five9


________________________________

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= ..

--
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3
--
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3


--
--000000000000ed4f8605a18d1216-- --000000000000ed4f8805a18d1217 Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_jm25x25z1_165d8b71f782610b iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAFHElEQVRYCcVXXWgcVRT+ZnZ2d2Z3 093NJtmkmmyrTZOAWGORgFURC76JloIvgiJYCooYfJEqIsW/12pRiFrUJ0EsKvomFvEPqrSNIjQx at2kND/N3ya7O7szszPy3WQmk226s1qhBy737uw95zv33O+ce6/kOI6DJmRmQcfoH0uYmCpgcraI ueUKarU11VBIRnsqilw2gd7uJG7blUZnRmvCKiAFOTCWL+DkN3/j9Pl5zC3qwmgyEUGLFoYkr2HY NlDUTRRKBuAAHa0ahgbacPDeHejPJRs6clUHDMvGWyfP4/Pvp1DSTXSkNcSiIdpvKBKAcrWGuSUd cS2MB+/qxlMHBxBR1r2t097SgfxMES++dw6//rmE7o4YtKgC2w6C3mxZliXoVQtTc2XcenMaLz8x iFxnYvMkbLEFY5MFDL9xGoWiie5sHI7tBK76CqvrHxgNSZYwNVtCMhHGsWeG0N+zeUs2ReDi5RIe f+0HVA0LXZkYav9y1VdzJCRLuLRQFpF8/8g+3NAe96Z6G2NaDp4fOYti2WwaXJIAcoUEZCvpFphT /O4XLmR7JobVkokjI2dBLFc8B979Yhy/TCyKsAetnABsM4s6apYtCEqStqWikCWAWVEvtMktJQax XBFbcGG6iMde/Q7JWBhqpAmmSxJmFsq4b7ALj9x/E27MroWUpBs+/jPml3XE1bCL4fUMTMWooVA2 8eELd2NnVwIiAh9/fQFl3YKmKk0R7vJyBYO9rTh6aBC7c0nEVEW0TFIF99taL1Ae8vqAgScGsYhJ UZZWDfz42xyyrWpTqUYjlaqFA/fkPPuWZWN0YhFLRQOmaSMaDnn/1Q+YzsQiJrGVM+MLmF7QkeuM CwLVK9T/ZuUmwLZExPvrk1N5HP1gFJlUFNm0ihjrRoMKz4jlZ0ogtjyWXxbECYo9SUebZDpLLntX fr9YgGXbojwDEgIrhwOBSWyFVY+1fSMxXLObezKbDG9PaSIDImEvgdCajKInGxehZRmu1WxI9bno M0csYhJbevSVb52ibqEudX3T14aliom2lIZjT98BNaKIbAmF1rQM04Zp2ShVLDx7/CcsrFQRV5Ur bPg/0ImEpkDhkcqVNdgyoUdmk+Fker0wGmxqOISlFUPMq59T/5uYxG7spk+LxCPDT52ZFtu1Z1ca bevOjE8WRL1nYSL5tAZZ4DMphgrDaBukTmMhsyuGhZdOjOLSfAnvPLcP+/d2CaWPvvoLJ76cwO6e bchsU8FMCeSUAxBb5k2G9T9IuDISqz2lirOCFdMVpuT2thhSiaiIQBA49YjZkVIh57ItKBSNwAi4 YO454P5mz+ht9d0/xz/mfGLyfiAP7EhBnLpBe+C3cK1jHlgO0J9LQd7bl0FXRkO5slFYrtV+kD6x iElsOd0SwZ23dGB2sQJeo5oR8sHPASUkN3WO0DYxiEVMYoty9vD+nYhpCvRKcEGikZAsY6Vkiqhx NVWjBjoRJFweMYhFTIp3JXv70zGMfDaOvlwycDXiQIqEPNCqWROVUG5QfgnG1Y/nCzj8UB+ePNAv HPDcPvRAH/b0toqCworXSNwI8OrN1kwEaJOXU2IQyxXPgbAi4fXDt6MlHhYXyEZOuBxIaGGwBXGA tngppW1iEMsVzwF+4G31zeEhcZBMzpZEyDamuirN99Rl2GmLhxNt+2/EtORxwG/2uj5MXEeu69PM dYJ9M49TxwZW+TgtGkL1f3mc+p3guPHzXBIHS89/eJ7/A2tpgiJjIcQ7AAAAAElFTkSuQmCC --000000000000ed4f8805a18d1217 Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_jm25y73l3_165d8b7eee16c0ac iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAFJElEQVRYCcVXS2gdVRj+zpmZO3fu I++Yh6lJSaO1wXbRnS6EKq5EQREEwY2IC5e660Lc60oU3epGKAruRIrUgCCCikpt+rAmNeYmaR5t 7mPunTtnRr4zmfvK3NuEBvrD3BnmnvN/3/8+I8IwDHEA2aoGuF70sVxWWHcD7NQCqL2dhgAGbIlx R2I6a2Aub2I4LQ+gFRD3IrBUUvi+UMNfd3xseQEEgKwp9MVnSgDA9UOU/BDkNJySODVg4tyEjZmc sbcq+daVgB8AF5Yq+GG9DlcFGEpJpA2hAZJVRW9JqqpCbHsBHEPi6TELr8xkYHZxSCKBgqvw2dUK bhR9PJSOgIMDBapJTYqIyEY1wIm8ibcey2DC2e+NfQSWSwofXi6h7IcYcyQOC9ykED2RCHOGYXtn PofpjpC0OYZsP7hcQjU4GnBSoAE0hDqp+3aVGdOUBgE/BD5ZLGvLR+z7t7wJEZGgTnr148UyiBVL g8A3t1xc3/V1KR3G7XGsaRmvrVqgAViaLFNeTEzqZJkSg1ixaAKrFYXvVmttMY833fGieidQp/Ad ARnfc+MpvHAsjSdHU/CDECsVpUvTMYQuU+6Nw0EsYlJM/lws1PTi4RbX0005U+DMYAo/bdZRD4CM KRpJST5btRCzORNvPprBoN1wJn7ZrOPb1Sqen0rjxw0Pf+746E9FFrCUN6uBxnx9NgNZ9EL8sV1H KzhJVfxQA742m8GrMw7ueiE2a1Ejoqp6GIKYb8y1g3Pv2REL50/ncarfhAjR1gPoBWIRk9jmlbt1 bQnj05Ib2tLYpqfGUhhICVxYcnGzpHRDYmyfGOzdcl0FSIk2vSRIL6y5AYhtLpUDCLF/kW1At162 WMcUmB+0cLLfwqW1Gn7bruvWXI3CSJ37hBOGhBm+8XS7cTSUmMQ211ylk6hTg20IPXAuFWp47uE0 DAl9PTNpgxeTiOTo0qQEZYiuFX3kurRvJi6xTU41JlenMAeOZQ1teYAQhi6m5qrJzP622vwX8BRg CQFDtga2uYKYxJaMZRzr5t+AJQF2RnYxK8nE1sUJz7erCizhbnuJ2Q1bq7Ol0FONQ+nfsmqUXwJW 4qsbRYWSH4ANqZdILmjvztFyOi5nRZ1rpaSw6yWt6q761606Mt1m8N4ZgtiSJxkmU5LQTfUQsAyh TzxJa5LeEXxx10ef1d185hiblxx3DH2SSVJEhmkD+OJmBQtrHnhO8Jj2PYTGfPlPBRlDdKRt+yYO JmLL49lo8nVyZd65KtQdccMN8OnVMhYKXs9cYFJ9dKWsGxtbbzeqxGKfmMlKmI/3Wxixo4Rj7cdC S1iGZ4csDNkSo46BCSepXqId/5UVPv+7gmtFpdf1chSPbMO2ALHNfErg9JCFi6s1TGWNhoXsVIwT U+9En5nYKwi9Ulb4edPDwrqn5z1J9gKPJ+izkzaIrY9k7Grv/17UHTG1V/O8kemOFyJvCkxlDExk JPIWYyt03hQqSo9dDirOCrbsXuAkzBxi/N87kwebWeNM+NWyi6+Xq/rM1qqEQWGR0BvMiThIjC+H CpONTatbvOOQ8k6jeOZ8aTqNl6cd/Zc+D/DpxUccPbdvlVXbqYiKmRq0nFeSHBScE3Cuz9RYsZ5G VnEcvH0yq8PAub8XiXjdfd2pizo5gIjROnoaBIgwmpZ4dz6HtBT6KH0UJKiDx3LqpG5itEojB1pf PtAPk5jIA/00i0nwfpCPUyYhS4sXn4/k47SVBJ/v9XnOwcKzw2E/z/8HeJXK68Y+LqEAAAAASUVO RK5CYII= --000000000000ed4f8805a18d1217-- From nobody Mon Mar 23 15:43:20 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0652E3A0BDA for ; Mon, 23 Mar 2020 15:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.489 X-Spam-Level: X-Spam-Status: No, score=-17.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 iNaNpp913XqL for ; Mon, 23 Mar 2020 15:43:14 -0700 (PDT) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 9ED133A05AC for ; Mon, 23 Mar 2020 15:43:13 -0700 (PDT) Received: by mail-vk1-xa2f.google.com with SMTP id o124so4309868vkc.4 for ; Mon, 23 Mar 2020 15:43:13 -0700 (PDT) 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=ycPAtK00Fr2ZZ5+iW0R3GBsa4E6b9BoH5l5D+ob3jus=; b=pPINqh90zyKq05FqUFqZhMoTPXkjgSf3J0gPuHLivOngR2IOCAqqy4guGvKHaVgjNI /Ttr/9eFjjgIn87G6p+v8ED3fD3Vm213da3cTlvZwVDW/QuI7fIcBgFsemU6UAa1ijnl QigLI5MJipE5MdA+8olDV/pUkXvhtLR16Pm01SfJwOBD9M+BuVrUqomJmR/XwbQx0Aw3 0j0SoebNFVvIASNE1LoAqKf0ED3pMFWO3/d9wh2BvQQsISDL71kVRew6s9vNGEe7eLtR 68GADF3aBGJNk0TdCNvkmdHxZ/K3YxWScxBla2DI/rtvtIgyzj8MZ0Vknctl8VdGyOcZ kUPg== 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=ycPAtK00Fr2ZZ5+iW0R3GBsa4E6b9BoH5l5D+ob3jus=; b=AvHDTzmqYIhDHtx47d3v6dOHzFLIsGyOYbyzYby+AHDeP2sbTUhreE7EBu8+gAw4bS R9lyaFmJZoeh6TPZokKZdNZJ0c4nCJttgQKvBs434ulq7cAnO1lX5vw0dgvXijMSwe8a sRTLV7or8k1eQTHuUoethdHOazjv8JAjaHVdEVX2KfLBb0v+akf921IFb9XCgwFlPDmK J5TDO1jyesXsIB/0kze7GmYvDxPgGIrPtJ66N7HGq82RY/kKetn4I+IbQ8MHaL5FlBCB +KWPN18z9zdB7QQeofnxXQC2Oed/dbxhMhlv6cwf7hFtkBoCw5mASEgA/uQ4fKAhgXvy TxaA== X-Gm-Message-State: ANhLgQ2XTtk9xHPkhcDwbnXLcIIoR1eopkZnG1WYR6JsO7XBaS4YIj2W c61vL5n/GQeny9b1SxYz98YfLxLelbyhp/uRR5yyPA== X-Google-Smtp-Source: ADFU+vtknME3X8W/GfCrR9ThztOK3fCiUUQhwobSGuS1SvuQPfNBnMvJu0o0HKq0GP2jaulnPdltLVqUNFkA4XN8s2U= X-Received: by 2002:a05:6122:2d0:: with SMTP id k16mr3124937vki.54.1585003391822; Mon, 23 Mar 2020 15:43:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Mon, 23 Mar 2020 15:43:00 -0700 Message-ID: To: Anthony Minessale Cc: Jonathan Rosenberg , "v3@ietf.org" Content-Type: multipart/related; boundary="000000000000246d5005a18d5c43" Archived-At: Subject: Re: [V3] Thoughts on scope for ript X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 22:43:18 -0000 --000000000000246d5005a18d5c43 Content-Type: multipart/alternative; boundary="000000000000246d5005a18d5c42" --000000000000246d5005a18d5c42 Content-Type: text/plain; charset="UTF-8" On Mon, Mar 23, 2020 at 3:24 PM Anthony Minessale wrote: > Also more consideration for live translation to sip/rtp/webrtc and > back-to-back scenarios. > > If calls are being loaded balanced to many servers you still probably will > want a way to keep track of what calls are on what server in a way that > goes out of scope of HTTP so the application doing the clustering will bear > a pretty big burden of solving that problem from behind the cluster. > > I read the memo about replacing SIP and was slightly disturbed that > RFC2833 (4733/4734) is the one thing salvaged ;) > That would be the first to go IMHO, its the leading cause of interop > issues in all of telephony and very rarely implemented to its full > potential not to mention there are some timestamp translation issues I > pointed out on the github discussion so that is it's own can of worms. > > Also, the description seems to be evolving more towards considerations > about making calls behave like a web app which is fine because that's the > GOAL but there is little consideration of actual trunking so far. SIP > trunking is just a made-up marketing term to mirror original TDM trunking > which was actual trunking (bundling many calls into one stream to reduce > overhead) In reality SIP trunking is often just (a lot of SIP calls) We > have our SIP setup so you can send many calls to many different phone > numbers over a single registration and that causes introp issues because > most people don't comprehend this lol. > > So it seems like there could be some improvements that could clean up > issues with WebRTC and how web-app type environments can bust through nat > etc. > WebRTC is still compatible with SIP in the sense that you can carry a > WebRTC SDP over sip and set up calls but most of the time its SIP over > WebSockets (though FS and Kamailio can translate and negotiate WebRTC > sessions to other SIP transports) > > From a server perspective with density being a major concern, removing all > the need for dialogs and route headers is a good thing. What I also think > is critical to preserve is the server's ability to limit the media formats > etc sent by the sender. Killing Offer/Answer is ok but the replacement > should at least preserve the notions that a client can offer what it can > do, the server can narrow that scope with its own requirements and the > client must work within those shared formats. The server is the one who > has to create thousands of connections etc and must not be treated as a > simple peer-to-peer agent. > > Removing SRTP is another concern because it's pretty widely used now, it's > required in WebRTC and decryption in the middle was something I was hoping > we would go the other direction on and find ways to route encrypted packets > without needing to decode them. > One reason we are focusing on client-to-server vs peer-to-peer is that it avoids the interop issues associated with p2p (i.e., the difference between connecting to the server that you control vs various peers that you don't control). Also, WebRTC already works well for the peer-to-peer case. I also think that whatever we come up with to replace SRTP will probably be able to gateway to SRTP easily for systems that expect SRTP. > > I think if you want to replace SIP trunking more considerations have to be > made for the mass translation of TDM/SIP/SS7 and how that works with > routing and clustering. I think some of that is how we got into that boat > with SIP because it was only later that this was tried and then workarounds > abounded for years. > > On Mon, Mar 23, 2020 at 12:09 PM Justin Uberti 40google.com@dmarc.ietf.org> wrote: > >> In addition to Eric's comments, I think the biggest question regarding >> goals and scope is whether we focus on both client-to-server and >> server-to-server. >> >> If we are taking a fresh look at how all of IP calling works, we could >> find ourselves looking at: >> a) a replacement for SIP "RPCs" (i.e, how are commands reliably >> exchanged) >> b) a replacement for SIP operations and routing (i.e., the specific >> commands and routing mechanisms) >> c) a replacement for offer-answer (i.e., how do both sides agree on media >> formats) >> d) a replacement for SDP (i.e., the details of how media formats are >> described) >> e) a replacement for SRTP (i.e., how media is transmitted from point A to >> B) >> f) a replacement for RTP packetization (i.e., how media is encapsulated >> when transmitted) >> >> I think that server-to-server, essentially a NNI, requires us to consider >> all of these items, and that may ultimately make sense. However, if we >> focus initially on client-to-server, we can get by by only focusing on e) >> and f), as a-d) are under application control >> >> This could still provide a lot of value, since moving to a world where >> even private RTC services can be built atop HTTP would still be quite an >> accomplishment. (Compared to the current state of the world, where people >> deploying cloud RTC services need to source and deploy their own >> ICE/DTLS/SCTP/SRTP stacks and all the load >> balancing/authentication/failover tech that Jonathan mentions). It would >> also be complementary to WebRTC, which works pretty well for p2p >> applications, but struggles in c2s environments for the aforementioned >> reasons. >> >> >> On Mon, Mar 23, 2020 at 7:21 AM Jonathan Rosenberg >> wrote: >> >>> With our BoF coming up this Thursday, I thought the time is right to >>> restart discussions with a focus in particular on SCOPE of the effort. >>> >>> For me its defined entirely by the GOAL. The goal is: >>> >>> It is possible to implement a ript server in public cloud, such that it >>> is nothing more than a web application as far as public cloud is concerned, >>> and therefore works with web-centric features such as Kubernetes, global >>> http load balancers, and service meshes - to name a few. The server >>> implements everything needed to make and receive voice and video calls. >>> >>> I do think the scope needs to be inclusive of server to server peering, >>> not just client to server. The client-to-server stuff defines the core, but >>> for me I'm really interested in building an alternative to sip trunking and >>> that requires solving for additional things (inbound load balancing, >>> inbound authentication, number routing). I think those can easily be in a >>> separate draft but I think they should be in scope. >>> >>> Thx, >>> Jonathan R. >>> >>> -- >>> Jonathan Rosenberg >>> CTO and Head of AI, Five9 >>> >>> >>> ________________________________ >>> >>> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain >>> confidential information of Five9 and/or its affiliated entities. Access by >>> the intended recipient only is authorized. Any liability arising from any >>> party acting, or refraining from acting, on any information contained in >>> this e-mail is hereby excluded. If you are not the intended recipient, >>> please notify the sender immediately, destroy the original transmission and >>> its attachments and do not disclose the contents to any other person, use >>> it for any purpose, or store or copy the information in any medium. >>> Copyright in this e-mail and any attachments belongs to Five9 and/or its >>> affiliated entities... >>> >>> -- >>> V3 mailing list >>> V3@ietf.org >>> https://www.ietf.org/mailman/listinfo/v3 >>> >> -- >> V3 mailing list >> V3@ietf.org >> https://www.ietf.org/mailman/listinfo/v3 >> > > > -- > > > Anthony Minessale | Founder and CEO > > SignalWire: *228 Hamilton Ave 3rd Floor, Palo Alto, CA 94303 > * > > *https://youtu.be/WKjZkzgK4pc * > > https://youtu.be/MwqpSl7luSM > > https://youtu.be/l82JtCECkog > > Email: anthm@signalwire.com > > Phone: 262-309-8501 <(262)%20309-8501> > > Website: https://www.signalwire.com > > > > > --000000000000246d5005a18d5c42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Mar 23, 2020 at 3:24 PM Anthony Minessale <= ;anthm@signalwire.com> wrote= :
Also more consideration for live translation to sip/rt= p/webrtc and back-to-back scenarios.

= If calls are being loaded balanced to many servers you still probably will = want a way to keep track of what calls are on what server in a way that goe= s out of scope of HTTP so the application doing the clustering will bear a = pretty big burden of solving that problem from behind the cluster.

I read the memo about replacing SIP and was s= lightly disturbed that RFC2833 (4733/4734) is the one thing salvaged ;)
That would be the first to go IMHO, its the leading cause of interop= issues in all of telephony and very rarely implemented to its full potenti= al not to mention there are some timestamp translation issues I pointed out= on the github discussion so that is it's own can of worms.
<= br>
Also, the description seems to be evolving more towards consi= derations about making calls behave like a web app which is fine because th= at's the GOAL but there is little consideration of actual trunking so f= ar.=C2=A0 SIP trunking is just a made-up marketing term to mirror original = TDM trunking which was actual trunking (bundling many calls into one stream= to reduce overhead) In reality SIP trunking is often just (a lot of SIP ca= lls) We have our SIP setup so you can send many calls to many different pho= ne numbers over a single registration and that causes introp issues because= most people don't comprehend this lol.
= =C2=A0
So it seems like there could be some improvements that = could clean up issues with WebRTC and how web-app type environments can bus= t through nat etc.
WebRTC is still compatible with SIP in the sen= se that you can carry a WebRTC SDP over sip and set up calls but most of th= e time its SIP over WebSockets (though FS and Kamailio can translate and ne= gotiate WebRTC sessions to other SIP transports)

From a server perspective with density being a major concern, removing a= ll the need for dialogs and route headers is a good thing. What I also thin= k is critical to preserve is the server's ability to limit the media fo= rmats etc sent by the sender.=C2=A0 Killing Offer/Answer is ok but the repl= acement should at least preserve the notions that a client can offer what i= t can do, the server can narrow that scope with its own requirements and th= e client must work within those shared formats.=C2=A0 The server is the one= who has to create thousands of connections etc and must not be treated as = a simple peer-to-peer agent.

Removing SRTP is anot= her concern because it's pretty widely used now, it's required in W= ebRTC and decryption in the middle was something I was hoping we would go t= he other direction on and find ways to route encrypted packets without need= ing to decode them.

One reason = we are focusing on client-to-server vs peer-to-peer is that it avoids the i= nterop issues associated with p2p (i.e., the difference between connecting = to the server that you control vs various peers that you don't control)= . Also, WebRTC already works well for the peer-to-peer case.=C2=A0

I also think that whatever we come up with to replace SRTP= will probably be able to gateway to SRTP easily for systems that expect SR= TP.

I think if you want to replace SIP trunking more consi= derations have to be made for the mass translation of TDM/SIP/SS7 and how t= hat works with routing and clustering.=C2=A0 I think some of that is how we= got into that boat with SIP because it was only later that this was tried = and then workarounds abounded for years.

On Mon, Mar 23, 2020 at 12:09= PM Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> 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">
In additi= on to Eric's comments, I think the biggest question regarding goals and= scope is whether we focus on both client-to-server and server-to-server.= =C2=A0

If we are taking a fresh look at how all of IP ca= lling works, we could find ourselves looking at:
=
a) a replacement for=C2=A0SIP=C2=A0"RPCs"= (i.e, how are commands reliably exchanged)
b) a replacement for = SIP operations and routing (i.e., the specific commands and routing mechani= sms)
c) a replacement for offer-answer (i.e., how do both sides a= gree on media formats)
d) a replacement for=C2=A0SDP (i= .e., the details of how media formats are described)
e= ) a replacement for SRTP (i.e., how media is transmitted from point A to B)=
f) a replacement for RTP packetization (i.e., how media is encap= sulated when transmitted)

I think that server-to-s= erver, essentially a NNI, requires us to consider all of these items, and t= hat may ultimately make sense. However, if we focus initially on client-to-= server, we can get by by only focusing on e) and f), as a-d) are under appl= ication control

This could still provide a lot of = value, since moving to a world where even private RTC services can be built= atop HTTP would still be quite an accomplishment. (Compared to the current= state of the world, where people deploying cloud RTC services need to sour= ce and deploy their own ICE/DTLS/SCTP/SRTP stacks and all the load balancin= g/authentication/failover tech that Jonathan mentions). It would also be co= mplementary to WebRTC, which works pretty well for p2p applications, but st= ruggles in c2s environments for the aforementioned reasons.


On Mon, Mar 23, 2020 at 7:21 AM Jonathan Rosenberg <jdrosen@five9.com> w= rote:
With our B= oF coming up this Thursday, I thought the time is right to restart discussi= ons with a focus in particular on SCOPE of the effort.

For me its defined entirely by the GOAL. The goal is:

It is possible to implement a ript server in public cloud, such that it is = nothing more than a web application as far as public cloud is concerned, an= d therefore works with web-centric features such as Kubernetes, global http= load balancers, and service meshes - to name a few. The server implements = everything needed to make and receive voice and video calls.

I do think the scope needs to be inclusive of server to server peering, not= just client to server. The client-to-server stuff defines the core, but fo= r me I'm really interested in building an alternative to sip trunking a= nd that requires solving for additional things (inbound load balancing, inb= ound authentication, number routing). I think those can easily be in a sepa= rate draft but I think they should be in scope.

Thx,
Jonathan R.

--
Jonathan Rosenberg
CTO and Head of AI, Five9


________________________________

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= ...

--
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3
--
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3


--
=


<= p dir=3D"ltr" style=3D"line-height:1.656;margin-top:0pt;margin-bottom:0pt;m= argin-left:5pt">Anthony Minessale =C2=A0| Founder and CEO

<= span style=3D"font-size:9pt;font-family:Arial;color:rgb(0,0,0);background-c= olor:transparent;vertical-align:baseline;white-space:pre-wrap">SignalWire: = <= a href=3D"https://maps.google.com/?q=3D228+Hamilton+Ave+3rd+Floor,+Palo+Alt= o,+CA+94303&entry=3Dgmail&source=3Dg" style=3D"color:rgb(17,85,204)= " target=3D"_blank">228 Hamilton Ave 3rd Floor, Palo Alto, CA 94303=

https://youtu.be/WKjZkzgK4pc=

https://youtu.be/MwqpSl7luSM

https://youtu.be/l82= JtCECkog

Email: anthm@= signalwire.com

Phone: 262-309-8501

= Website: https://www.signalwire.com

=C2=A0


<= /div>
--000000000000246d5005a18d5c42-- --000000000000246d5005a18d5c43 Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_jm25x25z1_165d8b71f782610b iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAFHElEQVRYCcVXXWgcVRT+ZnZ2d2Z3 093NJtmkmmyrTZOAWGORgFURC76JloIvgiJYCooYfJEqIsW/12pRiFrUJ0EsKvomFvEPqrSNIjQx at2kND/N3ya7O7szszPy3WQmk226s1qhBy737uw95zv33O+ce6/kOI6DJmRmQcfoH0uYmCpgcraI ueUKarU11VBIRnsqilw2gd7uJG7blUZnRmvCKiAFOTCWL+DkN3/j9Pl5zC3qwmgyEUGLFoYkr2HY NlDUTRRKBuAAHa0ahgbacPDeHejPJRs6clUHDMvGWyfP4/Pvp1DSTXSkNcSiIdpvKBKAcrWGuSUd cS2MB+/qxlMHBxBR1r2t097SgfxMES++dw6//rmE7o4YtKgC2w6C3mxZliXoVQtTc2XcenMaLz8x iFxnYvMkbLEFY5MFDL9xGoWiie5sHI7tBK76CqvrHxgNSZYwNVtCMhHGsWeG0N+zeUs2ReDi5RIe f+0HVA0LXZkYav9y1VdzJCRLuLRQFpF8/8g+3NAe96Z6G2NaDp4fOYti2WwaXJIAcoUEZCvpFphT /O4XLmR7JobVkokjI2dBLFc8B979Yhy/TCyKsAetnABsM4s6apYtCEqStqWikCWAWVEvtMktJQax XBFbcGG6iMde/Q7JWBhqpAmmSxJmFsq4b7ALj9x/E27MroWUpBs+/jPml3XE1bCL4fUMTMWooVA2 8eELd2NnVwIiAh9/fQFl3YKmKk0R7vJyBYO9rTh6aBC7c0nEVEW0TFIF99taL1Ae8vqAgScGsYhJ UZZWDfz42xyyrWpTqUYjlaqFA/fkPPuWZWN0YhFLRQOmaSMaDnn/1Q+YzsQiJrGVM+MLmF7QkeuM CwLVK9T/ZuUmwLZExPvrk1N5HP1gFJlUFNm0ihjrRoMKz4jlZ0ogtjyWXxbECYo9SUebZDpLLntX fr9YgGXbojwDEgIrhwOBSWyFVY+1fSMxXLObezKbDG9PaSIDImEvgdCajKInGxehZRmu1WxI9bno M0csYhJbevSVb52ibqEudX3T14aliom2lIZjT98BNaKIbAmF1rQM04Zp2ShVLDx7/CcsrFQRV5Ur bPg/0ImEpkDhkcqVNdgyoUdmk+Fker0wGmxqOISlFUPMq59T/5uYxG7spk+LxCPDT52ZFtu1Z1ca bevOjE8WRL1nYSL5tAZZ4DMphgrDaBukTmMhsyuGhZdOjOLSfAnvPLcP+/d2CaWPvvoLJ76cwO6e bchsU8FMCeSUAxBb5k2G9T9IuDISqz2lirOCFdMVpuT2thhSiaiIQBA49YjZkVIh57ItKBSNwAi4 YO454P5mz+ht9d0/xz/mfGLyfiAP7EhBnLpBe+C3cK1jHlgO0J9LQd7bl0FXRkO5slFYrtV+kD6x iElsOd0SwZ23dGB2sQJeo5oR8sHPASUkN3WO0DYxiEVMYoty9vD+nYhpCvRKcEGikZAsY6Vkiqhx NVWjBjoRJFweMYhFTIp3JXv70zGMfDaOvlwycDXiQIqEPNCqWROVUG5QfgnG1Y/nCzj8UB+ePNAv HPDcPvRAH/b0toqCworXSNwI8OrN1kwEaJOXU2IQyxXPgbAi4fXDt6MlHhYXyEZOuBxIaGGwBXGA tngppW1iEMsVzwF+4G31zeEhcZBMzpZEyDamuirN99Rl2GmLhxNt+2/EtORxwG/2uj5MXEeu69PM dYJ9M49TxwZW+TgtGkL1f3mc+p3guPHzXBIHS89/eJ7/A2tpgiJjIcQ7AAAAAElFTkSuQmCC --000000000000246d5005a18d5c43 Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_jm25y73l3_165d8b7eee16c0ac iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAFJElEQVRYCcVXS2gdVRj+zpmZO3fu I++Yh6lJSaO1wXbRnS6EKq5EQREEwY2IC5e660Lc60oU3epGKAruRIrUgCCCikpt+rAmNeYmaR5t 7mPunTtnRr4zmfvK3NuEBvrD3BnmnvN/3/8+I8IwDHEA2aoGuF70sVxWWHcD7NQCqL2dhgAGbIlx R2I6a2Aub2I4LQ+gFRD3IrBUUvi+UMNfd3xseQEEgKwp9MVnSgDA9UOU/BDkNJySODVg4tyEjZmc sbcq+daVgB8AF5Yq+GG9DlcFGEpJpA2hAZJVRW9JqqpCbHsBHEPi6TELr8xkYHZxSCKBgqvw2dUK bhR9PJSOgIMDBapJTYqIyEY1wIm8ibcey2DC2e+NfQSWSwofXi6h7IcYcyQOC9ykED2RCHOGYXtn PofpjpC0OYZsP7hcQjU4GnBSoAE0hDqp+3aVGdOUBgE/BD5ZLGvLR+z7t7wJEZGgTnr148UyiBVL g8A3t1xc3/V1KR3G7XGsaRmvrVqgAViaLFNeTEzqZJkSg1ixaAKrFYXvVmttMY833fGieidQp/Ad ARnfc+MpvHAsjSdHU/CDECsVpUvTMYQuU+6Nw0EsYlJM/lws1PTi4RbX0005U+DMYAo/bdZRD4CM KRpJST5btRCzORNvPprBoN1wJn7ZrOPb1Sqen0rjxw0Pf+746E9FFrCUN6uBxnx9NgNZ9EL8sV1H KzhJVfxQA742m8GrMw7ueiE2a1Ejoqp6GIKYb8y1g3Pv2REL50/ncarfhAjR1gPoBWIRk9jmlbt1 bQnj05Ib2tLYpqfGUhhICVxYcnGzpHRDYmyfGOzdcl0FSIk2vSRIL6y5AYhtLpUDCLF/kW1At162 WMcUmB+0cLLfwqW1Gn7bruvWXI3CSJ37hBOGhBm+8XS7cTSUmMQ211ylk6hTg20IPXAuFWp47uE0 DAl9PTNpgxeTiOTo0qQEZYiuFX3kurRvJi6xTU41JlenMAeOZQ1teYAQhi6m5qrJzP622vwX8BRg CQFDtga2uYKYxJaMZRzr5t+AJQF2RnYxK8nE1sUJz7erCizhbnuJ2Q1bq7Ol0FONQ+nfsmqUXwJW 4qsbRYWSH4ANqZdILmjvztFyOi5nRZ1rpaSw6yWt6q761606Mt1m8N4ZgtiSJxkmU5LQTfUQsAyh TzxJa5LeEXxx10ef1d185hiblxx3DH2SSVJEhmkD+OJmBQtrHnhO8Jj2PYTGfPlPBRlDdKRt+yYO JmLL49lo8nVyZd65KtQdccMN8OnVMhYKXs9cYFJ9dKWsGxtbbzeqxGKfmMlKmI/3Wxixo4Rj7cdC S1iGZ4csDNkSo46BCSepXqId/5UVPv+7gmtFpdf1chSPbMO2ALHNfErg9JCFi6s1TGWNhoXsVIwT U+9En5nYKwi9Ulb4edPDwrqn5z1J9gKPJ+izkzaIrY9k7Grv/17UHTG1V/O8kemOFyJvCkxlDExk JPIWYyt03hQqSo9dDirOCrbsXuAkzBxi/N87kwebWeNM+NWyi6+Xq/rM1qqEQWGR0BvMiThIjC+H CpONTatbvOOQ8k6jeOZ8aTqNl6cd/Zc+D/DpxUccPbdvlVXbqYiKmRq0nFeSHBScE3Cuz9RYsZ5G VnEcvH0yq8PAub8XiXjdfd2pizo5gIjROnoaBIgwmpZ4dz6HtBT6KH0UJKiDx3LqpG5itEojB1pf PtAPk5jIA/00i0nwfpCPUyYhS4sXn4/k47SVBJ/v9XnOwcKzw2E/z/8HeJXK68Y+LqEAAAAASUVO RK5CYII= --000000000000246d5005a18d5c43-- From nobody Mon Mar 23 16:38:43 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62D63A0F1A for ; Mon, 23 Mar 2020 16:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=signalwire.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 hhuB4MvtCPwT for ; Mon, 23 Mar 2020 16:38:37 -0700 (PDT) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 7F92A3A0F1B for ; Mon, 23 Mar 2020 16:38:37 -0700 (PDT) Received: by mail-vk1-xa33.google.com with SMTP id r129so4334825vkr.6 for ; Mon, 23 Mar 2020 16:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=signalwire.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iin3A7MFlKfYNqc4xy134XpHrSPZKTylDhomEAEdbIo=; b=cc9RAAn7hhsLLz44TCmx0/Ixt3IR3YJUd5uCD0aBb6S8f4H/biitAcnH3vxNfsv/qb fReee4lKZS/+jlxsBCjygi76nQWmOJrX5/DN1uiYQEqbTEF8CS8ss8OuwC1b1GrCMa4s SLoIi1NmJbx9suSLK34H2zuzZzCCIhrF3YSbI= 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=iin3A7MFlKfYNqc4xy134XpHrSPZKTylDhomEAEdbIo=; b=kTYXKVZgDnrPmtY+bdg+xlSVUjWMvvhABvNZUjIO8TMnQiithI0l82cb4qq28f4db2 usYcC+YnVCDV615GUFi0R6C7WX5H5PF5Ah60fz3ILDNzW+EOvwWyshDEz8yddhN8MZqp kRoeLO8amQOrEssupHzLCAymO2nQWUPtrotWi05FKAmbbR+wb/G5mTWHT8lTTsdk9vzZ 98Rmkc+NZjsRebjjat1PuXFIsxhMBy2PaVj8REbXH/tYJjlKqjHQcbAGeyLjj1C/uV4O 5dZA1s7b49+/6GtXcYV5AKBTEWNo7bIcc9pagx2vxhtQxAF5ZzzB6GY4t26qia1vd4ce zZyA== X-Gm-Message-State: ANhLgQ2E/T6c+W7xYtB5IM7dV+BduB0GlIKOikrkgCr+vLzbFipafX28 tpfsfQPqWbWD0ITqZNCLNXAmDIomxhE9t1L3teAsFtUW X-Google-Smtp-Source: ADFU+vv925crYNSH4oCUIhavuvnWjNPZCMETzHQHmI32GERDhRd2IS3qDdy8+HroZts7RRB5mlWCDRQ7ytPNXFo4Q+g= X-Received: by 2002:a1f:2c4b:: with SMTP id s72mr15275331vks.93.1585006715999; Mon, 23 Mar 2020 16:38:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Anthony Minessale Date: Mon, 23 Mar 2020 18:38:24 -0500 Message-ID: To: Justin Uberti Cc: Jonathan Rosenberg , "v3@ietf.org" Content-Type: multipart/related; boundary="00000000000046c2ac05a18e2204" Archived-At: Subject: Re: [V3] Thoughts on scope for ript X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 23:38:41 -0000 --00000000000046c2ac05a18e2204 Content-Type: multipart/alternative; boundary="00000000000046c2ab05a18e2203" --00000000000046c2ab05a18e2203 Content-Type: text/plain; charset="UTF-8" On Mon, Mar 23, 2020 at 5:43 PM Justin Uberti wrote: > > On Mon, Mar 23, 2020 at 3:24 PM Anthony Minessale > wrote: > >> Also more consideration for live translation to sip/rtp/webrtc and >> back-to-back scenarios. >> >> If calls are being loaded balanced to many servers you still probably >> will want a way to keep track of what calls are on what server in a way >> that goes out of scope of HTTP so the application doing the clustering will >> bear a pretty big burden of solving that problem from behind the cluster. >> >> I read the memo about replacing SIP and was slightly disturbed that >> RFC2833 (4733/4734) is the one thing salvaged ;) >> That would be the first to go IMHO, its the leading cause of interop >> issues in all of telephony and very rarely implemented to its full >> potential not to mention there are some timestamp translation issues I >> pointed out on the github discussion so that is it's own can of worms. >> >> Also, the description seems to be evolving more towards considerations >> about making calls behave like a web app which is fine because that's the >> GOAL but there is little consideration of actual trunking so far. SIP >> trunking is just a made-up marketing term to mirror original TDM trunking >> which was actual trunking (bundling many calls into one stream to reduce >> overhead) In reality SIP trunking is often just (a lot of SIP calls) We >> have our SIP setup so you can send many calls to many different phone >> numbers over a single registration and that causes introp issues because >> most people don't comprehend this lol. >> > > >> So it seems like there could be some improvements that could clean up >> issues with WebRTC and how web-app type environments can bust through nat >> etc. >> WebRTC is still compatible with SIP in the sense that you can carry a >> WebRTC SDP over sip and set up calls but most of the time its SIP over >> WebSockets (though FS and Kamailio can translate and negotiate WebRTC >> sessions to other SIP transports) >> >> From a server perspective with density being a major concern, removing >> all the need for dialogs and route headers is a good thing. What I also >> think is critical to preserve is the server's ability to limit the media >> formats etc sent by the sender. Killing Offer/Answer is ok but the >> replacement should at least preserve the notions that a client can offer >> what it can do, the server can narrow that scope with its own requirements >> and the client must work within those shared formats. The server is the >> one who has to create thousands of connections etc and must not be treated >> as a simple peer-to-peer agent. >> >> Removing SRTP is another concern because it's pretty widely used now, >> it's required in WebRTC and decryption in the middle was something I was >> hoping we would go the other direction on and find ways to route encrypted >> packets without needing to decode them. >> > > One reason we are focusing on client-to-server vs peer-to-peer is that it > avoids the interop issues associated with p2p (i.e., the difference between > connecting to the server that you control vs various peers that you don't > control). Also, WebRTC already works well for the peer-to-peer case. > As a server, I appreciate that because it makes scaling much easier to have the power to dictate things. > > I also think that whatever we come up with to replace SRTP will probably > be able to gateway to SRTP easily for systems that expect SRTP. > >> I think if you want to replace SIP trunking more considerations have to >> be made for the mass translation of TDM/SIP/SS7 and how that works with >> routing and clustering. I think some of that is how we got into that boat >> with SIP because it was only later that this was tried and then workarounds >> abounded for years. >> >> On Mon, Mar 23, 2020 at 12:09 PM Justin Uberti > 40google.com@dmarc.ietf.org> wrote: >> >>> In addition to Eric's comments, I think the biggest question regarding >>> goals and scope is whether we focus on both client-to-server and >>> server-to-server. >>> >>> If we are taking a fresh look at how all of IP calling works, we could >>> find ourselves looking at: >>> a) a replacement for SIP "RPCs" (i.e, how are commands reliably >>> exchanged) >>> b) a replacement for SIP operations and routing (i.e., the specific >>> commands and routing mechanisms) >>> c) a replacement for offer-answer (i.e., how do both sides agree on >>> media formats) >>> d) a replacement for SDP (i.e., the details of how media formats are >>> described) >>> e) a replacement for SRTP (i.e., how media is transmitted from point A >>> to B) >>> f) a replacement for RTP packetization (i.e., how media is encapsulated >>> when transmitted) >>> >>> I think that server-to-server, essentially a NNI, requires us to >>> consider all of these items, and that may ultimately make sense. However, >>> if we focus initially on client-to-server, we can get by by only focusing >>> on e) and f), as a-d) are under application control >>> >>> This could still provide a lot of value, since moving to a world where >>> even private RTC services can be built atop HTTP would still be quite an >>> accomplishment. (Compared to the current state of the world, where people >>> deploying cloud RTC services need to source and deploy their own >>> ICE/DTLS/SCTP/SRTP stacks and all the load >>> balancing/authentication/failover tech that Jonathan mentions). It would >>> also be complementary to WebRTC, which works pretty well for p2p >>> applications, but struggles in c2s environments for the aforementioned >>> reasons. >>> >>> >>> On Mon, Mar 23, 2020 at 7:21 AM Jonathan Rosenberg >>> wrote: >>> >>>> With our BoF coming up this Thursday, I thought the time is right to >>>> restart discussions with a focus in particular on SCOPE of the effort. >>>> >>>> For me its defined entirely by the GOAL. The goal is: >>>> >>>> It is possible to implement a ript server in public cloud, such that it >>>> is nothing more than a web application as far as public cloud is concerned, >>>> and therefore works with web-centric features such as Kubernetes, global >>>> http load balancers, and service meshes - to name a few. The server >>>> implements everything needed to make and receive voice and video calls. >>>> >>>> I do think the scope needs to be inclusive of server to server peering, >>>> not just client to server. The client-to-server stuff defines the core, but >>>> for me I'm really interested in building an alternative to sip trunking and >>>> that requires solving for additional things (inbound load balancing, >>>> inbound authentication, number routing). I think those can easily be in a >>>> separate draft but I think they should be in scope. >>>> >>>> Thx, >>>> Jonathan R. >>>> >>>> -- >>>> Jonathan Rosenberg >>>> CTO and Head of AI, Five9 >>>> >>>> >>>> ________________________________ >>>> >>>> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain >>>> confidential information of Five9 and/or its affiliated entities. Access by >>>> the intended recipient only is authorized. Any liability arising from any >>>> party acting, or refraining from acting, on any information contained in >>>> this e-mail is hereby excluded. If you are not the intended recipient, >>>> please notify the sender immediately, destroy the original transmission and >>>> its attachments and do not disclose the contents to any other person, use >>>> it for any purpose, or store or copy the information in any medium. >>>> Copyright in this e-mail and any attachments belongs to Five9 and/or its >>>> affiliated entities... >>>> >>>> -- >>>> V3 mailing list >>>> V3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v3 >>>> >>> -- >>> V3 mailing list >>> V3@ietf.org >>> https://www.ietf.org/mailman/listinfo/v3 >>> >> >> >> -- >> >> >> Anthony Minessale | Founder and CEO >> >> SignalWire: *228 Hamilton Ave 3rd Floor, Palo Alto, CA 94303 >> * >> >> *https://youtu.be/WKjZkzgK4pc * >> >> https://youtu.be/MwqpSl7luSM >> >> https://youtu.be/l82JtCECkog >> >> >> Email: anthm@signalwire.com >> >> Phone: 262-309-8501 <(262)%20309-8501> >> >> Website: https://www.signalwire.com >> >> >> >> >> -- Anthony Minessale | Founder and CEO SignalWire: *228 Hamilton Ave 3rd Floor, Palo Alto, CA 94303 * *https://youtu.be/WKjZkzgK4pc * https://youtu.be/MwqpSl7luSM https://youtu.be/l82JtCECkog Email: anthm@signalwire.com Phone: 262-309-8501 Website: https://www.signalwire.com --00000000000046c2ab05a18e2203 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Mar 23, 2020 at 5:43 PM Justi= n Uberti <juberti@google.com&g= t; wrote:

On Mon, Mar 23, 2020 at 3:24 PM Anthony Minessale <anthm@signalwire.com> wrote:
Also more consideration for live translati= on to sip/rtp/webrtc and back-to-back scenarios.
If calls are being loaded balanced to many servers you still pr= obably will want a way to keep track of what calls are on what server in a = way that goes out of scope of HTTP so the application doing the clustering = will bear a pretty big burden of solving that problem from behind the clust= er.

I read the memo about replacing S= IP and was slightly disturbed that RFC2833 (4733/4734) is the one thing sal= vaged ;)
That would be the first to go IMHO, its the leading caus= e of interop issues in all of telephony and very rarely implemented to its = full potential not to mention there are some timestamp translation issues I= pointed out on the github discussion so that is it's own can of worms.=

Also, the description seems to be evolving more t= owards considerations about making calls behave like a web app which is fin= e because that's the GOAL but there is little consideration of actual t= runking so far.=C2=A0 SIP trunking is just a made-up marketing term to mirr= or original TDM trunking which was actual trunking (bundling many calls int= o one stream to reduce overhead) In reality SIP trunking is often just (a l= ot of SIP calls) We have our SIP setup so you can send many calls to many d= ifferent phone numbers over a single registration and that causes introp is= sues because most people don't comprehend this lol.
So it seems like there could be some improvem= ents that could clean up issues with WebRTC and how web-app type environmen= ts can bust through nat etc.
WebRTC is still compatible with SIP = in the sense that you can carry a WebRTC SDP over sip and set up calls but = most of the time its SIP over WebSockets (though FS and Kamailio can transl= ate and negotiate WebRTC sessions to other SIP transports)
From a server perspective with density being a major concern, = removing all the need for dialogs and route headers is a good thing. What I= also think is critical to preserve is the server's ability to limit th= e media formats etc sent by the sender.=C2=A0 Killing Offer/Answer is ok bu= t the replacement should at least preserve the notions that a client can of= fer what it can do, the server can narrow that scope with its own requireme= nts and the client must work within those shared formats.=C2=A0 The server = is the one who has to create thousands of connections etc and must not be t= reated as a simple peer-to-peer agent.

Removing SR= TP is another concern because it's pretty widely used now, it's req= uired in WebRTC and decryption in the middle was something I was hoping we = would go the other direction on and find ways to route encrypted packets wi= thout needing to decode them.


<= /blockquote>

I think if you want to replace S= IP trunking more considerations have to be made for the mass translation of= TDM/SIP/SS7 and how that works with routing and clustering.=C2=A0 I think = some of that is how we got into that boat with SIP because it was only late= r that this was tried and then workarounds abounded for years.
<= br>
On Mon,= Mar 23, 2020 at 12:09 PM Justin Uberti <juberti=3D40google.com@dmarc.ietf.org= > wrote:
In addition to Eric's comments, I think the biggest questi= on regarding goals and scope is whether we focus on both client-to-server a= nd server-to-server.=C2=A0

If we are taking a fresh look= at how all of IP calling works, we could find ourselves looking at:
<= div>
a) a replacement for=C2=A0SIP= =C2=A0"RPCs" (i.e, how are commands reliably exchanged)
b) a replacement for SIP operations and routing (i.e., the specific comman= ds and routing mechanisms)
c) a replacement for offer-answer (i.e= ., how do both sides agree on media formats)
d) a replacement= for=C2=A0SDP (i.e., the details of how media formats are described)<= /span>
e) a replacement for SRTP (i.e., how media is transmit= ted from point A to B)
f) a replacement for RTP packetization (i.= e., how media is encapsulated when transmitted)

I = think that server-to-server, essentially a NNI, requires us to consider all= of these items, and that may ultimately make sense. However, if we focus i= nitially on client-to-server, we can get by by only focusing on e) and f), = as a-d) are under application control

This could s= till provide a lot of value, since moving to a world where even private RTC= services can be built atop HTTP would still be quite an accomplishment. (C= ompared to the current state of the world, where people deploying cloud RTC= services need to source and deploy their own ICE/DTLS/SCTP/SRTP stacks and= all the load balancing/authentication/failover tech that Jonathan mentions= ). It would also be complementary to WebRTC, which works pretty well for p2= p applications, but struggles in c2s environments for the aforementioned re= asons.


On Mon, Mar 23, 2020 at 7:21 AM Jonathan R= osenberg <jdrosen= @five9.com> wrote:
With our BoF coming up this Thursday, I thought the time is righ= t to restart discussions with a focus in particular on SCOPE of the effort.=

For me its defined entirely by the GOAL. The goal is:

It is possible to implement a ript server in public cloud, such that it is = nothing more than a web application as far as public cloud is concerned, an= d therefore works with web-centric features such as Kubernetes, global http= load balancers, and service meshes - to name a few. The server implements = everything needed to make and receive voice and video calls.

I do think the scope needs to be inclusive of server to server peering, not= just client to server. The client-to-server stuff defines the core, but fo= r me I'm really interested in building an alternative to sip trunking a= nd that requires solving for additional things (inbound load balancing, inb= ound authentication, number routing). I think those can easily be in a sepa= rate draft but I think they should be in scope.

Thx,
Jonathan R.

--
Jonathan Rosenberg
CTO and Head of AI, Five9


________________________________

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= ...

--
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3
--
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3


--
=


<= p dir=3D"ltr" style=3D"line-height:1.656;margin-top:0pt;margin-bottom:0pt;m= argin-left:5pt">Anthony Minessale =C2=A0| Founder and CEO

<= span style=3D"font-size:9pt;font-family:Arial;color:rgb(0,0,0);background-c= olor:transparent;vertical-align:baseline;white-space:pre-wrap">SignalWire: = <= a href=3D"https://maps.google.com/?q=3D228+Hamilton+Ave+3rd+Floor,+Palo+Alt= o,+CA+94303&entry=3Dgmail&source=3Dg" style=3D"color:rgb(17,85,204)= " target=3D"_blank">228 Hamilton Ave 3rd Floor, Palo Alto, CA 94303=

https://youtu.be/WKjZkzgK4pc=

https://youtu.be/MwqpSl7luSM

https://youtu.be/l82= JtCECkog

Email: anthm@= signalwire.com

Phone: 262-309-8501

= Website: https://www.signalwire.com

=C2=A0


<= /div>


--
--00000000000046c2ab05a18e2203-- --00000000000046c2ac05a18e2204 Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_jm25x25z1_165d8b71f782610b iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAFHElEQVRYCcVXXWgcVRT+ZnZ2d2Z3 093NJtmkmmyrTZOAWGORgFURC76JloIvgiJYCooYfJEqIsW/12pRiFrUJ0EsKvomFvEPqrSNIjQx at2kND/N3ya7O7szszPy3WQmk226s1qhBy737uw95zv33O+ce6/kOI6DJmRmQcfoH0uYmCpgcraI ueUKarU11VBIRnsqilw2gd7uJG7blUZnRmvCKiAFOTCWL+DkN3/j9Pl5zC3qwmgyEUGLFoYkr2HY NlDUTRRKBuAAHa0ahgbacPDeHejPJRs6clUHDMvGWyfP4/Pvp1DSTXSkNcSiIdpvKBKAcrWGuSUd cS2MB+/qxlMHBxBR1r2t097SgfxMES++dw6//rmE7o4YtKgC2w6C3mxZliXoVQtTc2XcenMaLz8x iFxnYvMkbLEFY5MFDL9xGoWiie5sHI7tBK76CqvrHxgNSZYwNVtCMhHGsWeG0N+zeUs2ReDi5RIe f+0HVA0LXZkYav9y1VdzJCRLuLRQFpF8/8g+3NAe96Z6G2NaDp4fOYti2WwaXJIAcoUEZCvpFphT /O4XLmR7JobVkokjI2dBLFc8B979Yhy/TCyKsAetnABsM4s6apYtCEqStqWikCWAWVEvtMktJQax XBFbcGG6iMde/Q7JWBhqpAmmSxJmFsq4b7ALj9x/E27MroWUpBs+/jPml3XE1bCL4fUMTMWooVA2 8eELd2NnVwIiAh9/fQFl3YKmKk0R7vJyBYO9rTh6aBC7c0nEVEW0TFIF99taL1Ae8vqAgScGsYhJ UZZWDfz42xyyrWpTqUYjlaqFA/fkPPuWZWN0YhFLRQOmaSMaDnn/1Q+YzsQiJrGVM+MLmF7QkeuM CwLVK9T/ZuUmwLZExPvrk1N5HP1gFJlUFNm0ihjrRoMKz4jlZ0ogtjyWXxbECYo9SUebZDpLLntX fr9YgGXbojwDEgIrhwOBSWyFVY+1fSMxXLObezKbDG9PaSIDImEvgdCajKInGxehZRmu1WxI9bno M0csYhJbevSVb52ibqEudX3T14aliom2lIZjT98BNaKIbAmF1rQM04Zp2ShVLDx7/CcsrFQRV5Ur bPg/0ImEpkDhkcqVNdgyoUdmk+Fker0wGmxqOISlFUPMq59T/5uYxG7spk+LxCPDT52ZFtu1Z1ca bevOjE8WRL1nYSL5tAZZ4DMphgrDaBukTmMhsyuGhZdOjOLSfAnvPLcP+/d2CaWPvvoLJ76cwO6e bchsU8FMCeSUAxBb5k2G9T9IuDISqz2lirOCFdMVpuT2thhSiaiIQBA49YjZkVIh57ItKBSNwAi4 YO454P5mz+ht9d0/xz/mfGLyfiAP7EhBnLpBe+C3cK1jHlgO0J9LQd7bl0FXRkO5slFYrtV+kD6x iElsOd0SwZ23dGB2sQJeo5oR8sHPASUkN3WO0DYxiEVMYoty9vD+nYhpCvRKcEGikZAsY6Vkiqhx NVWjBjoRJFweMYhFTIp3JXv70zGMfDaOvlwycDXiQIqEPNCqWROVUG5QfgnG1Y/nCzj8UB+ePNAv HPDcPvRAH/b0toqCworXSNwI8OrN1kwEaJOXU2IQyxXPgbAi4fXDt6MlHhYXyEZOuBxIaGGwBXGA tngppW1iEMsVzwF+4G31zeEhcZBMzpZEyDamuirN99Rl2GmLhxNt+2/EtORxwG/2uj5MXEeu69PM dYJ9M49TxwZW+TgtGkL1f3mc+p3guPHzXBIHS89/eJ7/A2tpgiJjIcQ7AAAAAElFTkSuQmCC --00000000000046c2ac05a18e2204 Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_jm25y73l3_165d8b7eee16c0ac iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAFJElEQVRYCcVXS2gdVRj+zpmZO3fu I++Yh6lJSaO1wXbRnS6EKq5EQREEwY2IC5e660Lc60oU3epGKAruRIrUgCCCikpt+rAmNeYmaR5t 7mPunTtnRr4zmfvK3NuEBvrD3BnmnvN/3/8+I8IwDHEA2aoGuF70sVxWWHcD7NQCqL2dhgAGbIlx R2I6a2Aub2I4LQ+gFRD3IrBUUvi+UMNfd3xseQEEgKwp9MVnSgDA9UOU/BDkNJySODVg4tyEjZmc sbcq+daVgB8AF5Yq+GG9DlcFGEpJpA2hAZJVRW9JqqpCbHsBHEPi6TELr8xkYHZxSCKBgqvw2dUK bhR9PJSOgIMDBapJTYqIyEY1wIm8ibcey2DC2e+NfQSWSwofXi6h7IcYcyQOC9ykED2RCHOGYXtn PofpjpC0OYZsP7hcQjU4GnBSoAE0hDqp+3aVGdOUBgE/BD5ZLGvLR+z7t7wJEZGgTnr148UyiBVL g8A3t1xc3/V1KR3G7XGsaRmvrVqgAViaLFNeTEzqZJkSg1ixaAKrFYXvVmttMY833fGieidQp/Ad ARnfc+MpvHAsjSdHU/CDECsVpUvTMYQuU+6Nw0EsYlJM/lws1PTi4RbX0005U+DMYAo/bdZRD4CM KRpJST5btRCzORNvPprBoN1wJn7ZrOPb1Sqen0rjxw0Pf+746E9FFrCUN6uBxnx9NgNZ9EL8sV1H KzhJVfxQA742m8GrMw7ueiE2a1Ejoqp6GIKYb8y1g3Pv2REL50/ncarfhAjR1gPoBWIRk9jmlbt1 bQnj05Ib2tLYpqfGUhhICVxYcnGzpHRDYmyfGOzdcl0FSIk2vSRIL6y5AYhtLpUDCLF/kW1At162 WMcUmB+0cLLfwqW1Gn7bruvWXI3CSJ37hBOGhBm+8XS7cTSUmMQ211ylk6hTg20IPXAuFWp47uE0 DAl9PTNpgxeTiOTo0qQEZYiuFX3kurRvJi6xTU41JlenMAeOZQ1teYAQhi6m5qrJzP622vwX8BRg CQFDtga2uYKYxJaMZRzr5t+AJQF2RnYxK8nE1sUJz7erCizhbnuJ2Q1bq7Ol0FONQ+nfsmqUXwJW 4qsbRYWSH4ANqZdILmjvztFyOi5nRZ1rpaSw6yWt6q761606Mt1m8N4ZgtiSJxkmU5LQTfUQsAyh TzxJa5LeEXxx10ef1d185hiblxx3DH2SSVJEhmkD+OJmBQtrHnhO8Jj2PYTGfPlPBRlDdKRt+yYO JmLL49lo8nVyZd65KtQdccMN8OnVMhYKXs9cYFJ9dKWsGxtbbzeqxGKfmMlKmI/3Wxixo4Rj7cdC S1iGZ4csDNkSo46BCSepXqId/5UVPv+7gmtFpdf1chSPbMO2ALHNfErg9JCFi6s1TGWNhoXsVIwT U+9En5nYKwi9Ulb4edPDwrqn5z1J9gKPJ+izkzaIrY9k7Grv/17UHTG1V/O8kemOFyJvCkxlDExk JPIWYyt03hQqSo9dDirOCrbsXuAkzBxi/N87kwebWeNM+NWyi6+Xq/rM1qqEQWGR0BvMiThIjC+H CpONTatbvOOQ8k6jeOZ8aTqNl6cd/Zc+D/DpxUccPbdvlVXbqYiKmRq0nFeSHBScE3Cuz9RYsZ5G VnEcvH0yq8PAub8XiXjdfd2pizo5gIjROnoaBIgwmpZ4dz6HtBT6KH0UJKiDx3LqpG5itEojB1pf PtAPk5jIA/00i0nwfpCPUyYhS4sXn4/k47SVBJ/v9XnOwcKzw2E/z/8HeJXK68Y+LqEAAAAASUVO RK5CYII= --00000000000046c2ac05a18e2204-- From nobody Tue Mar 24 07:13:19 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1B73A0BD8 for ; Tue, 24 Mar 2020 07:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 N8UXsU8sz605 for ; Tue, 24 Mar 2020 07:12:53 -0700 (PDT) Received: from smtp84.ord1d.emailsrvr.com (smtp84.ord1d.emailsrvr.com [184.106.54.84]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D453A096E for ; Tue, 24 Mar 2020 07:12:53 -0700 (PDT) X-Auth-ID: fluffy@iii.ca Received: by smtp19.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A5189603F3; Tue, 24 Mar 2020 10:12:51 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.53] ([UNAVAILABLE]. [128.107.241.168]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Tue, 24 Mar 2020 10:12:52 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_667CBC2B-630E-4225-B67C-684D853736E4" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Cullen Jennings In-Reply-To: Date: Tue, 24 Mar 2020 08:12:49 -0600 Cc: Jonathan Rosenberg , v3@ietf.org, IETF QUIC WG Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.3445.104.11) X-Classification-ID: 52a457f1-4773-4d2d-a294-5dd0535fecd6-1-1 Archived-At: Subject: [V3] E2E Security and P2P media X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 14:13:15 -0000 --Apple-Mail=_667CBC2B-630E-4225-B67C-684D853736E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 22, 2020, at 3:00 PM, Eric Rescorla wrote: >=20 > LACK OF E2E SECURITY > Your charter specifies e2e security, but AFAICT, this is not > provided by this specification, nor is it obvious how to enhance > it to provide it. Indeed, it seems like there's not any support > for a disjoint media path. You may recall that I made similar > comments at the DISPATCH session in SIN, and I had understood > that it was your intention to accommodate these cases, but > I don't see anything here, which is somewhat disappointing. This was in some version but accidentally got deleted out in editing but = what I think we should do is something along the lines of following: 1.Include End-2-End encryption and authentication of the media packets = in the base design. (and there would also still be Hop-bop provided by = transport layer)=20 2. Design it to work well if you are using MLS keying or something like = it but the keying would be out of scope.=20 That design would well to do things like cover the PERC WG uses cases. = (but i am not advocating a solution like double - just we have one E2E = that is keyed by something like MLS and a separate HbH that is keyed by = TLS)=20 I don=E2=80=99t think we should directly take on P2P media to start with = due to the complexity that an ICE like protocol adds. Most the uses = cases driving this work fine in the same sort of way that HTTP works = without any P2P. Much of the =E2=80=9CP2P=E2=80=9D SIP and WeBRTC = traffic actually goes via a TURN server or other tunnel and RIPT would = support that sort of relay topology as long as we had a E2E crypto.=20 I do think it might be possible that we will be able to use WebRTC set = up a data channel then run RIPT over that data channel.=20 --Apple-Mail=_667CBC2B-630E-4225-B67C-684D853736E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Feb 22, 2020, at 3:00 PM, Eric Rescorla <ekr@rtfm.com> = wrote:

LACK OF E2E SECURITY
Your charter specifies e2e = security, but AFAICT, this is not
provided by this specification, nor is it obvious how to = enhance
it to provide = it. Indeed, it seems like there's not any support
for a disjoint media path. You = may recall that I made similar
comments at the DISPATCH session in SIN, and I had = understood
that it was = your intention to accommodate these cases, but
I don't see anything here, which = is somewhat disappointing.

This was in some version but accidentally got = deleted out in editing but what I think we should do is something along = the lines of following:

1.Include End-2-End encryption and authentication of the = media packets in the base design. (and there would also still be Hop-bop = provided by transport layer) 

2. Design it to work well if you are = using MLS keying or something like it but the keying would be out of = scope. 

That design would well to do things like cover the PERC WG = uses cases. (but i am not advocating a solution like double - just we = have one E2E that is keyed by something like MLS and a separate HbH that = is keyed by TLS) 

I don=E2=80=99t think we should directly take on P2P media to = start with due to the complexity that an ICE like protocol adds. Most = the uses cases driving this work fine in the same sort of way that HTTP = works without any P2P.  Much of the =E2=80=9CP2P=E2=80=9D SIP and = WeBRTC traffic actually goes via a TURN server or other tunnel and RIPT = would support that sort of relay topology as long as we had a E2E = crypto. 

I = do think it might be possible that we will be able to use WebRTC set up = a data channel then run RIPT  over that data = channel. 


= --Apple-Mail=_667CBC2B-630E-4225-B67C-684D853736E4-- From nobody Tue Mar 24 15:36:38 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E14993A0538 for ; Tue, 24 Mar 2020 15:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.363 X-Spam-Level: X-Spam-Status: No, score=-3.363 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-1.463, 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=fivn.onmicrosoft.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 G8v9lgzrQwuG for ; Tue, 24 Mar 2020 15:36:32 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2042.outbound.protection.outlook.com [40.107.93.42]) (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 CDD5F3A0442 for ; Tue, 24 Mar 2020 15:36:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K37oKyv+L2Q5qocY9agJfLDS/IiYL/r+nD9ss/0QyitFWMA1sWTGYl3J/tQu4S5wgFw0j4vdqak9myE1rO1cWZXwc3gG84Erf3lK3DMh+OAdCdmAEfMLV6aScPtfZ9yY3c3KydEe7Ec7eGHYmtJcYRdrov/mOtv1EAaMG8mJRaBFHfosFZ885I+ckTwOIfeTlXDDwfkSg+8/yAYSKKwuEUSJPE4N/9oFEwfLdq20V4sSoMQZRiDE+/Gms2GL58DYxfsCd75inqpXY+Ffd2xFd3c9oETi8mSoLk3+UuUvAVnDCX/h4WtvCiBJVx2CVms/5jP30ba1eLuw2OF2uFiCWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nc7GdwSvMjS8fyRibWxGyeo7m2tJ/Q5DvqdGrk3Sdeg=; b=l5OFvWTeGSZvuBBqFIvfH9vlVovswWsnjPik6Bz36sRdg0/ddFLDBOcz4yec7GzoReEW9FpJjR110tQ45knMmzfzohvGcVYWHPxQBvDo4tCKxqX1dLu+kApZ6S7pMl26UCVG9OEGApLD3nTM03XFfeGtp64X3KzbhFTIm9Iiei9XHyXGmrRn0nRdkhYIZbZ2Gs2lCtK4frD9iynsaFF+vCj6RtlEm/UnpU+KMa1a+YQiGlw+KxhP1/qY0TFklVEFKjYhaIns0Di1eqqdDR2jw/HDSmaGGfl9HgEnEh3O8zEBNg7VMyztNbG7geKK852Dp9gFS2WK60GiCeqW6aPXow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=five9.com; dmarc=pass action=none header.from=five9.com; dkim=pass header.d=five9.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fivn.onmicrosoft.com; s=selector2-fivn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nc7GdwSvMjS8fyRibWxGyeo7m2tJ/Q5DvqdGrk3Sdeg=; b=BduWgxJotvPEJugtgbBiwlenozr42zOXF3Ess0bUIuAGjs9CeELaFlR5e04y8PWPMUMzzfwkh+ERKjeM01HzjuM6e88oeJTwy6vtKMzb6dhPViyCHdD8OUiw7wBl0cA52Yr4dif/80hoftfa0ewiJ7OY8erRIx4HpcGySlLF/Bw= Received: from BYAPR06MB4391.namprd06.prod.outlook.com (2603:10b6:a03:12::26) by BYAPR06MB4693.namprd06.prod.outlook.com (2603:10b6:a03:50::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.19; Tue, 24 Mar 2020 22:36:29 +0000 Received: from BYAPR06MB4391.namprd06.prod.outlook.com ([fe80::21c5:6201:54:13d4]) by BYAPR06MB4391.namprd06.prod.outlook.com ([fe80::21c5:6201:54:13d4%2]) with mapi id 15.20.2835.021; Tue, 24 Mar 2020 22:36:29 +0000 From: Jonathan Rosenberg To: "v3@ietf.org" CC: Eric Rescorla Thread-Topic: ekr's comment #1: load balancing Thread-Index: AdYCKfFdA36BkNSySJKSnPIWXcJ0Eg== Date: Tue, 24 Mar 2020 22:36:29 +0000 Message-ID: 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=jdrosen@five9.com; x-originating-ip: [108.35.46.157] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dac0d65c-5f73-463c-45f3-08d7d043cbc8 x-ms-traffictypediagnostic: BYAPR06MB4693: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03524FBD26 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(376002)(366004)(346002)(136003)(81166006)(316002)(7696005)(6506007)(33656002)(186003)(81156014)(966005)(71200400001)(6916009)(5660300002)(66556008)(2906002)(76116006)(66946007)(66476007)(478600001)(52536014)(8936002)(86362001)(66446008)(8676002)(55016002)(9686003)(26005)(64756008)(4326008)(17413003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR06MB4693; H:BYAPR06MB4391.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; received-spf: None (protection.outlook.com: five9.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: omUbT8Xm6AV+q1oDrIeZiuGpzkGCVEG8UcFeV1vBupRSllmXRRbxFYRzGnhSpUASnHOtv3X4ePQh4De2x+AIZo3fgf9nStr4YJQBfhQu7hvIXRQ0jY23zqqrE47T1xebOufCU2bV+SQDTtt2bVVuLdvnhwtIbhVfBGk/q9EON+nbRJMj7y+Kmw9k19u2ZckgI44+GEvnG1ZntAWKeDhIiUO6PBwWG+1gTLPWr10pG7K78wyKWXV7Unh/Qf0Te27TaMWNIXsURVbHTZOMHFBgceKT3R4AYlYx6RqhLJ06h63Q6Eve5BF20+5m4MZpDa8BECEF/2Gzttn0kmweW7VDMMC5E6SxQiqv1btVX4eh7IkHULtHqZfG39ygoc4L+r9m2amWOCzOydDl022CVThop1zvxIRKOGjJcsgTqpNLeZG8E8Gr9fnMh3sq1R2n07QYF/0SdUR+Bme84osfAm1Bj+ldPZTkcoaWHrpOivXGrANvIeZ25VnJmiGuRI9GogODC5byeaQHGGKzwX885y3vWaJbqOb7twJ0+u02GIulVF2NobU+jZfRpPL3/gCmcy8I x-ms-exchange-antispam-messagedata: GoCXkfmxg5JsTsHTeVPcACll54EjbNQpOjBnzrAz8BRodmXS8GwoVTybNTMvG4Xi447tMd0X1c9hqvJQv6PeNM2IdwIX6/52s0n4KELr2K2ZRNTacCSX8h20Hnh0heTxZsZWrm5Hk/jX+A3atlcU6A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: five9.com X-MS-Exchange-CrossTenant-Network-Message-Id: dac0d65c-5f73-463c-45f3-08d7d043cbc8 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2020 22:36:29.4871 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f6c5114f-7396-4a09-af1e-98ee46f99bdb X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6HpzTlzTpfWDrSf09D+XgZoDI3KSXLOoxn3CdKPmzqkJKLXMlmHcDMKATBc2g3SBmewoRty6a3gaIEj/o0npgg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB4693 Archived-At: Subject: [V3] ekr's comment #1: load balancing X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 22:36:36 -0000 I figured for ease of following I'd take ekr's review and split it up into = a few separate mails. https://mailarchive.ietf.org/arch/msg/v3/V2BuGEZJpEMcAKcYLNHDMtV3i70/ ekr says: ----------- > WEB ARCHITECTURE This document talks multiple times about how it's designed to work with existing HTTP infrastructure and there are a number of features of this design that seem to be dictated by that. However, it seems to me that you are making a number of surprising (and perhaps incorrect) assumptions about architecture and in general this seems misguided. - Transport Connections and HTTP Requests Need Not Fate Share There seems to be an implicit assumption in this design that HTTP LBs have semi-persistent routing, such that if request 1 and request 2 go to different servers this is a "migration" event (S 8.9). This may be the case in some architectures but it's not by any means guaranteed. The LB is free to send every request to a different server, and Web applications need to be designed to accommodate this. (see, for instance: https://www.oreilly.com/library/view/programming-google-app/9781491900246/c= h01.html . section The Runtime Environment). While this might in principle be compatible with RIPT as designed, it seems unlikely to work well if each byway goes to a different server. ------ My assumption is that cloud load balancers can be configured to perform sti= cky routing, *not* that all load balancers will do it by default. In other = words, the assumption is that the ript server is being deployed into a clou= d environment which is under the control (via configuration) of the company= that is deploying the server, and therefore its settings can be tuned to m= ake ript work properly. Sticky routing is broadly supported. It is supporte= d by AWS (https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/e= lb-sticky-sessions.html#enable-sticky-sessions-application), Google (https:= //cloud.google.com/load-balancing/docs/backend-service#session_affinity) , = Azure (https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-d= istribution-mode) . I suspect the others do too but I didn't check. Many we= b apps that were built on-prem and were stateful, but are now being run in = cloud compute environments, have an identical need so I don't expect this f= eature to be removed. You are correct that ript wont work well if each byway aka media packet goe= s to a different server. Though, this may depend on the application. For ap= ps that don't really process the media in a highly stateful way, it might a= ctually work fine. For stateful operations like transcoding it would obviou= sly be bad, yes. That said, I think what is needed here is a better statement on the constra= ints. Instead of making things a hard rule like, "must work with existing c= loud services without change", I think a better statement is perhaps someth= ing like, "aligns with web design principals, protocols, and features of cl= oud services in such a way that it minimizes the set of features which are = unique to real-time". Would that work better? Thx, Jonathan R. -- Jonathan Rosenberg CTO and Head of AI, Five9 ________________________________ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= . From nobody Tue Mar 24 22:11:14 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6365A3A08AF for ; Tue, 24 Mar 2020 22:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lowentropy.net header.b=D8mnMQxS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cYb+LVzv 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 hulzO7u4ETVB for ; Tue, 24 Mar 2020 22:11:10 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB8693A0415 for ; Tue, 24 Mar 2020 22:11:10 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 5A21C628 for ; Wed, 25 Mar 2020 01:11:08 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 25 Mar 2020 01:11:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=ue3E2Tgcbn/eOu1U0zONsOiyDcSAwEAAeyhvIyaAm6U=; b=D8mnMQxS FQsjcBMyVTl8Xwvy80d7mqjmZO0HN8rbbo9sS4MGi3kGDjW7D6sKJNp/DsPPcnsz cHtK2HcIdTmfhrlFu9wnOyGg11pM389S33B1cB4iqh4cKTrjGpR8fX3QsivURLS3 EFF/sjD/ft1mSg2Y9/wMgGorn6MezoGJM6qAvkxNP0zr5WZX1j054En3YViypiTX cLjeXW9wfQ/qNgNJLZWsqSE0cG+B6SByU8d7fdXNjCSBfct9nNurNnDBj09nkpy3 YmIhuf82SiWKZXghwarq/KRq9ES4eea1qwRx8Y5Wj6qfqeSnLPVAAf8sO7CzSQ8G dwBJMw9WU6wQBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=ue3E2Tgcbn/eOu1U0zONsOiyDcSAw EAAeyhvIyaAm6U=; b=cYb+LVzvoShIwzl9CMgze1M1WZVnuG+c6/a/ph1OhecSB Ptgq6FPoK/sEem/tMP9csMZw9MesdxvewaTp/Ac1tezaY8yyOAbMc1aKAGZNlfCR u0Ft3+5vGbAbuJYsiObDgZz1qiLv/q12IMS5uagu5gofUPe4g+g9G2KdooaRjB/J tzjc5b0uPtMr7j/xZ1VZLUadq69GdaSVtHxZA+P28DjoVaJoP61V0Mcxz++QxcYH Ui7DgD33vWbGU6+y7yE3C3HLngdC7IFjM1J0Iou+6+AuP8Hz1k2qCxIL4uJame3Z NUpCtJsJ9+clo7dGqwNZzNPHIxMnGMJvTP/goxSSw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehvddgjeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigv nhhtrhhophihrdhnvghtqeenucffohhmrghinhepfigvsggvgidrtghomhdpihgvthhfrd horhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep mhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 96342E00A6; Wed, 25 Mar 2020 01:11:07 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-Id: Date: Wed, 25 Mar 2020 16:10:27 +1100 From: "Martin Thomson" To: v3@ietf.org Content-Type: text/plain Archived-At: Subject: [V3] RIPT virtual meeting info for IETF 107 X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 05:11:13 -0000 Props to Sean Turner for setting a good example here. Here is the info you will need for the meeting on Wed/Thu: - Webex Link: https://ietf.webex.com/ietf/j.php?MTID=m77168c5c7592f30d7f369b49b47cfcf3 - Make sure your video is OFF - Mute your mic unless you are speaking - Use headsets to avoid echo - Use Webex chat only to join the mic queue: +q adds you to the queue -q removes you from the queue - Add your name and affiliation to the virtual blue sheet in the Etherpad: https://etherpad.ietf.org/p/notes-ietf-107-ript?useMonospaceFont=true - Join the Jabber room: xmpp:ript@jabber.ietf.org?join From nobody Wed Mar 25 00:32:11 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0400A3A0A4D for ; Wed, 25 Mar 2020 00:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, 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 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 8iMjvVdDz20u for ; Wed, 25 Mar 2020 00:32:05 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150078.outbound.protection.outlook.com [40.107.15.78]) (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 82B763A0A56 for ; Wed, 25 Mar 2020 00:31:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AE91Z5t3sRpj8qFf1Jku1w0XTgTlp7Z/pguBOAbVC94Uuj9RN9X3cnwxp7nEDlt34lzDPnRgalCeRVfXXq3YLShxEoyDFwLBz0rArSW5m/eG+Q361LupanbuMtZdbcVwBvnShFms5H63c4yDnBtta9OWQRMlHdqUldIpPIWYnbVfFA/rglIEAgQy2BcydamqLQoYFOGQgY8xxxBriLngp5JJfzAFO3AU4N0BrF3E5GWYu41kahzIonUBhTxPh7wTZSPAw2DugvkfaLEvyvwcEEu6LRJX82rbHwsZdwQFy70ypg9MORLvj3bXETRyTUY35loyV5gG0/BgqHqFJ4ATAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2SzKqoIVhOYmo02QkZAcahixt5aQ41xgZ7YCYmi+WAs=; b=Jc02Cfy5vk7GZIN+YKckaV9l6V1DHQIKn/4gUKdqubKkZuGegliBRO9WJ2lIIvbTg+6azfx3JLa7U/LuZlbZibb2gWv7j0jo0+2bu/sJPx2vW6/s953R/VJPLPkLY3Dn8Kit60WaMwajoVc7fjQzzPvfK5YeUOIFhsJFjdBgrjRWb26SBeM32E+TI3htTHXl1awIdoyZHjbDsd3QZMYdng6qNjbNN6q5REsuu72TxEsv/jixWn2wLDYNBENEzCRQ94EDEU+5/V39KF9PAZ++pdolu3Q4pO2rixMpVwH9J5YXTVz37Ql17vrSJsMiOrXjW8V1nWn/zhGcYUYFox377w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=2SzKqoIVhOYmo02QkZAcahixt5aQ41xgZ7YCYmi+WAs=; b=RbLoNuNgMbv9tiYm9giSZIMeo+LyV6guBeQAH/HVwHwKsoKQ9uXwH5+Yh2rttKNCN+G7YdvfOCX1vjMMMbMM+yoqa4Eb0nm8BnlAOoH1bvQQtASILFFFJ0H/UgOrrnTGR6aKCjr5CbaeILcBjVU0VJ6UabKBadW4d7qiVv2ssCA= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (52.134.82.159) by AM0PR07MB4498.eurprd07.prod.outlook.com (52.135.145.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.18; Wed, 25 Mar 2020 07:31:57 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::57b:b81e:33ec:5512]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::57b:b81e:33ec:5512%7]) with mapi id 15.20.2856.018; Wed, 25 Mar 2020 07:31:57 +0000 From: Christer Holmberg To: Martin Thomson , "v3@ietf.org" Thread-Topic: [V3] RIPT virtual meeting info for IETF 107 Thread-Index: AQHWAmPeOaL1oi6vi02LxdA+btbQpahZC6sA Date: Wed, 25 Mar 2020 07:31:57 +0000 Message-ID: <104BD9AB-5E65-49B9-B296-43FE904EC1B9@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5f1be918-bd9b-453c-8e02-08d7d08e994b x-ms-traffictypediagnostic: AM0PR07MB4498: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-forefront-prvs: 0353563E2B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(136003)(346002)(396003)(376002)(33656002)(110136005)(316002)(66476007)(66556008)(64756008)(66446008)(91956017)(76116006)(8936002)(66946007)(36756003)(2616005)(478600001)(6506007)(44832011)(2906002)(8676002)(86362001)(6486002)(186003)(5660300002)(6512007)(71200400001)(26005)(558084003)(81166006)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4498; H:AM0PR07MB3987.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /bPv9AGua0oQKuBZe/HPLG4ykWkTAShf7IdWPZHHm6XodtveBrRBFQbJ+b6ErSjqUYzTsddAaw2L9TNc8F7frv4lCgCkHn6jpvjyiLpupFcEGqwddBK1r/fieKST/AD30IuNRYlO+Ft9Q2W6MjMNTsZdO2ENe+HctWR7qBp8DPzK2LehRimTFBCc4fEiNczrq+7vXfKk46XCJHBqqc3/CB9xBQ8th4jOBq5Y43/psIxxwvw6K+We7/CCj/+tUcacufXcoZmjajg5xAyiRPPwJUdZ6N0YV6yUoTpeaCJGFu88XqZdc5gJ5iSHPhUt3HNSXf8FHCxk+BUIKbLtFD0wnPANUYmSKxUJJQ+yBdkdAeISTJcEhVcfD3LtxTRkvWlsJxHxoO1CRt2qtQiPKjlU9k1a9plh++t5dkzCXYwIihRXvhK5gbR1CDnSWHm+2o0/ x-ms-exchange-antispam-messagedata: cZZTHQ53AaNV+SGpM+JyxxY+F/DUoNj3oCIdYfRCQKV2aqiobfZ5Ff5mMm196OscTr3UiSoTJ2TnNbDKxwPd5eB4fIpYQpPYVSCp9ffCpdGSz3+P+CkbXK+kmGe4sAeiTjucmjtvw6YbwM3iZyWPbQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <07C07C2D65283243BD0A34535FEE26F8@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5f1be918-bd9b-453c-8e02-08d7d08e994b X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2020 07:31:57.0834 (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-CrossTenant-userprincipalname: I3hUcXoso4z/oVOf5TBjYDmA+noiGBwBJ5mZPnmsLl/wWwFaUserW2pwER0tGwdxuZ6c1HgzbxWt4koQu+txZC6m8OzB4fHjVUr0ZMdINs8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4498 Archived-At: Subject: Re: [V3] RIPT virtual meeting info for IETF 107 X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 07:32:09 -0000 DQo+ICAgIFByb3BzIHRvIFNlYW4gVHVybmVyIGZvciBzZXR0aW5nIGEgZ29vZCBleGFtcGxlIGhl cmUuICBIZXJlIGlzIHRoZSBpbmZvIHlvdSB3aWxsIG5lZWQgZm9yIHRoZSBtZWV0aW5nIG9uIFdl ZC9UaHU6DQogIA0KSnVzdCB0byB2ZXJpZnk6IElzIHRoZXJlIGdvaW5nIHRvIGJlIGEgVjMgbWVl dGluZyBvbiBXZWRuZXNkYXksIG9yIGFyZSB5b3UgcmVmZXJyaW5nIHRvIHNvbWUgb3RoZXIgbWVl dGluZz8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCiANCg0K From nobody Wed Mar 25 03:21:25 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6DB3A0CC8 for ; Wed, 25 Mar 2020 03:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lowentropy.net header.b=Q9nol1yE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pUjcEh81 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 16ijKB3VIo_j for ; Wed, 25 Mar 2020 03:21:22 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4D5E3A0CBD for ; Wed, 25 Mar 2020 03:21:22 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 95A4B5C3; Wed, 25 Mar 2020 06:21:21 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 25 Mar 2020 06:21:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=8JqGaXVtzssKOGGLxNQ6lwW+qnVjHFu 9LMJYdJSitIw=; b=Q9nol1yE6AmUN79OmMd2/v8IDtq5aSI9xPGr10+tJTKo4pD 6F6coBUsi/k0c+uzW6FUwNf9A5tyH9r20XFbwaXFtz2vHGYykTD0ZOBDTERtZBYN yoDc5JuMG+5goE9l9wJfqmnTS44DNOuJiYlPt3AA/oHqTTTatJuCsJv+8HGDyWWy WOhT1cNwKA10x3s2yIARrftCzSL9HSQX8je7t3ojcmc9wXoBDuO/WNB8aEdozBO+ NMaT3BrtD/FAW9mBR0UWDisrJNGX5n/QuLBt8wKyvkZCzQiMNRiiRIF3qVk4EK43 Z+oBMaQsbOX1+KBBTct7hdmHQJKQ1IBG9VVTfLQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=8JqGaX VtzssKOGGLxNQ6lwW+qnVjHFu9LMJYdJSitIw=; b=pUjcEh81wh4KZtOuPnMUXz kGobQFk1n9L5mKbI1EKTqnLbrY/YebAQ94bzLGUxHg13O2+QYQK8uHaoxGO9C0i2 JLMkbmrIAY/qDszMSg5qZMYglpyXTioE+ZpRtwXCxjBCtR1nEVOznKSj2Y4+9SxO 6Sk7bkeBjP3meZYXaYjaL62L5R+NEmHjbUCm1IvkNoGZLrsWfVUoaNbV00YbGIU6 JBaSvnHMD8e0Ydk2tlpJOELZ124G3iGH1m7xBEtyosQ60OdECHZnBeU2T2mxzTzO EE4Wc7+yTS/fQcufDUcR4wgQcnRrq/zFlYB9baZEtBLDE+79Kt40xTghacpehfgw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehfedgudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohif vghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9FCE4E00A6; Wed, 25 Mar 2020 06:21:20 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-Id: <709bc6fb-1daa-401f-9787-545f861db2e0@beta.fastmail.com> In-Reply-To: <104BD9AB-5E65-49B9-B296-43FE904EC1B9@ericsson.com> References: <104BD9AB-5E65-49B9-B296-43FE904EC1B9@ericsson.com> Date: Wed, 25 Mar 2020 21:20:58 +1100 From: "Martin Thomson" To: "Christer Holmberg" , "v3@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [V3] RIPT virtual meeting info for IETF 107 X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 10:21:24 -0000 On Wed, Mar 25, 2020, at 18:31, Christer Holmberg wrote: > > Props to Sean Turner for setting a good example here. Here is the info you will need for the meeting on Wed/Thu: > > Just to verify: Is there going to be a V3 meeting on Wednesday, or are > you referring to some other meeting? I am sorry, the meeting is on Thursday for a little over half the planet and Friday for the remainder. From nobody Wed Mar 25 03:48:43 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EEF3A0D0C for ; Wed, 25 Mar 2020 03:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 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 nNlkUPWnBvSW for ; Wed, 25 Mar 2020 03:48:39 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0602.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::602]) (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 14C123A0D06 for ; Wed, 25 Mar 2020 03:48:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SK3YcF7LA6iHTtLC6nS0HUDrlLfBoE1O2FIoFOoR3LJiaSc6mM/OjFD3qUUYavemCpe+EDsjeY7Vk72HDjBXQy8EIGn1Si8T7wiOPXS3N4GltjR/8dveBs5aSLfimgAMwwuuubFC94r4V5uhMPa0ZC2//ma8bXQTLgIFR4Okp419Px8bCQP+7KrWU0WgZ0TeWhQ+zbF0VE2yvDFKDInjd9l1h1H4YbPHrzpjQ01u1O0UnkSR2MF1lCqJCbQMQem4MjkembvHFt+EOeR/LDd6bvKIHfvrcO3S9TPQ/SbMjY4uV1WTGd+BfQ/wq7cI84a0UNpywpaYF6DUYv+F2aZ7eQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TW/ZY7inpUlptPVWD/c14yvvJtvhlVeqfNNVYVemePo=; b=e90AzqXqFMrJHKuLkLdQn8gX/vxUSo1Ub7ckiVyVVyxZrvDADmlXt5xG03O5Chv6fHa8wnILe9I0mumPNEdAy23SNkSsM220M5FFFui9bPXft+qEUGQqu9JLkvmFOOfmpkbdlwQq79kY5LghYmpur2jWCLYlPjV7DpZ9xVBXEMBtdoV2208GC1p3V/i1yekfwm87mdLeytqAb1j2jv39LDyavNIl9k0+b+bZJJ9+yVC67PONU0hTpqMytp7WlIkwwEgayLLJZI82N2auL9XBHdTmvQPFamE4FHC4eIWWk05aRzepEAPZs9m/wB/OUzdWw+ZkutTkMXmp6iPOPJb/qA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=TW/ZY7inpUlptPVWD/c14yvvJtvhlVeqfNNVYVemePo=; b=jc5zeObxf893RkZtZQs1zPWBT+DxknX+8KdSbWD1/J+rS7OpOhW10oSePQx5sXZbUJWuopuUc6JqjGzTmxyvfYf8L7Af3KSE8TTojxdcWChQTWLaKlkomkJkQy7ZWDFiNwK0+Cy5Lj/ODuAROhDd0AtchSSzwspiaeHWwOnNvlQ= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (52.134.82.159) by AM0PR07MB5779.eurprd07.prod.outlook.com (20.178.116.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17; Wed, 25 Mar 2020 10:48:36 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::57b:b81e:33ec:5512]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::57b:b81e:33ec:5512%7]) with mapi id 15.20.2856.018; Wed, 25 Mar 2020 10:48:36 +0000 From: Christer Holmberg To: Martin Thomson , "v3@ietf.org" Thread-Topic: [V3] RIPT virtual meeting info for IETF 107 Thread-Index: AQHWAmPeOaL1oi6vi02LxdA+btbQpahZC6sAgAANswCAAClAAA== Date: Wed, 25 Mar 2020 10:48:36 +0000 Message-ID: References: <104BD9AB-5E65-49B9-B296-43FE904EC1B9@ericsson.com> <709bc6fb-1daa-401f-9787-545f861db2e0@beta.fastmail.com> In-Reply-To: <709bc6fb-1daa-401f-9787-545f861db2e0@beta.fastmail.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cf4d5028-48cb-4a01-b1aa-08d7d0aa123c x-ms-traffictypediagnostic: AM0PR07MB5779: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0353563E2B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(396003)(136003)(366004)(346002)(91956017)(66556008)(33656002)(478600001)(64756008)(66476007)(66446008)(6512007)(76116006)(4744005)(6486002)(6506007)(26005)(66946007)(5660300002)(8936002)(36756003)(316002)(2906002)(44832011)(8676002)(71200400001)(110136005)(86362001)(81166006)(186003)(2616005)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5779; H:AM0PR07MB3987.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: W20BqsabL+PO72lk6SASxouo+F1RhbXCkYxah7uiMbpQb9/cyrYp7WQ01n6vPWJWL6tYfcJLkSA00usVv5LlHk5hVpiQ3iQjJ7hAFXGv68qR9chV3i8tO9CFkk340V7LQIk0iOEd5Sjsp+jdF8Jri+EYllqSw9F0RtsWbFO6oxcgcQGJ2d3U5QPk2FXqcokG+ZTM9horKtrOviNcXXy67Q6V+80/I+m24Ii//NA8LB2T7pR2R7qEcDXM1XwguYP8V3PVkwzewINs9PaD0Y2Qal6bzTXnC90abp+XEcBY3S1jpMwguuTtJomWf4GdT4Nlcu86eMpqCMIqbjAPP7xuatnIjS9kHh0t9HF9UWaRNte8ZAUaAtTg3Bwdh9ijkoZ979zeJ3vqnOUz3jAn9r99Oqfn3/LDwv84WK1UIU1acP0/BZKRD/il/QgiBONF3xU9 x-ms-exchange-antispam-messagedata: 3f8qr+tD2Roa8abVO2CMaQkOIsyg9c3qzRz0LI4puVrt8d9UmoabwyXMcb4HAnzpQfxjv3PWFt8yYdP/u5PTvGMvPBiGn6tpzLfCKvGtrL/rSS5tC4WxLrUzI+Bal6mPXtasVJ1cDEJZ6/dgyA6epQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <48AF381BF74B8948B7ABE2FB5ED5A81F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: cf4d5028-48cb-4a01-b1aa-08d7d0aa123c X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2020 10:48:36.3830 (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-CrossTenant-userprincipalname: X5Y/kCKK63jjznfcSW3m8t8DffBWOjHBbdYcmG9UV5llhktME78ziLbAc5r3gFIxbqjWTCkMZyx1ER5WkOeISnrZ+2INccO8rgjVTN/idM0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5779 Archived-At: Subject: Re: [V3] RIPT virtual meeting info for IETF 107 X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 10:48:41 -0000 DQogICAgPj4+IFByb3BzIHRvIFNlYW4gVHVybmVyIGZvciBzZXR0aW5nIGEgZ29vZCBleGFtcGxl IGhlcmUuICBIZXJlIGlzIHRoZSBpbmZvIHlvdSB3aWxsIG5lZWQgZm9yIHRoZSBtZWV0aW5nIG9u IFdlZC9UaHU6DQogICAgPj4gICANCiAgICA+PiBKdXN0IHRvIHZlcmlmeTogSXMgdGhlcmUgZ29p bmcgdG8gYmUgYSBWMyBtZWV0aW5nIG9uIFdlZG5lc2RheSwgb3IgYXJlIA0KICAgID4+IHlvdSBy ZWZlcnJpbmcgdG8gc29tZSBvdGhlciBtZWV0aW5nPw0KICAgID4NCiAgICA+IEkgYW0gc29ycnks IHRoZSBtZWV0aW5nIGlzIG9uIFRodXJzZGF5IGZvciBhIGxpdHRsZSBvdmVyIGhhbGYgdGhlIHBs YW5ldCBhbmQgRnJpZGF5IGZvciB0aGUgcmVtYWluZGVyLg0KDQpJIGZpcnN0IGFzc3VtZWQgaXQg d2FzIGEgdGltZSB6b25lIGRpZmZlcmVuY2UgdGhpbmcsIGJ1dCBJIGNvdWxkbid0IGZpZ3VyZSBv dXQgd2hlcmUgb24gdGhlIHBsYW5ldCBpdCB3b3VsZCBzdGlsbCBiZSBXZWRuZXNkYXkgYXQgdGhl IHRpbWUgb2YgdGhlIG1lZXRpbmcgOikNCg0KVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbiEN Cg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Wed Mar 25 08:31:10 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2533A0983 for ; Wed, 25 Mar 2020 08:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 xFNZEmEkxIOO for ; Wed, 25 Mar 2020 08:31:05 -0700 (PDT) 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 58D4E3A095D for ; Wed, 25 Mar 2020 08:31:04 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id v16so2864547ljk.13 for ; Wed, 25 Mar 2020 08:31:04 -0700 (PDT) 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=PGP2awUiXDKYQl6IeNrlKL0leSg4HgpMBkG8QCZ6yvg=; b=eHMDOl7Ncx+8zBp7q9vmeidTff5Lmv3imCR8lNuaopNyUhuWpOUN/KEclt9+LxhpHW H0660xT1smcjUEj20ewHlUeDQExTO7ubDPRb5ud5U59REnqkwoi8pysx/PpqZ9zKdi7G KctHitXqyx9auCPReOe/fEuuLlpaFJH412gBo5Nja/6YdxOMP1r8D2i6EnCvhNxQ8ZVR IBFIG125XtLcRjHlZ/ArbuGHmYODTjrnj1QM7wNmn9VnBpDY47Lq5d2Zd2FFy+RPg+3v 9EgF41wqdTm2dKvxs8LEGM5bosPcidDU20Px5AqdQK4MVg/JlkUTqG7Urb5LLjtU2uXr BCMg== 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=PGP2awUiXDKYQl6IeNrlKL0leSg4HgpMBkG8QCZ6yvg=; b=CKLuhMfoWQckHgIIuPDnd8F8NX7N7jX8TGJ0VbujLv6DSqD9MJhX/woK3VzPg8JajD h13Lzczqxq/TAEIHOEeAAsRM06a1LHgsHkLH2kSPJj8v46Tx8Xul6awGt8rKSw23J4Jl GFxU4JX1cdsIxJdFc4EulGNSvos7uIHyDvEvtJ1+0Mkk5Xz5vYoZXXbA6jLcr65K0vz6 OI0NhFhaFfFCZlj8gfmwwA//l/ep5XvPJ3qoTLiHmdKvh0DEpzdxzCwJvi1w1YlPbGv4 mgDg7n5fVW6LfjMU0XttnyGaNK95muvVZmaVsVPJWrNA6WbgDkbDu5Yq2GsCzbyp8CpN /y9Q== X-Gm-Message-State: AGi0PubAR9yk0d56jXR55yYPodWkoyJ4v137wRaIf5R+oL65/xpboKO2 5cWWEE45QUSYUxThMXt0MtM6CkBvcdMMbMQCEipFFQ== X-Google-Smtp-Source: ADFU+vsWJetudDyXl4yfbsccdd5xaxN5Y9GtWLwayV3wkRQlbaL2zGECbKLk6cXeTlYpMzLdP+MOJvZe7HVMp0uMYKY= X-Received: by 2002:a2e:85cb:: with SMTP id h11mr2343272ljj.55.1585150259569; Wed, 25 Mar 2020 08:30:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Victor Vasiliev Date: Wed, 25 Mar 2020 11:30:46 -0400 Message-ID: To: Justin Uberti Cc: Jonathan Rosenberg , "v3@ietf.org" Content-Type: multipart/alternative; boundary="00000000000023856305a1af8ece" Archived-At: Subject: Re: [V3] Thoughts on scope for ript X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 15:31:08 -0000 --00000000000023856305a1af8ece Content-Type: text/plain; charset="UTF-8" I would like to second Justin's point here about the value of a client-server RTP streaming by itself (e-f, though in-band c-d are also valuable). There's a lot of value in the world where I can take an HTTP URL to some endpoint in the cloud and give it to, say, an IoT camera device to use as a realtime media sink, or pass it to an off-the-shelf streaming library to show a realtime media source on screen. On Mon, Mar 23, 2020 at 1:09 PM Justin Uberti wrote: > In addition to Eric's comments, I think the biggest question regarding > goals and scope is whether we focus on both client-to-server and > server-to-server. > > If we are taking a fresh look at how all of IP calling works, we could > find ourselves looking at: > a) a replacement for SIP "RPCs" (i.e, how are commands reliably exchanged) > b) a replacement for SIP operations and routing (i.e., the specific > commands and routing mechanisms) > c) a replacement for offer-answer (i.e., how do both sides agree on media > formats) > d) a replacement for SDP (i.e., the details of how media formats are > described) > e) a replacement for SRTP (i.e., how media is transmitted from point A to > B) > f) a replacement for RTP packetization (i.e., how media is encapsulated > when transmitted) > > I think that server-to-server, essentially a NNI, requires us to consider > all of these items, and that may ultimately make sense. However, if we > focus initially on client-to-server, we can get by by only focusing on e) > and f), as a-d) are under application control > > This could still provide a lot of value, since moving to a world where > even private RTC services can be built atop HTTP would still be quite an > accomplishment. (Compared to the current state of the world, where people > deploying cloud RTC services need to source and deploy their own > ICE/DTLS/SCTP/SRTP stacks and all the load > balancing/authentication/failover tech that Jonathan mentions). It would > also be complementary to WebRTC, which works pretty well for p2p > applications, but struggles in c2s environments for the aforementioned > reasons. > > > On Mon, Mar 23, 2020 at 7:21 AM Jonathan Rosenberg > wrote: > >> With our BoF coming up this Thursday, I thought the time is right to >> restart discussions with a focus in particular on SCOPE of the effort. >> >> For me its defined entirely by the GOAL. The goal is: >> >> It is possible to implement a ript server in public cloud, such that it >> is nothing more than a web application as far as public cloud is concerned, >> and therefore works with web-centric features such as Kubernetes, global >> http load balancers, and service meshes - to name a few. The server >> implements everything needed to make and receive voice and video calls. >> >> I do think the scope needs to be inclusive of server to server peering, >> not just client to server. The client-to-server stuff defines the core, but >> for me I'm really interested in building an alternative to sip trunking and >> that requires solving for additional things (inbound load balancing, >> inbound authentication, number routing). I think those can easily be in a >> separate draft but I think they should be in scope. >> >> Thx, >> Jonathan R. >> >> -- >> Jonathan Rosenberg >> CTO and Head of AI, Five9 >> >> >> ________________________________ >> >> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain >> confidential information of Five9 and/or its affiliated entities. Access by >> the intended recipient only is authorized. Any liability arising from any >> party acting, or refraining from acting, on any information contained in >> this e-mail is hereby excluded. If you are not the intended recipient, >> please notify the sender immediately, destroy the original transmission and >> its attachments and do not disclose the contents to any other person, use >> it for any purpose, or store or copy the information in any medium. >> Copyright in this e-mail and any attachments belongs to Five9 and/or its >> affiliated entities.. >> >> -- >> V3 mailing list >> V3@ietf.org >> https://www.ietf.org/mailman/listinfo/v3 >> > -- > V3 mailing list > V3@ietf.org > https://www.ietf.org/mailman/listinfo/v3 > --00000000000023856305a1af8ece Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would like to second Justin's point here about the v= alue of a client-server RTP streaming by itself (e-f, though in-band c-d ar= e also valuable).=C2=A0 There's a lot of value in the world where I can= take an HTTP URL to some endpoint in the cloud and give it to, say, an IoT= camera device to use as a realtime media sink, or pass it to an off-the-sh= elf streaming library to show a realtime media source on screen.

<= div class=3D"gmail_quote">
On Mon, Mar= 23, 2020 at 1:09 PM Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> = wrote:
In addition to Eric's comments, I think the biggest question r= egarding goals and scope is whether we focus on both client-to-server and s= erver-to-server.=C2=A0

If we are taking a fresh look at = how all of IP calling works, we could find ourselves looking at:
=
a) a replacement for=C2=A0SIP=C2=A0= "RPCs" (i.e, how are commands reliably exchanged)
b) a = replacement for SIP operations and routing (i.e., the specific commands and= routing mechanisms)
c) a replacement for offer-answer (i.e., how= do both sides agree on media formats)
d) a replacement for= =C2=A0SDP (i.e., the details of how media formats are described)
e) a replacement for SRTP (i.e., how media is transmitted = from point A to B)
f) a replacement for RTP packetization (i.e., = how media is encapsulated when transmitted)

I thin= k that server-to-server, essentially a NNI, requires us to consider all of = these items, and that may ultimately make sense. However, if we focus initi= ally on client-to-server, we can get by by only focusing on e) and f), as a= -d) are under application control

This could still= provide a lot of value, since moving to a world where even private RTC ser= vices can be built atop HTTP would still be quite an accomplishment. (Compa= red to the current state of the world, where people deploying cloud RTC ser= vices need to source and deploy their own ICE/DTLS/SCTP/SRTP stacks and all= the load balancing/authentication/failover tech that Jonathan mentions). I= t would also be complementary to WebRTC, which works pretty well for p2p ap= plications, but struggles in c2s environments for the aforementioned reason= s.


On Mon, Mar 23, 2020 at 7:21 AM Jonathan Rose= nberg <jdrosen@fi= ve9.com> wrote:
With our BoF coming up this Thursday, I thought the time is right to= restart discussions with a focus in particular on SCOPE of the effort.

For me its defined entirely by the GOAL. The goal is:

It is possible to implement a ript server in public cloud, such that it is = nothing more than a web application as far as public cloud is concerned, an= d therefore works with web-centric features such as Kubernetes, global http= load balancers, and service meshes - to name a few. The server implements = everything needed to make and receive voice and video calls.

I do think the scope needs to be inclusive of server to server peering, not= just client to server. The client-to-server stuff defines the core, but fo= r me I'm really interested in building an alternative to sip trunking a= nd that requires solving for additional things (inbound load balancing, inb= ound authentication, number routing). I think those can easily be in a sepa= rate draft but I think they should be in scope.

Thx,
Jonathan R.

--
Jonathan Rosenberg
CTO and Head of AI, Five9


________________________________

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= ..

--
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3
--
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3
--00000000000023856305a1af8ece-- From nobody Wed Mar 25 09:28:24 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B493A0BCF for ; Wed, 25 Mar 2020 09:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 8BZGL-23-_ke for ; Wed, 25 Mar 2020 09:28:20 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 332033A085C for ; Wed, 25 Mar 2020 09:28:20 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id n20so2299780lfl.10 for ; Wed, 25 Mar 2020 09:28:19 -0700 (PDT) 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=KAuACdV8vgd+R96U83ycLJxsAYqsbt9bCqLD80q68OU=; b=CFhFRgNKjk0MvnILrelSJ7nuBseGaLnDABRyJk4F7PklAVFW8dtJZBmdSoowHe8wXd wbxqcdpHmgPRVrTpMalFtS6CeMJcjHRLDrLF+z1AbhBWzTs2AO8BaG03VbyvDuXjGHlj K0ZMu3k5yaeopfm+4c2C11e3d79fKENbTVfv2GGy/MJ08vS6MDxFDkPF5m71/uWkmYMA n3oW2MH2DLuPU47Z3hWeLsWx+nC98iTnVPteiGkyZCGQ3oSN1hn7xHp9q9ecyjK6nKF6 HTOqzInQwuxYdXA1hOwiFgNb63wVELhM5YfxLkZPkcLZB8Pm/h5ChDyIB/C01Il0o7NF OnIA== 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=KAuACdV8vgd+R96U83ycLJxsAYqsbt9bCqLD80q68OU=; b=C2q/FN1eovM9nOLHw1eC3dIhBBGt0+lCf4VkeacXttOTGgEq41x3e3KrJQGizqGWWd pTGwZvNdPwCSfT45ufS5p8DG3emGNoJCDo2sBXnizqvI7bSoQ7cwpHGLqMnHFGK8V9Wx f9PEYzP7nhNJc0vRNt3PBCMiUg4Hli5K3LZ4GfMTWxaO6j+bI/wlAikwWmL0UtpsSwJ8 7NRVnEquhEsXVMTUiDWQZDGz9F+mBN+B29z2/tgnCsy+MoGUQXv1keAAJ1u78hlKMBga YVCu2S0+DJofi7mgcfrmLTgAFaBXHhEZiT90lCd08QvB3h8eGzqtejVImAreBp+iryn6 k36A== X-Gm-Message-State: ANhLgQ0h6pi99zoMqgpkga+nn+yTVFyzhuE9jqgKSSLZWC423vQOx+ut xbWIdmblrk4QIdsEAf5kVr60bZq6AUQOniSeVU4= X-Google-Smtp-Source: ADFU+vtfBHeEDGwkNAJ+6A1xJNHzy930ohrcyaLHK2g0uyFGpNx+s9+QKGvt7KTUi+Eg9pDYt/uQEOXStaNl2nyC8ZI= X-Received: by 2002:ac2:4433:: with SMTP id w19mr2834857lfl.53.1585153697006; Wed, 25 Mar 2020 09:28:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Wed, 25 Mar 2020 11:27:51 -0500 Message-ID: To: Victor Vasiliev Cc: Justin Uberti , Jonathan Rosenberg , "v3@ietf.org" Content-Type: multipart/alternative; boundary="00000000000006474b05a1b05b85" Archived-At: Subject: Re: [V3] Thoughts on scope for ript X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 16:28:23 -0000 --00000000000006474b05a1b05b85 Content-Type: text/plain; charset="UTF-8" This is interesting ... On Wed, Mar 25, 2020 at 10:31 AM Victor Vasiliev wrote: > I would like to second Justin's point here about the value of a > client-server RTP streaming by itself (e-f, though in-band c-d are also > valuable). There's a lot of value in the world where I can take an HTTP > URL to some endpoint in the cloud and give it to, say, an IoT camera device > to use as a realtime media sink, or pass it to an off-the-shelf streaming > library to show a realtime media source on screen. > I know most of my own concerns about RIPT media have started out with "this won't be as good as RTP for media", but what I've been getting from RIPT discussions is, that may not matter as much as I expected. For a use case like Victor's, great media quality would be great, but good enough media quality may be ... good enough. Am I putting words in the mouths of the proponents? Best, Spencer --00000000000006474b05a1b05b85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is interesting ...

On Wed, Mar 25, 20= 20 at 10:31 AM Victor Vasiliev <vasilvv=3D40google.com@dmarc.ietf.org> wrote:
I would like t= o second Justin's point here about the value of a client-server RTP str= eaming by itself (e-f, though in-band c-d are also valuable).=C2=A0 There&#= 39;s a lot of value in the world where I can take an HTTP URL to some endpo= int in the cloud and give it to, say, an IoT camera device to use as a real= time media sink, or pass it to an off-the-shelf streaming library to show a= realtime media source on screen.

I k= now most of my own concerns about RIPT media have started out with "th= is won't be as good as RTP for media", but what I've been gett= ing from RIPT discussions is, that may not matter as much as I expected.=C2= =A0

For a use case like Victor's, great media = quality would be great, but good enough media quality may be ... good enoug= h.=C2=A0

Am I putting words in the mouths of the p= roponents?

Best,

Spencer= =C2=A0
--00000000000006474b05a1b05b85-- From nobody Wed Mar 25 09:54:15 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CC03A0A45 for ; Wed, 25 Mar 2020 09:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=signalwire.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 YPRzX-EqU0ca for ; Wed, 25 Mar 2020 09:54:11 -0700 (PDT) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (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 012F03A0A03 for ; Wed, 25 Mar 2020 09:54:10 -0700 (PDT) Received: by mail-vk1-xa31.google.com with SMTP id o124so867234vkc.4 for ; Wed, 25 Mar 2020 09:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=signalwire.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Iteuc/uJw4uyL4d7vyBpvfJ5gU2LNPL6t4Vn1PsW8S8=; b=YsuBO22n42VCYQbRJbxlEDjQfD9uq7ynIBs2kGQxdqPJAf6AxKVGyTqTnQa2jbmGfw qqo13X1oV/v345CoHSVT6W9/JxbM2KgGnC7PXuCe0iWCG8Ayt+mWhLt3FrnnEhByNkdk iaDgoprBAuARAU0W1QO+MO1xqHkXTkLHroet8= 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=Iteuc/uJw4uyL4d7vyBpvfJ5gU2LNPL6t4Vn1PsW8S8=; b=bAgJahVgyg+yoMPtiOlQLAqoYBfYg0ScY5d6elp+kgTiejaUtj9y1fiND+vmJo0du4 9XQVyNJbIYf06c+R5K1yz8A1S6JEDlazKFSQnUo11R8yPvoqe74lJ3fUTJnsLM2UKFaK NWova1MrVSQ8yemGXRgx0/JLE4ybM63BuPoSG1pHKsyXkpI1aogh/gkicMbUlgCVJbSk 0QJEz2tnctu8ZN61r5w4hvomU2Wv82XPnDkj3gtVYeqp3tZojHu7ieJoKE6Jrb1rq+Da 3S4azOb/Qm0wpLV7TcbyIr+zNeDUKCTqmNZyUciiTMsad0ZuEtE9oOPPm0Jj93IWEgwR yOPA== X-Gm-Message-State: ANhLgQ0GRGdX0Ijy1tbL7rFJ6dcjeoUHLWswxt8XRhSsshSCkByAlKlr nZXDzXdpWGG0kXOSMURaaidXnjUVnZnI0vNNtH0ZPA== X-Google-Smtp-Source: ADFU+vshLdD4sF31mmSC8UTH7cMY3cnz/kMd7r5DHrGIrfJ9KJZ1zhjTfEaaNRsHAfMyxIkSPhDY9yUdtZf2x65ZGsI= X-Received: by 2002:a1f:2c4b:: with SMTP id s72mr3280889vks.93.1585155249268; Wed, 25 Mar 2020 09:54:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Anthony Minessale Date: Wed, 25 Mar 2020 11:53:57 -0500 Message-ID: To: Spencer Dawkins at IETF Cc: Victor Vasiliev , "v3@ietf.org" , Jonathan Rosenberg , Justin Uberti Content-Type: multipart/related; boundary="0000000000008c9e2205a1b0b757" Archived-At: Subject: Re: [V3] Thoughts on scope for ript X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 16:54:14 -0000 --0000000000008c9e2205a1b0b757 Content-Type: multipart/alternative; boundary="0000000000008c9e1f05a1b0b756" --0000000000008c9e1f05a1b0b756 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 25, 2020 at 11:28 AM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > This is interesting ... > > On Wed, Mar 25, 2020 at 10:31 AM Victor Vasiliev 40google.com@dmarc.ietf.org> wrote: > >> I would like to second Justin's point here about the value of a >> client-server RTP streaming by itself (e-f, though in-band c-d are also >> valuable). There's a lot of value in the world where I can take an HTTP >> URL to some endpoint in the cloud and give it to, say, an IoT camera device >> to use as a realtime media sink, or pass it to an off-the-shelf streaming >> library to show a realtime media source on screen. >> > > I know most of my own concerns about RIPT media have started out with > "this won't be as good as RTP for media", but what I've been getting from > RIPT discussions is, that may not matter as much as I expected. > > For a use case like Victor's, great media quality would be great, but good > enough media quality may be ... good enough. > > Am I putting words in the mouths of the proponents? > > Being "as good as RTP" is relative and so is "quality" There is quality like how it sounds and quality like (how many packets did I get that I am supposed to be getting and are they on time, are they dejittered and are they dropped when they are too old) If the media signal is in good shape then the second type makes all the difference in preserving that. One thing about RTP that is helpful but often not taken advantage of is that you can pass it through as is even out of order and messed up and the final thing to receive the stream can put things back together. If something in the middle just cleanses it and rewrites all the timestamps you get a permanently messed-up stream that can never be fixed. Sometimes you want to dejitter and rewrite the packets when you know the next hop has no way to do it but otherwise usually only when you are the final terminating leg. Everything RTP can do to make sure you have these features should be duplicated or maybe an encapsulation mode to just carry old school RTP as a payload so 2 aincent devices can still exchange RTP across a RIPT-wormhole. > Best, > > Spencer > -- > V3 mailing list > V3@ietf.org > https://www.ietf.org/mailman/listinfo/v3 > -- Anthony Minessale | Founder and CEO SignalWire: *228 Hamilton Ave 3rd Floor, Palo Alto, CA 94303 * *https://youtu.be/WKjZkzgK4pc * https://youtu.be/MwqpSl7luSM https://youtu.be/l82JtCECkog Email: anthm@signalwire.com Phone: 262-309-8501 Website: https://www.signalwire.com --0000000000008c9e1f05a1b0b756 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 25, 2020 at 11:28 AM Spen= cer Dawkins at IETF <sp= encerdawkins.ietf@gmail.com> wrote:
This is intere= sting ...

On Wed, Mar 25, 2020 at 10:31 AM Victor Vasiliev <vasilvv=3D40google.com@= dmarc.ietf.org> wrote:
I would like to second Justin's point he= re about the value of a client-server RTP streaming by itself (e-f, though = in-band c-d are also valuable).=C2=A0 There's a lot of value in the wor= ld where I can take an HTTP URL to some endpoint in the cloud and give it t= o, say, an IoT camera device to use as a realtime media sink, or pass it to= an off-the-shelf streaming library to show a realtime media source on scre= en.

I know most of my own concerns ab= out RIPT media have started out with "this won't be as good as RTP= for media", but what I've been getting from RIPT discussions is, = that may not matter as much as I expected.=C2=A0

F= or a use case like Victor's, great media quality would be great, but go= od enough media quality may be ... good enough.=C2=A0

<= div>Am I putting words in the mouths of the proponents?


Being "as good as RTP&qu= ot; is relative and so is "quality" There is quality like how it = sounds and quality like (how many packets did I get that I am supposed to b= e getting and are they on time, are they dejittered and are they dropped wh= en they are too old)
If the media signal is in good shape then th= e second type makes all the difference in preserving that.

One thing about RTP that is helpful but often not taken advantage = of is that you can pass it through as is even out of order and messed up an= d the final thing to receive the stream can put things back together.
=
If something in the middle just cleanses it and rewrites all the times= tamps you get a permanently messed-up stream that can never be fixed.
=
Sometimes you want to dejitter and rewrite the packets when you know t= he next hop has no way to do it but otherwise usually only when you are the= final terminating leg.

Everything RTP can do to m= ake sure you have these features should be duplicated or maybe an encapsula= tion mode to just carry old school RTP as a payload so 2 aincent=C2=A0devic= es can still exchange RTP across a RIPT-wormhole.

=



=C2=A0
Best,

Spencer=C2= =A0
--
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3


--
--0000000000008c9e1f05a1b0b756-- --0000000000008c9e2205a1b0b757 Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_jm25x25z1_165d8b71f782610b iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAFHElEQVRYCcVXXWgcVRT+ZnZ2d2Z3 093NJtmkmmyrTZOAWGORgFURC76JloIvgiJYCooYfJEqIsW/12pRiFrUJ0EsKvomFvEPqrSNIjQx at2kND/N3ya7O7szszPy3WQmk226s1qhBy737uw95zv33O+ce6/kOI6DJmRmQcfoH0uYmCpgcraI ueUKarU11VBIRnsqilw2gd7uJG7blUZnRmvCKiAFOTCWL+DkN3/j9Pl5zC3qwmgyEUGLFoYkr2HY NlDUTRRKBuAAHa0ahgbacPDeHejPJRs6clUHDMvGWyfP4/Pvp1DSTXSkNcSiIdpvKBKAcrWGuSUd cS2MB+/qxlMHBxBR1r2t097SgfxMES++dw6//rmE7o4YtKgC2w6C3mxZliXoVQtTc2XcenMaLz8x iFxnYvMkbLEFY5MFDL9xGoWiie5sHI7tBK76CqvrHxgNSZYwNVtCMhHGsWeG0N+zeUs2ReDi5RIe f+0HVA0LXZkYav9y1VdzJCRLuLRQFpF8/8g+3NAe96Z6G2NaDp4fOYti2WwaXJIAcoUEZCvpFphT /O4XLmR7JobVkokjI2dBLFc8B979Yhy/TCyKsAetnABsM4s6apYtCEqStqWikCWAWVEvtMktJQax XBFbcGG6iMde/Q7JWBhqpAmmSxJmFsq4b7ALj9x/E27MroWUpBs+/jPml3XE1bCL4fUMTMWooVA2 8eELd2NnVwIiAh9/fQFl3YKmKk0R7vJyBYO9rTh6aBC7c0nEVEW0TFIF99taL1Ae8vqAgScGsYhJ UZZWDfz42xyyrWpTqUYjlaqFA/fkPPuWZWN0YhFLRQOmaSMaDnn/1Q+YzsQiJrGVM+MLmF7QkeuM CwLVK9T/ZuUmwLZExPvrk1N5HP1gFJlUFNm0ihjrRoMKz4jlZ0ogtjyWXxbECYo9SUebZDpLLntX fr9YgGXbojwDEgIrhwOBSWyFVY+1fSMxXLObezKbDG9PaSIDImEvgdCajKInGxehZRmu1WxI9bno M0csYhJbevSVb52ibqEudX3T14aliom2lIZjT98BNaKIbAmF1rQM04Zp2ShVLDx7/CcsrFQRV5Ur bPg/0ImEpkDhkcqVNdgyoUdmk+Fker0wGmxqOISlFUPMq59T/5uYxG7spk+LxCPDT52ZFtu1Z1ca bevOjE8WRL1nYSL5tAZZ4DMphgrDaBukTmMhsyuGhZdOjOLSfAnvPLcP+/d2CaWPvvoLJ76cwO6e bchsU8FMCeSUAxBb5k2G9T9IuDISqz2lirOCFdMVpuT2thhSiaiIQBA49YjZkVIh57ItKBSNwAi4 YO454P5mz+ht9d0/xz/mfGLyfiAP7EhBnLpBe+C3cK1jHlgO0J9LQd7bl0FXRkO5slFYrtV+kD6x iElsOd0SwZ23dGB2sQJeo5oR8sHPASUkN3WO0DYxiEVMYoty9vD+nYhpCvRKcEGikZAsY6Vkiqhx NVWjBjoRJFweMYhFTIp3JXv70zGMfDaOvlwycDXiQIqEPNCqWROVUG5QfgnG1Y/nCzj8UB+ePNAv HPDcPvRAH/b0toqCworXSNwI8OrN1kwEaJOXU2IQyxXPgbAi4fXDt6MlHhYXyEZOuBxIaGGwBXGA tngppW1iEMsVzwF+4G31zeEhcZBMzpZEyDamuirN99Rl2GmLhxNt+2/EtORxwG/2uj5MXEeu69PM dYJ9M49TxwZW+TgtGkL1f3mc+p3guPHzXBIHS89/eJ7/A2tpgiJjIcQ7AAAAAElFTkSuQmCC --0000000000008c9e2205a1b0b757 Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_jm25y73l3_165d8b7eee16c0ac iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAFJElEQVRYCcVXS2gdVRj+zpmZO3fu I++Yh6lJSaO1wXbRnS6EKq5EQREEwY2IC5e660Lc60oU3epGKAruRIrUgCCCikpt+rAmNeYmaR5t 7mPunTtnRr4zmfvK3NuEBvrD3BnmnvN/3/8+I8IwDHEA2aoGuF70sVxWWHcD7NQCqL2dhgAGbIlx R2I6a2Aub2I4LQ+gFRD3IrBUUvi+UMNfd3xseQEEgKwp9MVnSgDA9UOU/BDkNJySODVg4tyEjZmc sbcq+daVgB8AF5Yq+GG9DlcFGEpJpA2hAZJVRW9JqqpCbHsBHEPi6TELr8xkYHZxSCKBgqvw2dUK bhR9PJSOgIMDBapJTYqIyEY1wIm8ibcey2DC2e+NfQSWSwofXi6h7IcYcyQOC9ykED2RCHOGYXtn PofpjpC0OYZsP7hcQjU4GnBSoAE0hDqp+3aVGdOUBgE/BD5ZLGvLR+z7t7wJEZGgTnr148UyiBVL g8A3t1xc3/V1KR3G7XGsaRmvrVqgAViaLFNeTEzqZJkSg1ixaAKrFYXvVmttMY833fGieidQp/Ad ARnfc+MpvHAsjSdHU/CDECsVpUvTMYQuU+6Nw0EsYlJM/lws1PTi4RbX0005U+DMYAo/bdZRD4CM KRpJST5btRCzORNvPprBoN1wJn7ZrOPb1Sqen0rjxw0Pf+746E9FFrCUN6uBxnx9NgNZ9EL8sV1H KzhJVfxQA742m8GrMw7ueiE2a1Ejoqp6GIKYb8y1g3Pv2REL50/ncarfhAjR1gPoBWIRk9jmlbt1 bQnj05Ib2tLYpqfGUhhICVxYcnGzpHRDYmyfGOzdcl0FSIk2vSRIL6y5AYhtLpUDCLF/kW1At162 WMcUmB+0cLLfwqW1Gn7bruvWXI3CSJ37hBOGhBm+8XS7cTSUmMQ211ylk6hTg20IPXAuFWp47uE0 DAl9PTNpgxeTiOTo0qQEZYiuFX3kurRvJi6xTU41JlenMAeOZQ1teYAQhi6m5qrJzP622vwX8BRg CQFDtga2uYKYxJaMZRzr5t+AJQF2RnYxK8nE1sUJz7erCizhbnuJ2Q1bq7Ol0FONQ+nfsmqUXwJW 4qsbRYWSH4ANqZdILmjvztFyOi5nRZ1rpaSw6yWt6q761606Mt1m8N4ZgtiSJxkmU5LQTfUQsAyh TzxJa5LeEXxx10ef1d185hiblxx3DH2SSVJEhmkD+OJmBQtrHnhO8Jj2PYTGfPlPBRlDdKRt+yYO JmLL49lo8nVyZd65KtQdccMN8OnVMhYKXs9cYFJ9dKWsGxtbbzeqxGKfmMlKmI/3Wxixo4Rj7cdC S1iGZ4csDNkSo46BCSepXqId/5UVPv+7gmtFpdf1chSPbMO2ALHNfErg9JCFi6s1TGWNhoXsVIwT U+9En5nYKwi9Ulb4edPDwrqn5z1J9gKPJ+izkzaIrY9k7Grv/17UHTG1V/O8kemOFyJvCkxlDExk JPIWYyt03hQqSo9dDirOCrbsXuAkzBxi/N87kwebWeNM+NWyi6+Xq/rM1qqEQWGR0BvMiThIjC+H CpONTatbvOOQ8k6jeOZ8aTqNl6cd/Zc+D/DpxUccPbdvlVXbqYiKmRq0nFeSHBScE3Cuz9RYsZ5G VnEcvH0yq8PAub8XiXjdfd2pizo5gIjROnoaBIgwmpZ4dz6HtBT6KH0UJKiDx3LqpG5itEojB1pf PtAPk5jIA/00i0nwfpCPUyYhS4sXn4/k47SVBJ/v9XnOwcKzw2E/z/8HeJXK68Y+LqEAAAAASUVO RK5CYII= --0000000000008c9e2205a1b0b757-- From nobody Wed Mar 25 09:55:47 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB1D3A09AB for ; Wed, 25 Mar 2020 09:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 QTLWQgvP13Ml for ; Wed, 25 Mar 2020 09:55:43 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 96A183A09A4 for ; Wed, 25 Mar 2020 09:55:42 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id o3so1961103vsd.4 for ; Wed, 25 Mar 2020 09:55:42 -0700 (PDT) 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=WyzqTRLggxDJDVnN2gBd/xoFffQq8EDMKy7aVL8hvdU=; b=uOGnwmboigrSxXjJO+MSMOdiONdhXcXyI0Gu0lCEwjtcoSwPXICEVUU+mGLqkuabSc 5MOSWh+j8fKj0KOFZWoUXp1gjtby/ApwktgLcWKift0qLL5Q8/nobSXy/4c4zUKBoWs7 vZPCCu7W9ARASaXeno/CgEaSuZXHzc5whUFixKvHgZx0iA4TTSpdl0f5I/fpC0Q4a3Sz PrTflYhaQOHJSK5KKJ8asQREI0O50kzAmwUp4o4VcIAytfGkAEENaJd9TUCuk8Q9/E4R M4raR0+UcvieoZ3IzELS3+bvo0h/cn2OtzSoACmbVytbxwtfhWUgLZPs73S1sSqwWyop Gwww== 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=WyzqTRLggxDJDVnN2gBd/xoFffQq8EDMKy7aVL8hvdU=; b=ksUu/IZrzA3t0eDnqtRMRgRGG6yGRB4u2UVpgmrnYomctaDpdj6eJE0MY0AHBF5r+4 clLVrbMButwdxCZCF1CQgmdYTyGsIj1BkxIfziQ5ucDl0HdnPe6Jv12nyhFhIGAnE2CS fjPowxZsVUa7t9d43PgI8xbayazWcWmx9+eS1lVqoUIhQR2DmwBxAHmtCdtpSGDz1Ubg af9judWWWIpE/Fei+Iyel9qdEHNUdUOcjk0dkFvFM1r0TobtwPjCERqVwkFo0LBS+Vw0 zr4edXGBVARUfnkEJt4dnlzMLs18rd0Tc8yhA32bTA4vsSds05XRWsjDFuLskpfhfJeX twAQ== X-Gm-Message-State: ANhLgQ2U81l3HEPOHmkJ3sRVAkL7pCW1WgcFfNIffrF0m666dBlkWfzV PozPeNUpJopiFS3wCi5Eb+hIRAVVTi0ACFkXhnOiWw== X-Google-Smtp-Source: ADFU+vsWCeLJxC3j15N7wi8R1HgoSNSl6fLT/SGwyqZg4l2gHeGDSo8WXNDo4QIIq5hYNtf/jWDjIYrAVXFYHk8GOOo= X-Received: by 2002:a67:8844:: with SMTP id k65mr3552716vsd.231.1585155340612; Wed, 25 Mar 2020 09:55:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Wed, 25 Mar 2020 09:55:28 -0700 Message-ID: To: Spencer Dawkins at IETF Cc: Victor Vasiliev , Jonathan Rosenberg , "v3@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fe1fea05a1b0bc72" Archived-At: Subject: Re: [V3] Thoughts on scope for ript X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 16:55:45 -0000 --000000000000fe1fea05a1b0bc72 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 25, 2020 at 9:28 AM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > This is interesting ... > > On Wed, Mar 25, 2020 at 10:31 AM Victor Vasiliev 40google.com@dmarc.ietf.org> wrote: > >> I would like to second Justin's point here about the value of a >> client-server RTP streaming by itself (e-f, though in-band c-d are also >> valuable). There's a lot of value in the world where I can take an HTTP >> URL to some endpoint in the cloud and give it to, say, an IoT camera device >> to use as a realtime media sink, or pass it to an off-the-shelf streaming >> library to show a realtime media source on screen. >> > > I know most of my own concerns about RIPT media have started out with > "this won't be as good as RTP for media", but what I've been getting from > RIPT discussions is, that may not matter as much as I expected. > > For a use case like Victor's, great media quality would be great, but good > enough media quality may be ... good enough. > > Am I putting words in the mouths of the proponents? > > Some applications may tolerate somewhat lower quality in fallback scenarios, but I think we should be aiming for RTP performance with HTTP ease of deployment. --000000000000fe1fea05a1b0bc72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 25, 2020 at 9:28 AM Spenc= er Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
This is interesting ...

On Wed, Mar 25, 2020 at 10:31 AM Victor Vasiliev = <vasilvv=3D40google.com@dmarc.ietf.org> wrote:
I would like to second Ju= stin's point here about the value of a client-server RTP streaming by i= tself (e-f, though in-band c-d are also valuable).=C2=A0 There's a lot = of value in the world where I can take an HTTP URL to some endpoint in the = cloud and give it to, say, an IoT camera device to use as a realtime media = sink, or pass it to an off-the-shelf streaming library to show a realtime m= edia source on screen.

I know most of= my own concerns about RIPT media have started out with "this won'= t be as good as RTP for media", but what I've been getting from RI= PT discussions is, that may not matter as much as I expected.=C2=A0

For a use case like Victor's, great media quality wou= ld be great, but good enough media quality may be ... good enough.=C2=A0

Am I putting words in the mouths of the proponents?<= /div>

Some applications may tol= erate somewhat lower quality in fallback scenarios, but I think we should b= e aiming for RTP performance with HTTP ease of deployment.
=C2=A0=
--000000000000fe1fea05a1b0bc72-- From nobody Wed Mar 25 12:26:26 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC703A0C3C for ; Wed, 25 Mar 2020 12:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 eqr8W5l9pGyx for ; Wed, 25 Mar 2020 12:26:15 -0700 (PDT) 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 9DB2D3A0BB0 for ; Wed, 25 Mar 2020 12:26:14 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id f20so3852851ljm.0 for ; Wed, 25 Mar 2020 12:26:14 -0700 (PDT) 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=puWYpC42LRs+5g4zLONfok5WaLKMzmC06XUVoUmpRUo=; b=cFP6M98genH+D1sCAe5kYQK0umEAd6YWYAEJgOCNf1qOsr+KvRuOGdQipYegkqPg0u We9Q8bb5iaH9TFWrE6bTlqEseMY+2HgNpBhH4cbr7IiEETNFJxb8/M87PKkA8wYjF5gX 2WUcuVIY5OXNt8iigwVUH0xqCDeecC75y6GwsP+DvcQggpwvT4C3vq2c4XvTaVNxPvSj J51tl1dKF0pPxBTj1arI/1P/SJnh7azx6p6l0xJu4hbbVwleus9OFHmMLDYF+9/bbPZg Bp6bmCmFi2Yu9qHGIMpa+PtOziAO1hLds7FOu/wVD/G/GmmDKGhKl+HgaR1YHvWGPoNu tt0g== 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=puWYpC42LRs+5g4zLONfok5WaLKMzmC06XUVoUmpRUo=; b=tbFNLE27yhfAQy10AUa7DX9skdxJoYiUVw8ekYpGqbD0CIS5jJsKxdZaW4R83//cs3 9QvcgDeZeyeeESqYE7Vp4xXfEdt7ZPfHzo8AKEg/8bv/VAYrh7Aw9rt5Cei3RIVO3tlN Bx5sG5OpL4cIvBM2NFAfme6RudjmQapmaGzvutQogc0V2h8IKATvRKHNJ5Yz0d1+1yQO wX9+J8r4agM5U4YkhABP5XGlapsalB/J9+z7wPB7FTcj/UhFRM2fo0x/UkFhr6h0dLfQ NiKTtedmYp8Vl4skLyBaTHDApY1zic40jLiRJZbWBSJz4xsCAKF0wR9+8wxpFu+UKI6g qkxA== X-Gm-Message-State: AGi0PuaXi4h/QuXEMLyTuGsyAlmrz0ftF4u490jmhxwD4aEnZmAnERHY XwZYFLFGiJsz3iyrjTNkr/XN+dPLmwvSEmw1UX1FtA== X-Google-Smtp-Source: APiQypJLvAUWLcTQEFcDXl741ghMQh6HgJvvwoa4QZ23Q9kqlt9enb3F4N7RPj7OUJ3ZLxhQ1AAkwK7WjhQgouVqVXc= X-Received: by 2002:a05:651c:85:: with SMTP id 5mr3034306ljq.60.1585164371470; Wed, 25 Mar 2020 12:26:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Wed, 25 Mar 2020 14:25:45 -0500 Message-ID: To: Justin Uberti Cc: Victor Vasiliev , Jonathan Rosenberg , "v3@ietf.org" Content-Type: multipart/alternative; boundary="00000000000045ad9405a1b2d752" Archived-At: Subject: Re: [V3] Thoughts on scope for ript X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 19:26:25 -0000 --00000000000045ad9405a1b2d752 Content-Type: text/plain; charset="UTF-8" Replying to Justin, after reading Victor's reply - thank you both for replying ... On Wed, Mar 25, 2020 at 11:55 AM Justin Uberti wrote: > > > On Wed, Mar 25, 2020 at 9:28 AM Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > >> This is interesting ... >> >> On Wed, Mar 25, 2020 at 10:31 AM Victor Vasiliev > 40google.com@dmarc.ietf.org> wrote: >> >>> I would like to second Justin's point here about the value of a >>> client-server RTP streaming by itself (e-f, though in-band c-d are also >>> valuable). There's a lot of value in the world where I can take an HTTP >>> URL to some endpoint in the cloud and give it to, say, an IoT camera device >>> to use as a realtime media sink, or pass it to an off-the-shelf streaming >>> library to show a realtime media source on screen. >>> >> >> I know most of my own concerns about RIPT media have started out with >> "this won't be as good as RTP for media", but what I've been getting from >> RIPT discussions is, that may not matter as much as I expected. >> >> For a use case like Victor's, great media quality would be great, but >> good enough media quality may be ... good enough. >> >> Am I putting words in the mouths of the proponents? >> >> Some applications may tolerate somewhat lower quality in fallback > scenarios, but I think we should be aiming for RTP performance with HTTP > ease of deployment. > I was actually hoping that wasn't the case, because ISTM that the question whether RTP performance over HTTP is possible/likely is going to suck up a LOT of the discussion time during the BOF ... Best, Spencer --00000000000045ad9405a1b2d752 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Replying to Justin, after reading Victor&= #39;s reply - thank you both for replying ...

On Wed, Mar 25, 2020 at 11:55 = AM Justin Uberti <juberti@google.c= om> wrote:


On Wed, Mar 25, 2020 at 9:28 AM Spe= ncer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
This is interesting ...

On Wed, Mar 25, 2020 at 10:31 AM Victor Vasil= iev <vasilvv=3D40google.com@dmarc.ietf.org> wrote:
I would like to second = Justin's point here about the value of a client-server RTP streaming by= itself (e-f, though in-band c-d are also valuable).=C2=A0 There's a lo= t of value in the world where I can take an HTTP URL to some endpoint in th= e cloud and give it to, say, an IoT camera device to use as a realtime medi= a sink, or pass it to an off-the-shelf streaming library to show a realtime= media source on screen.

I know most = of my own concerns about RIPT media have started out with "this won= 9;t be as good as RTP for media", but what I've been getting from = RIPT discussions is, that may not matter as much as I expected.=C2=A0
=

For a use case like Victor's, great media quality w= ould be great, but good enough media quality may be ... good enough.=C2=A0<= /div>

Am I putting words in the mouths of the proponents= ?

Some applications may t= olerate somewhat lower quality in fallback scenarios, but I think we should= be aiming for RTP performance with HTTP ease of deployment.

I was actually hoping that wasn't t= he case, because ISTM that the question whether RTP performance over HTTP i= s possible/likely is going to suck up a LOT of the discussion time during t= he BOF ...=C2=A0=C2=A0

Best,

<= div>Spencer
--00000000000045ad9405a1b2d752-- From nobody Wed Mar 25 12:31:56 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DF63A0B9B for ; Wed, 25 Mar 2020 12:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 UaMdIErf-U0Y for ; Wed, 25 Mar 2020 12:31:52 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 C83073A0BE1 for ; Wed, 25 Mar 2020 12:31:50 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id x82so2282031vsc.12 for ; Wed, 25 Mar 2020 12:31:50 -0700 (PDT) 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=3jAXsE4yaYOjzH1nl6Kua0rZMPSbLcVOmRjHKNXddYk=; b=QY5V3a2sZSUOV3keBlLQaHmHhG/C2yEgSIHkmqOXZLzOaCIKYGSc+dkYb7wainZNNM hwvuY+HTC7Me6UNY7lrxn9p+DTF5LzglIjpjUUJt92liSW5FXaqhx5wzCMKHAHKqrSvG D7HQllaGcPkBX+dfT0iqcG8HDK8z5UezlOMhYU5nEEMJ+YGm9LZUg8dI+KQ4PkUGIn+1 Ph+u8xKqXmVsu46lK+uWtH5A6ok1iR+rkqXj02esbP0Ne1y2PI0pH/Fe5KKQa22Pi2oz Tbb94y6Vz+8OOZAQqdug5tofnnaSbAJWXMOwWPVgA6PrHeUg+VTGEOVo4X7SBXmYaAnH F6zg== 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=3jAXsE4yaYOjzH1nl6Kua0rZMPSbLcVOmRjHKNXddYk=; b=mfdqmyrnt2phPg9iMSlMMw2R3Tywl7ftP6I37hKrKm80SKdWpeJ3IIJeKFN7TyZGRB QDXcYs4Wqqxt+aeYiTlLsAZw+c5sN3/gtb6opFojkmhDwewr9r+czT1FudM+B6aBIvUS qL2h6TWPFa1B4rcldSLYCOq0aLJpJl/fKtKezEWqtVbTr2o66sa/86NcfujGu8v97rXV 3vMvShDmgpw9FEN8MLDGWAY1PiGdCk55kAAEvyxkESYIz99XWNGxxO2l7DaE3xmOqQdZ aFsVtx2Yr1+Pymqf8dYNtbow0DjrKfekAF47YX9Vdwmb5iqdsP7F54JfAFreLSZtsjy0 rawQ== X-Gm-Message-State: ANhLgQ14/99XXlnGuXNnWn48qAquKHagBbdom1fZHuef94N0QxFuR1iJ XfgoUOPqvjRtclz+fnEuaJARh7zUmfa59vOpMRvQSA== X-Google-Smtp-Source: ADFU+vsQOGgOcp+mEHnID8DJNJ/QIe67gWGPjsTIBukk1X2W7wpDV/JmN8GbqIvXLzKysyapIFlkuIw6DTS2+78eGek= X-Received: by 2002:a67:2f83:: with SMTP id v125mr4000294vsv.100.1585164709068; Wed, 25 Mar 2020 12:31:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Wed, 25 Mar 2020 12:31:37 -0700 Message-ID: To: Spencer Dawkins at IETF Cc: Victor Vasiliev , Jonathan Rosenberg , "v3@ietf.org" Content-Type: multipart/alternative; boundary="000000000000658b8005a1b2eba7" Archived-At: Subject: Re: [V3] Thoughts on scope for ript X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 19:31:54 -0000 --000000000000658b8005a1b2eba7 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 25, 2020 at 12:26 PM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Replying to Justin, after reading Victor's reply - thank you both for > replying ... > > On Wed, Mar 25, 2020 at 11:55 AM Justin Uberti wrote: > >> >> >> On Wed, Mar 25, 2020 at 9:28 AM Spencer Dawkins at IETF < >> spencerdawkins.ietf@gmail.com> wrote: >> >>> This is interesting ... >>> >>> On Wed, Mar 25, 2020 at 10:31 AM Victor Vasiliev >> 40google.com@dmarc.ietf.org> wrote: >>> >>>> I would like to second Justin's point here about the value of a >>>> client-server RTP streaming by itself (e-f, though in-band c-d are also >>>> valuable). There's a lot of value in the world where I can take an HTTP >>>> URL to some endpoint in the cloud and give it to, say, an IoT camera device >>>> to use as a realtime media sink, or pass it to an off-the-shelf streaming >>>> library to show a realtime media source on screen. >>>> >>> >>> I know most of my own concerns about RIPT media have started out with >>> "this won't be as good as RTP for media", but what I've been getting from >>> RIPT discussions is, that may not matter as much as I expected. >>> >>> For a use case like Victor's, great media quality would be great, but >>> good enough media quality may be ... good enough. >>> >>> Am I putting words in the mouths of the proponents? >>> >>> Some applications may tolerate somewhat lower quality in fallback >> scenarios, but I think we should be aiming for RTP performance with HTTP >> ease of deployment. >> > > I was actually hoping that wasn't the case, because ISTM that the question > whether RTP performance over HTTP is possible/likely is going to suck up a > LOT of the discussion time during the BOF ... > To Eric's point, "H3 is not widely deployed yet, and so we should think about how we want things to look". I think it's entirely possible to achieve RTP performance over H3, and hopefully also have a reasonable fallback when only H2 is available. --000000000000658b8005a1b2eba7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 25, 2020 at 12:26 PM Spen= cer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Replying to Justin, after reading Victor's reply - thank you both f= or replying ...

On Wed, Mar 25, 2020 at 11:55 AM Justin Uberti <juberti@google.com>= wrote:


On Wed, Mar 25, 2020 at 9:28 AM Spencer Dawki= ns at IETF <spencerdawkins.ietf@gmail.com> wrote:
This = is interesting ...

On Wed, Mar 25, 2020 at 10:31 AM Victor Vasiliev <vasi= lvv=3D40go= ogle.com@dmarc.ietf.org> wrote:
I would like to second Justin's= point here about the value of a client-server RTP streaming by itself (e-f= , though in-band c-d are also valuable).=C2=A0 There's a lot of value i= n the world where I can take an HTTP URL to some endpoint in the cloud and = give it to, say, an IoT camera device to use as a realtime media sink, or p= ass it to an off-the-shelf streaming library to show a realtime media sourc= e on screen.

I know most of my own co= ncerns about RIPT media have started out with "this won't be as go= od as RTP for media", but what I've been getting from RIPT discuss= ions is, that may not matter as much as I expected.=C2=A0

For a use case like Victor's, great media quality would be grea= t, but good enough media quality may be ... good enough.=C2=A0
Am I putting words in the mouths of the proponents?
=
Some applications may tolerate some= what lower quality in fallback scenarios, but I think we should be aiming f= or RTP performance with HTTP ease of deployment.

I was actually hoping that wasn't the case, bec= ause ISTM that the question whether RTP performance over HTTP is possible/l= ikely is going to suck up a LOT of the discussion time during the BOF ...= =C2=A0=C2=A0

To Eric'= s point, "H3 is not widely deployed yet, and so we should think about = how we want things to look". I think it's entirely possible to ach= ieve RTP performance over H3, and hopefully also have a reasonable fallback= when only H2 is available.
--000000000000658b8005a1b2eba7-- From nobody Wed Mar 25 12:38:07 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB143A0A47 for ; Wed, 25 Mar 2020 12:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=steweorg.onmicrosoft.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 DEMiIhofJUJi for ; Wed, 25 Mar 2020 12:38:03 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2097.outbound.protection.outlook.com [40.107.223.97]) (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 027C33A0A34 for ; Wed, 25 Mar 2020 12:38:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SwMG906BpbHdWpxwoOjU2+Wy6OruREeuGntgOBnl6GvfLPFB+VeknFjzwVmRL1zxIjVoqDa/hA1harKKqUGjJ1v7hXWTxCqLbPfd/kgYs+G49S8G4qVXbwl4JYVpCvpP8ReLcnVtsob+mRm6dJYPX+X3Z80jIjKvnGWG+f+MJQ8esOihqwXwiqWvsDZV0a67yQvQsj28qXPrb/LS7nyiBpx0o6yiQ3MzlMoPn8CkVBcrbQ3zgr7CQCue7vTZnZ4B8CuzC6PyKmAmq7ofbAQgCYyF8cT7EBKwgpwrOqzQywhR9zzAtfkIfZ0uu7fsbGv4tcy6mR9z9itctLj4Dnynxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8153KDEkLgGYGs5T3/0igFSFfpTds7TIyva6OJX7IeA=; b=Vgi6lh1E5vD/JdDduMVDUbqGPPSYHcnX7eNnDNHIMji/BhqUmdORZ3ezrrDtKyBDOg1im11Vrh1yRWxsk5qv2P181L2i2EtAF+11Fk6GmbkEQ/SMIS0loUKub3aaFNdAqoQLkjbuL1uAyefTVAEJoZ2I2y9tu4iCAtNjHtNJeahl4ktYIr0HrFI6VUVsPucwcH0uEHaCemDt2UrKXIENS/BKYchqqgYkWrkWZsgSKycvkZP3i5l7RsmS6ZdVTszcDamS+SDaw/SE9Yhu3Soe2ALICiHLmrr33j+Oj1VA0lEcKFoxXIWqYeKraV4UY15juvLGp+tR0IDoztmT94l/9g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=stewe.org; dmarc=pass action=none header.from=stewe.org; dkim=pass header.d=stewe.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=steweorg.onmicrosoft.com; s=selector2-steweorg-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8153KDEkLgGYGs5T3/0igFSFfpTds7TIyva6OJX7IeA=; b=o1L1+/po/1AFDGz1uP5KcZqG6tM/qfg+RP9KLwhlQLLOThW6HCv1CVPt74g5J4PnT+PzI0k3QTSK8Gxg0CNLgq1Drxa7c5aVXfYcXFOjtISwrRkc7f6DKMQj+CvdlQBQV/uG9AnN7M0+CzvpDP3In5p3LAU3SN6REiD97lvV6Go= Received: from DM6PR17MB3036.namprd17.prod.outlook.com (2603:10b6:5:12e::14) by DM6PR17MB3163.namprd17.prod.outlook.com (2603:10b6:5:192::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.22; Wed, 25 Mar 2020 19:37:59 +0000 Received: from DM6PR17MB3036.namprd17.prod.outlook.com ([fe80::24b9:a21:fc:63df]) by DM6PR17MB3036.namprd17.prod.outlook.com ([fe80::24b9:a21:fc:63df%6]) with mapi id 15.20.2835.023; Wed, 25 Mar 2020 19:37:59 +0000 From: Stephan Wenger To: Justin Uberti , Spencer Dawkins at IETF CC: Victor Vasiliev , Jonathan Rosenberg , "v3@ietf.org" Thread-Topic: [V3] Thoughts on scope for ript Thread-Index: AdYBHf0Yy+O2W8g+RMGhiSdyDOSXPQAF87QAAGEjpwAAAf5egAAA9ukAAAU/pIAAADRzgP//jG6A Date: Wed, 25 Mar 2020 19:37:59 +0000 Message-ID: References: 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=stewe@stewe.org; x-originating-ip: [67.161.32.179] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f45ea189-76d5-47a3-ad7f-08d7d0f4069e x-ms-traffictypediagnostic: DM6PR17MB3163: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1284; x-forefront-prvs: 0353563E2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39830400003)(136003)(396003)(366004)(86362001)(4326008)(2616005)(36756003)(6512007)(81166006)(81156014)(8936002)(6486002)(8676002)(508600001)(53546011)(2906002)(316002)(66446008)(64756008)(66556008)(66476007)(26005)(76116006)(6506007)(33656002)(91956017)(110136005)(186003)(71200400001)(54906003)(5660300002)(66946007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR17MB3163; H:DM6PR17MB3036.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5ghdIM5zByCS2BMJuGU2AC5NvfJ49V/GLmAI2HE/+Co6A4bEPw3Q3UT7UAzGzjeFGU6QFPADOvOi1l+DUsoYnlxm4fRXI28d284Ujf9GVUuSCSZG3SE5eNTdhbmWHMHXo9i3v6qSd4QDThLByCUntk5eqzt56TLvgb0HZWxOV/a6QuK/T3Zx7mUtffYSglat6V9VXa0uQucomQLKds83HO54CXIzvaPPGpqiIwecn1AmEdL9/bSxUvuFoqAFfcC8AqYVm/pe5TeQAejIc3E/ZMT7gL/e81hW52HA46v7oX9WlGWzHhccRRDoJBVKvWOLa6xiDNzSA9lNtugAaNhGiQOjBLkP6h0kXNhbiPYMNCvTlNkydxFz3ysquh2SSfmd4YyAXcAz1ABQbIMyZZ/IaikzffACj42f87X2/PpsLbuh38HdnhVsxRlV7eeiuCBE x-ms-exchange-antispam-messagedata: AbfjbJMmz8Q4YRI6pkHolaBvQUfuDh5rUfw4EXLPftdLquzAQWA2tIuL4iko440CjNeWu2V73EpE+bdmcUxpVVhCXohjWSbgPJaVpA1lwo9/0lzGuNLlrXpKwWGOgjdb6ftrdPPYxkNxPHlA1JBUWw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_A45D04C3D640485DBAF4611DBE41DBAAsteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-Network-Message-Id: f45ea189-76d5-47a3-ad7f-08d7d0f4069e X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2020 19:37:59.6915 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7fZEcvo5atMIYqMh0zrxYW023oDQMJPLjI5qCVEkXPsMlKKw1PkWO7wK9ptkLqQl X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB3163 Archived-At: Subject: Re: [V3] Thoughts on scope for ript X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 19:38:05 -0000 --_000_A45D04C3D640485DBAF4611DBE41DBAAsteweorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLCBhbGw6DQoNCkZyb206IFYzIDx2My1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhh bGYgb2YgSnVzdGluIFViZXJ0aSA8anViZXJ0aT00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+ DQpEYXRlOiBXZWRuZXNkYXksIE1hcmNoIDI1LCAyMDIwIGF0IDEyOjMyDQpUbzogU3BlbmNlciBE YXdraW5zIGF0IElFVEYgPHNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPg0KQ2M6IFZpY3Rv ciBWYXNpbGlldiA8dmFzaWx2dkBnb29nbGUuY29tPiwgSm9uYXRoYW4gUm9zZW5iZXJnIDxqZHJv c2VuQGZpdmU5LmNvbT4sICJ2M0BpZXRmLm9yZyIgPHYzQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtWM10gVGhvdWdodHMgb24gc2NvcGUgZm9yIHJpcHQNCg0KDQoNCk9uIFdlZCwgTWFyIDI1LCAy MDIwIGF0IDEyOjI2IFBNIFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIDxzcGVuY2VyZGF3a2lucy5p ZXRmQGdtYWlsLmNvbTxtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20+PiB3cm90 ZToNClJlcGx5aW5nIHRvIEp1c3RpbiwgYWZ0ZXIgcmVhZGluZyBWaWN0b3IncyByZXBseSAtIHRo YW5rIHlvdSBib3RoIGZvciByZXBseWluZyAuLi4NCg0KT24gV2VkLCBNYXIgMjUsIDIwMjAgYXQg MTE6NTUgQU0gSnVzdGluIFViZXJ0aSA8anViZXJ0aUBnb29nbGUuY29tPG1haWx0bzpqdWJlcnRp QGdvb2dsZS5jb20+PiB3cm90ZToNCg0KDQpPbiBXZWQsIE1hciAyNSwgMjAyMCBhdCA5OjI4IEFN IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIDxzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbTxt YWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNClRoaXMgaXMgaW50 ZXJlc3RpbmcgLi4uDQoNCk9uIFdlZCwgTWFyIDI1LCAyMDIwIGF0IDEwOjMxIEFNIFZpY3RvciBW YXNpbGlldiA8dmFzaWx2dj00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwZ29v Z2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KSSB3b3VsZCBsaWtlIHRvIHNlY29uZCBK dXN0aW4ncyBwb2ludCBoZXJlIGFib3V0IHRoZSB2YWx1ZSBvZiBhIGNsaWVudC1zZXJ2ZXIgUlRQ IHN0cmVhbWluZyBieSBpdHNlbGYgKGUtZiwgdGhvdWdoIGluLWJhbmQgYy1kIGFyZSBhbHNvIHZh bHVhYmxlKS4gIFRoZXJlJ3MgYSBsb3Qgb2YgdmFsdWUgaW4gdGhlIHdvcmxkIHdoZXJlIEkgY2Fu IHRha2UgYW4gSFRUUCBVUkwgdG8gc29tZSBlbmRwb2ludCBpbiB0aGUgY2xvdWQgYW5kIGdpdmUg aXQgdG8sIHNheSwgYW4gSW9UIGNhbWVyYSBkZXZpY2UgdG8gdXNlIGFzIGEgcmVhbHRpbWUgbWVk aWEgc2luaywgb3IgcGFzcyBpdCB0byBhbiBvZmYtdGhlLXNoZWxmIHN0cmVhbWluZyBsaWJyYXJ5 IHRvIHNob3cgYSByZWFsdGltZSBtZWRpYSBzb3VyY2Ugb24gc2NyZWVuLg0KDQpJIGtub3cgbW9z dCBvZiBteSBvd24gY29uY2VybnMgYWJvdXQgUklQVCBtZWRpYSBoYXZlIHN0YXJ0ZWQgb3V0IHdp dGggInRoaXMgd29uJ3QgYmUgYXMgZ29vZCBhcyBSVFAgZm9yIG1lZGlhIiwgYnV0IHdoYXQgSSd2 ZSBiZWVuIGdldHRpbmcgZnJvbSBSSVBUIGRpc2N1c3Npb25zIGlzLCB0aGF0IG1heSBub3QgbWF0 dGVyIGFzIG11Y2ggYXMgSSBleHBlY3RlZC4NCg0KRm9yIGEgdXNlIGNhc2UgbGlrZSBWaWN0b3In cywgZ3JlYXQgbWVkaWEgcXVhbGl0eSB3b3VsZCBiZSBncmVhdCwgYnV0IGdvb2QgZW5vdWdoIG1l ZGlhIHF1YWxpdHkgbWF5IGJlIC4uLiBnb29kIGVub3VnaC4NCg0KQW0gSSBwdXR0aW5nIHdvcmRz IGluIHRoZSBtb3V0aHMgb2YgdGhlIHByb3BvbmVudHM/DQoNClNvbWUgYXBwbGljYXRpb25zIG1h eSB0b2xlcmF0ZSBzb21ld2hhdCBsb3dlciBxdWFsaXR5IGluIGZhbGxiYWNrIHNjZW5hcmlvcywg YnV0IEkgdGhpbmsgd2Ugc2hvdWxkIGJlIGFpbWluZyBmb3IgUlRQIHBlcmZvcm1hbmNlIHdpdGgg SFRUUCBlYXNlIG9mIGRlcGxveW1lbnQuDQoNCkkgd2FzIGFjdHVhbGx5IGhvcGluZyB0aGF0IHdh c24ndCB0aGUgY2FzZSwgYmVjYXVzZSBJU1RNIHRoYXQgdGhlIHF1ZXN0aW9uIHdoZXRoZXIgUlRQ IHBlcmZvcm1hbmNlIG92ZXIgSFRUUCBpcyBwb3NzaWJsZS9saWtlbHkgaXMgZ29pbmcgdG8gc3Vj ayB1cCBhIExPVCBvZiB0aGUgZGlzY3Vzc2lvbiB0aW1lIGR1cmluZyB0aGUgQk9GIC4uLg0KDQpU byBFcmljJ3MgcG9pbnQsICJIMyBpcyBub3Qgd2lkZWx5IGRlcGxveWVkIHlldCwgYW5kIHNvIHdl IHNob3VsZCB0aGluayBhYm91dCBob3cgd2Ugd2FudCB0aGluZ3MgdG8gbG9vayIuIEkgdGhpbmsg aXQncyBlbnRpcmVseSBwb3NzaWJsZSB0byBhY2hpZXZlIFJUUCBwZXJmb3JtYW5jZSBvdmVyIEgz LCBhbmQgaG9wZWZ1bGx5IGFsc28gaGF2ZSBhIHJlYXNvbmFibGUgZmFsbGJhY2sgd2hlbiBvbmx5 IEgyIGlzIGF2YWlsYWJsZS4NCg0KW1N0ZXBoYW5dOiBtYW55IHZpZGVvIGNvbmZlcmVuY2luZyB0 ZWNobm9sb2dpZXMgKGluY2x1ZGluZyBWaWR5bywgWm9vbSksIGhhdmUgcHJldmlvdXNseSwgb3Ig YXJlIGN1cnJlbnRseSBzdXBwb3J0aW5nIGh0dHAtYmFzZWQgbWVkaWEgdHJhbnNwb3J0LCBvZnRl biBmb3IgeWVhcnMgb3IgZXZlbiBkZWNhZGVzLiAgVGhleSBhcmUgYWxtb3N0IG5ldmVyIGVuYWJs ZWQgYnkgYW55IHByb2Zlc3Npb25hbCBkZXBsb3llciwgYmVjYXVzZSB0aGUgcmVzdWx0aW5nIFFv UyBpcyB1c2VyLXBlcmNlaXZlZCBhcyBzbyBiYWQgdGhhdCB0aGUgbWFya2V0aW5nIGd1eXMgZGVj aWRlZCB0aGF0IG9mZmVyaW5nIG5vIHZpZGVvL3ZvaWNlIChhbmQgaW5zdGVhZCBtYWtlIHBlb3Bs ZSBwaWNrIG9mIHRoZSBwaG9uZSkgaXMgYmV0dGVyIGZvciBwcm9kdWN0IHJlcHV0YXRpb24gdGhh biBvZmZlciB0aGUgZGVncmFkZWQgUW9TLg0KRG8gYW55IG9mIHlvdSBndXlzIGhhdmUgaGFyZCBu dW1iZXJzIHdoYXQgc29ydCBvZiBkZWxheSBoMy1iYXNlZCB0cmFuc3BvcnQgY2FuIGFjaGlldmUg b24gdG9kYXnigJlzIGluZnJhc3RydWN0dXJlPw0KDQo= --_000_A45D04C3D640485DBAF4611DBE41DBAAsteweorg_ Content-Type: text/html; charset="utf-8" Content-ID: <3159FCC90338134BB26D676CAA150BBE@namprd17.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SGkgSnVzdGluLCBhbGw6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj5WMyAmbHQ7djMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxm IG9mIEp1c3RpbiBVYmVydGkgJmx0O2p1YmVydGk9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3Jn Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIE1hcmNoIDI1LCAyMDIwIGF0IDEyOjMy PGJyPg0KPGI+VG86IDwvYj5TcGVuY2VyIERhd2tpbnMgYXQgSUVURiAmbHQ7c3BlbmNlcmRhd2tp bnMuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5WaWN0b3IgVmFzaWxpZXYgJmx0 O3Zhc2lsdnZAZ29vZ2xlLmNvbSZndDssIEpvbmF0aGFuIFJvc2VuYmVyZyAmbHQ7amRyb3NlbkBm aXZlOS5jb20mZ3Q7LCAmcXVvdDt2M0BpZXRmLm9yZyZxdW90OyAmbHQ7djNAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbVjNdIFRob3VnaHRzIG9uIHNjb3BlIGZvciByaXB0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBXZWQsIE1hciAyNSwgMjAyMCBhdCAxMjoyNiBQTSBTcGVuY2VyIERhd2tpbnMg YXQgSUVURiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVwbHlpbmcgdG8gSnVzdGluLCBhZnRlciByZWFkaW5nIFZp Y3RvcidzIHJlcGx5IC0gdGhhbmsgeW91IGJvdGggZm9yIHJlcGx5aW5nIC4uLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBNYXIgMjUsIDIwMjAg YXQgMTE6NTUgQU0gSnVzdGluIFViZXJ0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp1YmVydGlAZ29v Z2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmp1YmVydGlAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFdlZCwgTWFyIDI1LCAyMDIwIGF0IDk6MjggQU0gU3BlbmNlciBEYXdr aW5zIGF0IElFVEYgJmx0OzxhIGhyZWY9Im1haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgaW50ZXJlc3RpbmcgLi4uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1hciAyNSwgMjAy MCBhdCAxMDozMSBBTSBWaWN0b3IgVmFzaWxpZXYgJmx0O3Zhc2lsdnY9PGEgaHJlZj0ibWFpbHRv OjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwZ29vZ2xlLmNv bUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgbGlrZSB0byBz ZWNvbmQgSnVzdGluJ3MgcG9pbnQgaGVyZSBhYm91dCB0aGUgdmFsdWUgb2YgYSBjbGllbnQtc2Vy dmVyIFJUUCBzdHJlYW1pbmcgYnkgaXRzZWxmIChlLWYsIHRob3VnaCBpbi1iYW5kIGMtZCBhcmUg YWxzbyB2YWx1YWJsZSkuJm5ic3A7IFRoZXJlJ3MgYSBsb3Qgb2YgdmFsdWUgaW4gdGhlIHdvcmxk IHdoZXJlIEkgY2FuIHRha2UgYW4gSFRUUCBVUkwgdG8gc29tZSBlbmRwb2ludCBpbiB0aGUNCiBj bG91ZCBhbmQgZ2l2ZSBpdCB0bywgc2F5LCBhbiBJb1QgY2FtZXJhIGRldmljZSB0byB1c2UgYXMg YSByZWFsdGltZSBtZWRpYSBzaW5rLCBvciBwYXNzIGl0IHRvIGFuIG9mZi10aGUtc2hlbGYgc3Ry ZWFtaW5nIGxpYnJhcnkgdG8gc2hvdyBhIHJlYWx0aW1lIG1lZGlhIHNvdXJjZSBvbiBzY3JlZW4u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkga25vdyBtb3N0IG9mIG15IG93biBjb25jZXJucyBhYm91dCBSSVBUIG1l ZGlhIGhhdmUgc3RhcnRlZCBvdXQgd2l0aCAmcXVvdDt0aGlzIHdvbid0IGJlIGFzIGdvb2QgYXMg UlRQIGZvciBtZWRpYSZxdW90OywgYnV0IHdoYXQgSSd2ZSBiZWVuIGdldHRpbmcgZnJvbSBSSVBU IGRpc2N1c3Npb25zIGlzLCB0aGF0IG1heSBub3QgbWF0dGVyIGFzIG11Y2ggYXMgSSBleHBlY3Rl ZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Rm9yIGEgdXNlIGNhc2UgbGlrZSBWaWN0b3IncywgZ3JlYXQgbWVkaWEgcXVhbGl0eSB3 b3VsZCBiZSBncmVhdCwgYnV0IGdvb2QgZW5vdWdoIG1lZGlhIHF1YWxpdHkgbWF5IGJlIC4uLiBn b29kIGVub3VnaC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QW0gSSBwdXR0aW5nIHdvcmRzIGluIHRoZSBtb3V0aHMgb2YgdGhlIHBy b3BvbmVudHM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21lIGFwcGxpY2F0aW9ucyBt YXkgdG9sZXJhdGUgc29tZXdoYXQgbG93ZXIgcXVhbGl0eSBpbiBmYWxsYmFjayBzY2VuYXJpb3Ms IGJ1dCBJIHRoaW5rIHdlIHNob3VsZCBiZSBhaW1pbmcgZm9yIFJUUCBwZXJmb3JtYW5jZSB3aXRo IEhUVFAgZWFzZSBvZiBkZXBsb3ltZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3 YXMgYWN0dWFsbHkgaG9waW5nIHRoYXQgd2Fzbid0IHRoZSBjYXNlLCBiZWNhdXNlIElTVE0gdGhh dCB0aGUgcXVlc3Rpb24gd2hldGhlciBSVFAgcGVyZm9ybWFuY2Ugb3ZlciBIVFRQIGlzIHBvc3Np YmxlL2xpa2VseSBpcyBnb2luZyB0byBzdWNrIHVwIGEgTE9UIG9mIHRoZSBkaXNjdXNzaW9uIHRp bWUgZHVyaW5nIHRoZSBCT0YgLi4uJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UbyBFcmljJ3MgcG9pbnQsICZxdW90O0gzIGlzIG5vdCB3aWRlbHkgZGVwbG95ZWQgeWV0 LCBhbmQgc28gd2Ugc2hvdWxkIHRoaW5rIGFib3V0IGhvdyB3ZSB3YW50IHRoaW5ncyB0byBsb29r JnF1b3Q7LiBJIHRoaW5rIGl0J3MgZW50aXJlbHkgcG9zc2libGUgdG8gYWNoaWV2ZSBSVFAgcGVy Zm9ybWFuY2Ugb3ZlciBIMywgYW5kIGhvcGVmdWxseSBhbHNvIGhhdmUgYSByZWFzb25hYmxlIGZh bGxiYWNrIHdoZW4gb25seSBIMiBpcw0KIGF2YWlsYWJsZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+W1N0ZXBoYW5dOiBtYW55IHZpZGVvIGNvbmZlcmVuY2luZyB0ZWNobm9sb2dpZXMgKGluY2x1 ZGluZyBWaWR5bywgWm9vbSksIGhhdmUgcHJldmlvdXNseSwgb3IgYXJlIGN1cnJlbnRseSBzdXBw b3J0aW5nIGh0dHAtYmFzZWQgbWVkaWEgdHJhbnNwb3J0LCBvZnRlbiBmb3IgeWVhcnMgb3IgZXZl biBkZWNhZGVzLiZuYnNwOyBUaGV5IGFyZSBhbG1vc3QgbmV2ZXIgZW5hYmxlZCBieSBhbnkgcHJv ZmVzc2lvbmFsIGRlcGxveWVyLA0KIGJlY2F1c2UgdGhlIHJlc3VsdGluZyBRb1MgaXMgdXNlci1w ZXJjZWl2ZWQgYXMgc28gYmFkIHRoYXQgdGhlIG1hcmtldGluZyBndXlzIGRlY2lkZWQgdGhhdCBv ZmZlcmluZyBubyB2aWRlby92b2ljZSAoYW5kIGluc3RlYWQgbWFrZSBwZW9wbGUgcGljayBvZiB0 aGUgcGhvbmUpIGlzIGJldHRlciBmb3IgcHJvZHVjdCByZXB1dGF0aW9uIHRoYW4gb2ZmZXIgdGhl IGRlZ3JhZGVkIFFvUy4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RG8gYW55IG9mIHlvdSBndXlzIGhhdmUgaGFyZCBudW1iZXJzIHdoYXQgc29ydCBvZiBkZWxh eSBoMy1iYXNlZCB0cmFuc3BvcnQgY2FuIGFjaGlldmUgb24gdG9kYXnigJlzIGluZnJhc3RydWN0 dXJlPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_A45D04C3D640485DBAF4611DBE41DBAAsteweorg_-- From nobody Wed Mar 25 12:50:21 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823693A0CBC for ; Wed, 25 Mar 2020 12:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 dSD1tlhAY5jN for ; Wed, 25 Mar 2020 12:50:08 -0700 (PDT) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (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 686EA3A0CD9 for ; Wed, 25 Mar 2020 12:50:08 -0700 (PDT) Received: by mail-vk1-xa2c.google.com with SMTP id s194so1032329vkb.11 for ; Wed, 25 Mar 2020 12:50:08 -0700 (PDT) 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=PA17Z91vO0s0WjmpOGpa53Tbegd6mQoSHZIEbt2jmKQ=; b=VoR/u0ut6P+ZHzFPLiM3BxfEf6DP6eW2qYtjVf4H46cZ8IOgf2mg8717CZ/ZwcbXu9 6qtSlnCkOFKEClWjEciVilDAOutSAAZKTLqedlmbXeWxJ/L+zzCh1ohchpBLqyMkdsS9 iIairlvH+d/CfzFAJUnHeNNR09WnKXbw3AuYYvxnTMFDS4qM+BSnhNSFqkAGqkHMHtte rIJXndT3zK9uT3pujBwWtp2Zonh5ub/QC4vw6jsS77sBQt17EvuT6w1tu9kez/HMojvM xEo5U7CczpcGmQzGBYzUWtOYNbBoYhpgkr/guCCQfF4yltDpc2iBXJEWzKaoReqRH5E6 4LFQ== 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=PA17Z91vO0s0WjmpOGpa53Tbegd6mQoSHZIEbt2jmKQ=; b=aPPIdiLvs/V/lTZl/E2ctpr8guv7aIPK0e/4uAe1c/ga8ElaGBoNo2GiLs2cuQ5s3y Yr7BkccbzqZkkNn9pj+zwvTM75C+pz/V013Cmqxt3C54jGwMC8Vomvbuoq5Awl7qkl5Q 7ojL2rhhO428sNYSMqccYHTVWp2Rbm4DqRDcO+e5pSM5g1ippAYLghlQi09Lh8bYaegx 7Mhu0fsX/jsf35siMvK3flT5ll8MA+qoEi7JABTcFxstdzANfLJpSsj48zFKQSuqXtJw 2+i4rLAy5azgDhgnTX3yJOzdwDJL5mhDpXrG/uWH7wreWsLvYR3rOytZHBaLk2dNmsi6 72ow== X-Gm-Message-State: ANhLgQ1oW84k9Rj7gzKjdgp5MDJNQxBkgBTN33Nm371jTwPI7FYWxc3p 6SNaVVljPMzgb7MvnZJCjvNVpVj+Cd90CF2Xx5H2bg== X-Google-Smtp-Source: ADFU+vv/rPj90aaEpjZ5yH8rQlS3UZHxT1G03TLPei+yl2q0AFm148KSFTzx8TLU6BwsX5OBA4rqCquWbmOWN3ZC8/4= X-Received: by 2002:a1f:bf95:: with SMTP id p143mr3882455vkf.29.1585165806934; Wed, 25 Mar 2020 12:50:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Wed, 25 Mar 2020 12:49:55 -0700 Message-ID: To: Stephan Wenger Cc: Spencer Dawkins at IETF , Victor Vasiliev , Jonathan Rosenberg , "v3@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d5ab4605a1b32cf9" Archived-At: Subject: Re: [V3] Thoughts on scope for ript X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 19:50:20 -0000 --000000000000d5ab4605a1b32cf9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 25, 2020 at 12:38 PM Stephan Wenger wrote: > Hi Justin, all: > > > > *From: *V3 on behalf of Justin Uberti 40google.com@dmarc.ietf.org> > *Date: *Wednesday, March 25, 2020 at 12:32 > *To: *Spencer Dawkins at IETF > *Cc: *Victor Vasiliev , Jonathan Rosenberg < > jdrosen@five9.com>, "v3@ietf.org" > *Subject: *Re: [V3] Thoughts on scope for ript > > > > > > > > On Wed, Mar 25, 2020 at 12:26 PM Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > Replying to Justin, after reading Victor's reply - thank you both for > replying ... > > > > On Wed, Mar 25, 2020 at 11:55 AM Justin Uberti wrote= : > > > > > > On Wed, Mar 25, 2020 at 9:28 AM Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > This is interesting ... > > > > On Wed, Mar 25, 2020 at 10:31 AM Victor Vasiliev 40google.com@dmarc.ietf.org> wrote: > > I would like to second Justin's point here about the value of a > client-server RTP streaming by itself (e-f, though in-band c-d are also > valuable). There's a lot of value in the world where I can take an HTTP > URL to some endpoint in the cloud and give it to, say, an IoT camera devi= ce > to use as a realtime media sink, or pass it to an off-the-shelf streaming > library to show a realtime media source on screen. > > > > I know most of my own concerns about RIPT media have started out with > "this won't be as good as RTP for media", but what I've been getting from > RIPT discussions is, that may not matter as much as I expected. > > > > For a use case like Victor's, great media quality would be great, but goo= d > enough media quality may be ... good enough. > > > > Am I putting words in the mouths of the proponents? > > > > Some applications may tolerate somewhat lower quality in fallback > scenarios, but I think we should be aiming for RTP performance with HTTP > ease of deployment. > > > > I was actually hoping that wasn't the case, because ISTM that the questio= n > whether RTP performance over HTTP is possible/likely is going to suck up = a > LOT of the discussion time during the BOF ... > > > > To Eric's point, "H3 is not widely deployed yet, and so we should think > about how we want things to look". I think it's entirely possible to > achieve RTP performance over H3, and hopefully also have a reasonable > fallback when only H2 is available. > > > > [Stephan]: many video conferencing technologies (including Vidyo, Zoom), > have previously, or are currently supporting http-based media transport, > often for years or even decades. They are almost never enabled by any > professional deployer, because the resulting QoS is user-perceived as so > bad that the marketing guys decided that offering no video/voice (and > instead make people pick of the phone) is better for product reputation > than offer the degraded QoS. > > Do any of you guys have hard numbers what sort of delay h3-based transpor= t > can achieve on today=E2=80=99s infrastructure? > With H3 we have lots of options; there are lots of details to work through here but given that the substrate is QUIC there is no theoretical reason why RTP performance isn't possible. Regarding HTTP media transport in existing products (i.e., non-H3), you are correct that there are indeed limitations and as such providers do what they can to avoid this option, but it is nowhere near as grim as you make it out to be. Recall that the first web version of Zoom exclusively used websockets for transport . > --000000000000d5ab4605a1b32cf9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 25, 2020 at 12:38 PM Step= han Wenger <stewe@stewe.org> w= rote:

Hi Justin, all:

=C2=A0

From: = V3 <v3-bounces@ietf.org> on b= ehalf of Justin Uberti <juberti=3D40google.com@dmarc.ietf.org>
Date: Wednesday, March 25, 2020 at 12:32
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: Victor Vasiliev <vasilvv@google.com>, Jonathan Rosenberg <jdrosen@five9.com>, "= ;v3@ietf.org" <= ;v3@ietf.org>
Subject: Re: [V3] Thoughts on scope for ript

=C2=A0

=C2=A0

=C2=A0

On Wed, Mar 25, 2020 at 12:26 PM Spencer Dawkins at = IETF <spencerdawkins.ietf@gmail.com> wrote:

Replying to Justin, after reading Victor's reply= - thank you both for replying ...

=C2=A0

On Wed, Mar 25, 2020 at 11:55 AM Justin Uberti <<= a href=3D"mailto:juberti@google.com" target=3D"_blank">juberti@google.com> wrote:

=C2=A0

=C2=A0

On Wed, Mar 25, 2020 at 9:28 AM Spencer Dawkins at I= ETF <= spencerdawkins.ietf@gmail.com> wrote:

This is interesting ...

=C2=A0

On Wed, Mar 25, 2020 at 10:31 AM Victor Vasiliev <= ;vasilvv=3D40google.com@dmarc.ietf.org> wrote:

I would like to second Justin's point here about= the value of a client-server RTP streaming by itself (e-f, though in-band = c-d are also valuable).=C2=A0 There's a lot of value in the world where= I can take an HTTP URL to some endpoint in the cloud and give it to, say, an IoT camera device to use as a realtime media= sink, or pass it to an off-the-shelf streaming library to show a realtime = media source on screen.

=C2=A0

I know most of my own concerns about RIPT media have= started out with "this won't be as good as RTP for media", b= ut what I've been getting from RIPT discussions is, that may not matter= as much as I expected.=C2=A0

=C2=A0

For a use case like Victor's, great media qualit= y would be great, but good enough media quality may be ... good enough.=C2= =A0

=C2=A0

Am I putting words in the mouths of the proponents?<= u>

=C2=A0

Some applications may tolerate somewhat lower qualit= y in fallback scenarios, but I think we should be aiming for RTP performanc= e with HTTP ease of deployment.

=C2=A0

I was actually hoping that wasn't the case, beca= use ISTM that the question whether RTP performance over HTTP is possible/li= kely is going to suck up a LOT of the discussion time during the BOF ...=C2= =A0=C2=A0

=C2=A0

To Eric's point, "H3 is not widely deployed= yet, and so we should think about how we want things to look". I thin= k it's entirely possible to achieve RTP performance over H3, and hopefu= lly also have a reasonable fallback when only H2 is available.

=C2=A0

[Stephan]: many video conferencing technologies (inc= luding Vidyo, Zoom), have previously, or are currently supporting http-base= d media transport, often for years or even decades.=C2=A0 They are almost n= ever enabled by any professional deployer, because the resulting QoS is user-perceived as so bad that the marketing g= uys decided that offering no video/voice (and instead make people pick of t= he phone) is better for product reputation than offer the degraded QoS.=C2= =A0

Do any of you guys have hard numbers what sort of de= lay h3-based transport can achieve on today=E2=80=99s infrastructure?


With H3 we hav= e lots of options; there are lots of details to work through here but given= that the substrate is QUIC there is no theoretical reason why RTP performa= nce isn't possible.

Regarding HTTP media trans= port in existing products (i.e., non-H3), you are correct that there are in= deed limitations and as such providers do what they can to avoid this optio= n, but it is nowhere near as grim as you make it out to be. Recall that the= first web version of Zoom exclusively=C2=A0used websockets for transport.
--000000000000d5ab4605a1b32cf9-- From nobody Wed Mar 25 12:57:53 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6ED3A0CB9 for ; Wed, 25 Mar 2020 12:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 e7FCjkEo-9OP for ; Wed, 25 Mar 2020 12:57:47 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 9EBF23A0E93 for ; Wed, 25 Mar 2020 12:57:00 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id j11so2891981lfg.4 for ; Wed, 25 Mar 2020 12:57:00 -0700 (PDT) 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=lI1voLm2ESEEcmRmWNYstQJawd1Gq0HiwJZmbPteTMU=; b=dj49SWum5bRjBVkzvpWmxrBOTA4XLvB7wt/np1cjBoZq2v4z0bzIpBLYoo5g26RlRm +yu4lcHD0VyKAAYxFySX/ztLk3esdLNTv2RG28A9wxIbF+NsqI7sGa7zFhbYshlkD5DF s5xLaBZcpyL0Gvbt5BWOgAhdu/VSJc42YCQHJ85nPXvxzBXGjqW7vnhpdI+YtEkUYoCu 7wbLNd71PiP/UyLav7K3RK+i2agyWH2SdtYgJ8/aWAtJKB809cnZ23j3vu0Suc507OV5 K3Q0q05J8s/3ySZm3j18zf3Zn1XhC3vsXNr0XCRvRZV7HXdbw3+KiA0BVmkReMpiXQM+ OAzw== 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=lI1voLm2ESEEcmRmWNYstQJawd1Gq0HiwJZmbPteTMU=; b=i3lQhpT0XwOIHxYPwJNeWIi+uo5/DV9fRiZ6uegAf+SWq05sCmhSX+b5Ig/qzP9EcH VQ64AF1TvoAVlbqpdDJyTU5+uwoLPh+jvrofsB8WeKjpWICpn9SGutuk71Wt4A+nfG9n zjfswK/tlM4zjTKF9KSStFbbc4uNt4h0U9xMyPM3uzC5Hba9nEtRwWl/++Kjzg9fKXYX 3LRvNKwAJzb52e7jpAERFTnmO97YL1PU9++QZkWoXN9QNjaTEGCNqEgq8wskiaCDSbZ2 pb3HSngeJPhBaxEnAsubmXotZbZvO/4dfQERhYjNyd/p2QmzGYQ13BUS3Wz971rteb07 WzNg== X-Gm-Message-State: ANhLgQ3siNSVGrCIqZ3GlrU+8h5d4GRWoBkg+LmwIUt51uBmJ5NWuDTy eP2+gvujMUKcOSAxkgDWtbGB3G8PZoK7Fmk2FVTQSKJbhEM= X-Google-Smtp-Source: ADFU+vtTorH0kISZpQP6REgdrsF8G/N/1mzaQbjykxYhTmTl7Dk6jHoasabTX3xMU0vAg9vfrKatHWxy0o6RLeOWlek= X-Received: by 2002:ac2:4291:: with SMTP id m17mr3346072lfh.201.1585166216470; Wed, 25 Mar 2020 12:56:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Wed, 25 Mar 2020 12:56:20 -0700 Message-ID: To: Justin Uberti Cc: Stephan Wenger , Victor Vasiliev , Jonathan Rosenberg , "v3@ietf.org" , Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary="0000000000003e346b05a1b34503" Archived-At: Subject: Re: [V3] Thoughts on scope for ript X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 19:57:53 -0000 --0000000000003e346b05a1b34503 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 25, 2020 at 12:52 PM Justin Uberti wrote: > > > On Wed, Mar 25, 2020 at 12:38 PM Stephan Wenger wrote: > >> Hi Justin, all: >> >> >> >> *From: *V3 on behalf of Justin Uberti > 40google.com@dmarc.ietf.org> >> *Date: *Wednesday, March 25, 2020 at 12:32 >> *To: *Spencer Dawkins at IETF >> *Cc: *Victor Vasiliev , Jonathan Rosenberg < >> jdrosen@five9.com>, "v3@ietf.org" >> *Subject: *Re: [V3] Thoughts on scope for ript >> >> >> >> >> >> >> >> On Wed, Mar 25, 2020 at 12:26 PM Spencer Dawkins at IETF < >> spencerdawkins.ietf@gmail.com> wrote: >> >> Replying to Justin, after reading Victor's reply - thank you both for >> replying ... >> >> >> >> On Wed, Mar 25, 2020 at 11:55 AM Justin Uberti >> wrote: >> >> >> >> >> >> On Wed, Mar 25, 2020 at 9:28 AM Spencer Dawkins at IETF < >> spencerdawkins.ietf@gmail.com> wrote: >> >> This is interesting ... >> >> >> >> On Wed, Mar 25, 2020 at 10:31 AM Victor Vasiliev > 40google.com@dmarc.ietf.org> wrote: >> >> I would like to second Justin's point here about the value of a >> client-server RTP streaming by itself (e-f, though in-band c-d are also >> valuable). There's a lot of value in the world where I can take an HTTP >> URL to some endpoint in the cloud and give it to, say, an IoT camera dev= ice >> to use as a realtime media sink, or pass it to an off-the-shelf streamin= g >> library to show a realtime media source on screen. >> >> >> >> I know most of my own concerns about RIPT media have started out with >> "this won't be as good as RTP for media", but what I've been getting fro= m >> RIPT discussions is, that may not matter as much as I expected. >> >> >> >> For a use case like Victor's, great media quality would be great, but >> good enough media quality may be ... good enough. >> >> >> >> Am I putting words in the mouths of the proponents? >> >> >> >> Some applications may tolerate somewhat lower quality in fallback >> scenarios, but I think we should be aiming for RTP performance with HTTP >> ease of deployment. >> >> >> >> I was actually hoping that wasn't the case, because ISTM that the >> question whether RTP performance over HTTP is possible/likely is going t= o >> suck up a LOT of the discussion time during the BOF ... >> >> >> >> To Eric's point, "H3 is not widely deployed yet, and so we should think >> about how we want things to look". I think it's entirely possible to >> achieve RTP performance over H3, and hopefully also have a reasonable >> fallback when only H2 is available. >> >> >> >> [Stephan]: many video conferencing technologies (including Vidyo, Zoom), >> have previously, or are currently supporting http-based media transport, >> often for years or even decades. They are almost never enabled by any >> professional deployer, because the resulting QoS is user-perceived as so >> bad that the marketing guys decided that offering no video/voice (and >> instead make people pick of the phone) is better for product reputation >> than offer the degraded QoS. >> >> Do any of you guys have hard numbers what sort of delay h3-based >> transport can achieve on today=E2=80=99s infrastructure? >> > > With H3 we have lots of options; there are lots of details to work throug= h > here but given that the substrate is QUIC there is no theoretical reason > why RTP performance isn't possible. > > Regarding HTTP media transport in existing products (i.e., non-H3), you > are correct that there are indeed limitations and as such providers do wh= at > they can to avoid this option, but it is nowhere near as grim as you make > it out to be. Recall that the first web version of Zoom exclusively used > websockets for transport > . > I mostly concur with Justin here: I would expect QUIC (which is to say probably H3 + Datagram) to be roughly comparable to RTP [0]. Anything over TCP will obviously be non-awesome, but we already do have some nontrivial fraction of media going over TCP to TURN relays, so it's not like it doesn't work at all, especially in good network conditions. -Ekr [0] There are some open issues with how QUIC congestion control and the media rate control interact, but I imagine they are mostly soluble. > -- > V3 mailing list > V3@ietf.org > https://www.ietf.org/mailman/listinfo/v3 > --0000000000003e346b05a1b34503 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Mar 25, 2020 at 12:52 PM Justin U= berti <juberti=3D40google= .com@dmarc.ietf.org> wrote:


On Wed, Mar 25, 20= 20 at 12:38 PM Stephan Wenger <stewe@stewe.org> wrote:

Hi Justin, all:

=C2=A0

From: = V3 <v3-bounces@ietf.org> on b= ehalf of Justin Uberti <juberti=3D40google.com@dmarc.ietf.org>
Date: Wednesday, March 25, 2020 at 12:32
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: Victor Vasiliev <vasilvv@google.com>, Jonathan Rosenberg <jdrosen@five9.com>, "= ;v3@ietf.org" <= ;v3@ietf.org>
Subject: Re: [V3] Thoughts on scope for ript

=C2=A0

=C2=A0

=C2=A0

On Wed, Mar 25, 2020 at 12:26 PM Spencer Dawkins at = IETF <spencerdawkins.ietf@gmail.com> wrote:

Replying to Justin, after reading Victor's reply= - thank you both for replying ...

=C2=A0

On Wed, Mar 25, 2020 at 11:55 AM Justin Uberti <<= a href=3D"mailto:juberti@google.com" target=3D"_blank">juberti@google.com> wrote:

=C2=A0

=C2=A0

On Wed, Mar 25, 2020 at 9:28 AM Spencer Dawkins at I= ETF <= spencerdawkins.ietf@gmail.com> wrote:

This is interesting ...

=C2=A0

On Wed, Mar 25, 2020 at 10:31 AM Victor Vasiliev <= ;vasilvv=3D40google.com@dmarc.ietf.org> wrote:

I would like to second Justin's point here about= the value of a client-server RTP streaming by itself (e-f, though in-band = c-d are also valuable).=C2=A0 There's a lot of value in the world where= I can take an HTTP URL to some endpoint in the cloud and give it to, say, an IoT camera device to use as a realtime media= sink, or pass it to an off-the-shelf streaming library to show a realtime = media source on screen.

=C2=A0

I know most of my own concerns about RIPT media have= started out with "this won't be as good as RTP for media", b= ut what I've been getting from RIPT discussions is, that may not matter= as much as I expected.=C2=A0

=C2=A0

For a use case like Victor's, great media qualit= y would be great, but good enough media quality may be ... good enough.=C2= =A0

=C2=A0

Am I putting words in the mouths of the proponents?<= u>

=C2=A0

Some applications may tolerate somewhat lower qualit= y in fallback scenarios, but I think we should be aiming for RTP performanc= e with HTTP ease of deployment.

=C2=A0

I was actually hoping that wasn't the case, beca= use ISTM that the question whether RTP performance over HTTP is possible/li= kely is going to suck up a LOT of the discussion time during the BOF ...=C2= =A0=C2=A0

=C2=A0

To Eric's point, "H3 is not widely deployed= yet, and so we should think about how we want things to look". I thin= k it's entirely possible to achieve RTP performance over H3, and hopefu= lly also have a reasonable fallback when only H2 is available.

=C2=A0

[Stephan]: many video conferencing technologies (inc= luding Vidyo, Zoom), have previously, or are currently supporting http-base= d media transport, often for years or even decades.=C2=A0 They are almost n= ever enabled by any professional deployer, because the resulting QoS is user-perceived as so bad that the marketing g= uys decided that offering no video/voice (and instead make people pick of t= he phone) is better for product reputation than offer the degraded QoS.=C2= =A0

Do any of you guys have hard numbers what sort of de= lay h3-based transport can achieve on today=E2=80=99s infrastructure?


With H3 we hav= e lots of options; there are lots of details to work through here but given= that the substrate is QUIC there is no theoretical reason why RTP performa= nce isn't possible.

Regarding HTTP media trans= port in existing products (i.e., non-H3), you are correct that there are in= deed limitations and as such providers do what they can to avoid this optio= n, but it is nowhere near as grim as you make it out to be. Recall that the= first web version of Zoom exclusively=C2=A0used websockets for transp= ort.

I mostly concur = with Justin here: I would expect QUIC (which is to say probably H3 + Datagr= am) to be roughly comparable to RTP [0]. Anything over TCP will obviously b= e non-awesome, but we already do have some nontrivial fraction of media goi= ng over TCP to TURN relays, so it's not like it doesn't work at all= , especially in good network conditions.

-Ekr<= /div>

[0] There are some open issues with how QUIC conge= stion control and the media rate control interact, but I imagine they are m= ostly soluble.
<= div dir=3D"ltr">
--
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3
--0000000000003e346b05a1b34503-- From nobody Wed Mar 25 13:18:43 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AB33A0A16 for ; Wed, 25 Mar 2020 13:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 wzLjkkbc4A8F for ; Wed, 25 Mar 2020 13:18:39 -0700 (PDT) Received: from mail-ua1-x942.google.com (mail-ua1-x942.google.com [IPv6:2607:f8b0:4864:20::942]) (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 210F63A0A46 for ; Wed, 25 Mar 2020 13:18:38 -0700 (PDT) Received: by mail-ua1-x942.google.com with SMTP id o15so1272301ual.3 for ; Wed, 25 Mar 2020 13:18:38 -0700 (PDT) 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=RUKXYMz7txulgKvgH1svXJkb3juYvfkEyQ3fcodGmsg=; b=E4xKaXIJKVE82lRdg4XVeVL+abem3oHlwogOnUNU8RKW3ZOIf81U2YTgCIuZYqscMQ XSUaCOk8FRPA+Z4MbSy9Pvhs7qktOkxQt3njYKRG3jvJhMkFnTjxNLRuaa62qhVAIoyj 0rypfjo/QlMU1gd9/rE+LmO5nTSemt3cDfv0/SPDMr3SReCn+rs9GvAhCAM3gU0lIZ+u Uim7iD2sWoV7yknYBdv11rYU4DzvFMGMigY4PcraOhMUKNW9Nn+0snQm6wrogzTb3F1Y OvU3Wd75KTl+EbhviELNtDohT7PILC3OJYO/jIvKXrjMiesU+APkD5IveZnTosCB/N2S Fefg== 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=RUKXYMz7txulgKvgH1svXJkb3juYvfkEyQ3fcodGmsg=; b=GrdINoE7sHT6ZyXZluZ7n897S+s1LbkkCwhgwfTBwify3hsQ/kSJ7dBLjRy5tfO95y LS7vRNfPkbJYzHbcyyihljO4mOO5G3BOY8r0hH2IFpftFfvkYi9ON3tAdQvTE31wVRvv TzjRnIOJNJ7TTsXbA8bT0uxWiJcXPbD4gCTL25O6aPnirq3sJV+o92haYjYA+SxwFmo4 2mP0ZXtJw8EFYknYYV3JU1JNII2zi4iidkyq3GAEIF2o7XT8S8sBjIO0zLgYXbTiFuSd xikHR7q60TIhpiElys4TmBNQuYbawpseo3z0ymRoKF+wAOdCr+syHxPJRfOLEZ5h41Wn p9lg== X-Gm-Message-State: ANhLgQ2IcDWJ25efih8cK1p+7f4TT22KwN3GKiUtMUN5K1OWp3icmUTe ACXLm7/D2UazFl40+BM/on0cSxz7P2b48naya5WkEQ== X-Google-Smtp-Source: ADFU+vuyfoWS1MTD2iskhFD6s4XCEUv/VW5rRhjf3QdzZcv36cBdRNSZ8XykJH+OoJ+YYJhKO4L6mAlTSdC79RQixBo= X-Received: by 2002:a9f:2204:: with SMTP id 4mr3744961uad.87.1585167516645; Wed, 25 Mar 2020 13:18:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Wed, 25 Mar 2020 13:18:24 -0700 Message-ID: To: Eric Rescorla Cc: Stephan Wenger , Victor Vasiliev , Jonathan Rosenberg , "v3@ietf.org" , Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary="000000000000bdb59e05a1b39232" Archived-At: Subject: Re: [V3] Thoughts on scope for ript X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 20:18:43 -0000 --000000000000bdb59e05a1b39232 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 25, 2020 at 12:58 PM Eric Rescorla wrote: > > On Wed, Mar 25, 2020 at 12:52 PM Justin Uberti 40google..com@dmarc.ietf.org <40google.com@dmarc.ietf.org>> wrote: > >> >> >> On Wed, Mar 25, 2020 at 12:38 PM Stephan Wenger wrote: >> >>> Hi Justin, all: >>> >>> >>> >>> *From: *V3 on behalf of Justin Uberti >> 40google.com@dmarc.ietf.org> >>> *Date: *Wednesday, March 25, 2020 at 12:32 >>> *To: *Spencer Dawkins at IETF >>> *Cc: *Victor Vasiliev , Jonathan Rosenberg < >>> jdrosen@five9.com>, "v3@ietf.org" >>> *Subject: *Re: [V3] Thoughts on scope for ript >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Mar 25, 2020 at 12:26 PM Spencer Dawkins at IETF < >>> spencerdawkins.ietf@gmail.com> wrote: >>> >>> Replying to Justin, after reading Victor's reply - thank you both for >>> replying ... >>> >>> >>> >>> On Wed, Mar 25, 2020 at 11:55 AM Justin Uberti >>> wrote: >>> >>> >>> >>> >>> >>> On Wed, Mar 25, 2020 at 9:28 AM Spencer Dawkins at IETF < >>> spencerdawkins.ietf@gmail.com> wrote: >>> >>> This is interesting ... >>> >>> >>> >>> On Wed, Mar 25, 2020 at 10:31 AM Victor Vasiliev >> 40google.com@dmarc.ietf.org> wrote: >>> >>> I would like to second Justin's point here about the value of a >>> client-server RTP streaming by itself (e-f, though in-band c-d are also >>> valuable). There's a lot of value in the world where I can take an HTT= P >>> URL to some endpoint in the cloud and give it to, say, an IoT camera de= vice >>> to use as a realtime media sink, or pass it to an off-the-shelf streami= ng >>> library to show a realtime media source on screen. >>> >>> >>> >>> I know most of my own concerns about RIPT media have started out with >>> "this won't be as good as RTP for media", but what I've been getting fr= om >>> RIPT discussions is, that may not matter as much as I expected. >>> >>> >>> >>> For a use case like Victor's, great media quality would be great, but >>> good enough media quality may be ... good enough. >>> >>> >>> >>> Am I putting words in the mouths of the proponents? >>> >>> >>> >>> Some applications may tolerate somewhat lower quality in fallback >>> scenarios, but I think we should be aiming for RTP performance with HTT= P >>> ease of deployment. >>> >>> >>> >>> I was actually hoping that wasn't the case, because ISTM that the >>> question whether RTP performance over HTTP is possible/likely is going = to >>> suck up a LOT of the discussion time during the BOF ... >>> >>> >>> >>> To Eric's point, "H3 is not widely deployed yet, and so we should think >>> about how we want things to look". I think it's entirely possible to >>> achieve RTP performance over H3, and hopefully also have a reasonable >>> fallback when only H2 is available. >>> >>> >>> >>> [Stephan]: many video conferencing technologies (including Vidyo, Zoom)= , >>> have previously, or are currently supporting http-based media transport= , >>> often for years or even decades. They are almost never enabled by any >>> professional deployer, because the resulting QoS is user-perceived as s= o >>> bad that the marketing guys decided that offering no video/voice (and >>> instead make people pick of the phone) is better for product reputation >>> than offer the degraded QoS. >>> >>> Do any of you guys have hard numbers what sort of delay h3-based >>> transport can achieve on today=E2=80=99s infrastructure? >>> >> >> With H3 we have lots of options; there are lots of details to work >> through here but given that the substrate is QUIC there is no theoretica= l >> reason why RTP performance isn't possible. >> >> Regarding HTTP media transport in existing products (i.e., non-H3), you >> are correct that there are indeed limitations and as such providers do w= hat >> they can to avoid this option, but it is nowhere near as grim as you mak= e >> it out to be. Recall that the first web version of Zoom exclusively used >> websockets for transport >> . >> > > I mostly concur with Justin here: I would expect QUIC (which is to say > probably H3 + Datagram) to be roughly comparable to RTP [0]. Anything ove= r > TCP will obviously be non-awesome, but we already do have some nontrivial > fraction of media going over TCP to TURN relays, so it's not like it > doesn't work at all, especially in good network conditions. > > -Ekr > > [0] There are some open issues with how QUIC congestion control and the > media rate control interact, but I imagine they are mostly soluble. > Yes, the CC stuff is one of the details I was thinking of. The other main one is the right abstractions in cloud providers to allow more direct access to the underlying transport. --000000000000bdb59e05a1b39232 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 25, 2020 at 12:58 PM Eric= Rescorla <ekr@rtfm.com> wrote:
=

On Wed, Mar 25, 2020 at 12:52 PM Justin Uberti <juberti= =3D40googl= e..com@dmarc.ietf.org> wrote:


On Wed, Mar 25, = 2020 at 12:38 PM Stephan Wenger <stewe@stewe.org> wrote:

Hi Justin, all:

=C2=A0

From: = V3 <v3-bounces@ietf.org> on b= ehalf of Justin Uberti <juberti=3D40google.com@dmarc.ietf.org>
Date: Wednesday, March 25, 2020 at 12:32
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: Victor Vasiliev <vasilvv@google.com>, Jonathan Rosenberg <jdrosen@five9.com>, "= ;v3@ietf.org" <= ;v3@ietf.org>
Subject: Re: [V3] Thoughts on scope for ript

=C2=A0

=C2=A0

=C2=A0

On Wed, Mar 25, 2020 at 12:26 PM Spencer Dawkins at = IETF <spencerdawkins.ietf@gmail.com> wrote:

Replying to Justin, after reading Victor's reply= - thank you both for replying ...

=C2=A0

On Wed, Mar 25, 2020 at 11:55 AM Justin Uberti <<= a href=3D"mailto:juberti@google.com" target=3D"_blank">juberti@google.com> wrote:

=C2=A0

=C2=A0

On Wed, Mar 25, 2020 at 9:28 AM Spencer Dawkins at I= ETF <= spencerdawkins.ietf@gmail.com> wrote:

This is interesting ...

=C2=A0

On Wed, Mar 25, 2020 at 10:31 AM Victor Vasiliev <= ;vasilvv=3D40google.com@dmarc.ietf.org> wrote:

I would like to second Justin's point here about= the value of a client-server RTP streaming by itself (e-f, though in-band = c-d are also valuable).=C2=A0 There's a lot of value in the world where= I can take an HTTP URL to some endpoint in the cloud and give it to, say, an IoT camera device to use as a realtime media= sink, or pass it to an off-the-shelf streaming library to show a realtime = media source on screen.

=C2=A0

I know most of my own concerns about RIPT media have= started out with "this won't be as good as RTP for media", b= ut what I've been getting from RIPT discussions is, that may not matter= as much as I expected.=C2=A0

=C2=A0

For a use case like Victor's, great media qualit= y would be great, but good enough media quality may be ... good enough.=C2= =A0

=C2=A0

Am I putting words in the mouths of the proponents?<= u>

=C2=A0

Some applications may tolerate somewhat lower qualit= y in fallback scenarios, but I think we should be aiming for RTP performanc= e with HTTP ease of deployment.

=C2=A0

I was actually hoping that wasn't the case, beca= use ISTM that the question whether RTP performance over HTTP is possible/li= kely is going to suck up a LOT of the discussion time during the BOF ...=C2= =A0=C2=A0

=C2=A0

To Eric's point, "H3 is not widely deployed= yet, and so we should think about how we want things to look". I thin= k it's entirely possible to achieve RTP performance over H3, and hopefu= lly also have a reasonable fallback when only H2 is available.

=C2=A0

[Stephan]: many video conferencing technologies (inc= luding Vidyo, Zoom), have previously, or are currently supporting http-base= d media transport, often for years or even decades.=C2=A0 They are almost n= ever enabled by any professional deployer, because the resulting QoS is user-perceived as so bad that the marketing g= uys decided that offering no video/voice (and instead make people pick of t= he phone) is better for product reputation than offer the degraded QoS.=C2= =A0

Do any of you guys have hard numbers what sort of de= lay h3-based transport can achieve on today=E2=80=99s infrastructure?


With H3 we hav= e lots of options; there are lots of details to work through here but given= that the substrate is QUIC there is no theoretical reason why RTP performa= nce isn't possible.

Regarding HTTP media trans= port in existing products (i.e., non-H3), you are correct that there are in= deed limitations and as such providers do what they can to avoid this optio= n, but it is nowhere near as grim as you make it out to be. Recall that the= first web version of Zoom exclusively=C2=A0used websockets for transp= ort.

I mostly concur = with Justin here: I would expect QUIC (which is to say probably H3 + Datagr= am) to be roughly comparable to RTP [0]. Anything over TCP will obviously b= e non-awesome, but we already do have some nontrivial fraction of media goi= ng over TCP to TURN relays, so it's not like it doesn't work at all= , especially in good network conditions.

-Ekr<= /div>

[0] There are some open issues with how QUIC conge= stion control and the media rate control interact, but I imagine they are m= ostly soluble.

Yes, the C= C stuff is one of the details I was thinking of. The other main one is the = right abstractions in cloud providers to allow more direct access to the un= derlying transport.=C2=A0
--000000000000bdb59e05a1b39232-- From nobody Thu Mar 26 13:29:16 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC9E3A0D70 for ; Thu, 26 Mar 2020 13:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=c6OfumUj; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=K3UaPTPj 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 56OZVr7Abq9C for ; Thu, 26 Mar 2020 13:28:56 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 602173A0D6B for ; Thu, 26 Mar 2020 13:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1040; q=dns/txt; s=iport; t=1585254536; x=1586464136; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KTgn2EWjjn+rS+bSHliVGTsdpvEfQxE1Q0038kDg4kU=; b=c6OfumUj/MZhLzPRkH3sPIXtbHTW0tdMEq01js6PuNfH0lyKccoG3SLs 04WfA22aWSwjm5YNaVvxc7Kt5OIn6Wa8ENWq9cDt53IglHwHqJH4fnkMh kCYhPEyhMmWnzNbnjGWjItNZEakSHbePk59NXVXq0Zr8NfehGB5B4jWvN I=; IronPort-PHdr: =?us-ascii?q?9a23=3Aecy32BN9QAzo1goziZcl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj+PvfsZjArNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BNAAChD31e/5pdJa1MGhwBAQEBAQc?= =?us-ascii?q?BAREBBAQBAYFnBwEBCwGBU1AFbFggBAsqCodVA4RahgyafYEugSQDVAoBAQE?= =?us-ascii?q?MAQEYDQgCBAEBhEQCgi8kNAkOAgMBAQsBAQUBAQECAQUEbYVWAQuFcQIBAwE?= =?us-ascii?q?BECgGAQEsCwEPAgEIMAYGCicLJQIEDgUigwWCSwMuAQ48okMCgTmIYoIngn8?= =?us-ascii?q?BAQVFagEDBIEOglQYggwDBoE4AYwuGoFBP4ERgmYuPoEEAYFfAQECARmBSU+?= =?us-ascii?q?CGIJuG7BbCoI8h1+If4YrHYJMiC2QaYVEiU+JEZJnAgQCBAUCDgEBBYFSOYF?= =?us-ascii?q?YcBU7gmxQGA1YjUUMDAuDUIUUhUF0AoEni1uBDQGBDwEB?= X-IronPort-AV: E=Sophos;i="5.72,309,1580774400"; d="scan'208";a="468518926" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2020 20:28:55 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 02QKStdb028559 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 26 Mar 2020 20:28:55 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 26 Mar 2020 15:28:55 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 26 Mar 2020 15:28:54 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 26 Mar 2020 15:28:54 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d8Gr1lvehA0OzCSJ3sioeEflnwZXe8VSVpCwKSjtiCIv5QxsWED5s4lbXvVNP58ndQhOaN8iCYfqUwW0BlPiN36S9UQfPRm1UhXy0LdR4ACe3YGFfKpYMy0jJpOQNvDd4Td0FpPYYdWbkbeeJEA84HhP4ef4iDZuGrpHXWeKOd5OQEnA2sFNbxHki7cabIuApO5h8NmSy4Zly/uTHmwKbmdcmgCTINq6Q1kzNpWI5R54iNAHUdLIdV3+qNSWnLMNEkC+bIyVIRpuT7HYAjxyJVzg5Fq6TQKCBspMt213v1x82/d0sz2pBDTERkKqtLXESPRCHdHorZavusM6iGJELQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KTgn2EWjjn+rS+bSHliVGTsdpvEfQxE1Q0038kDg4kU=; b=Rh4pg5kbdhJnWauECMbC9RVOPhiyyWUJ1Df56QPQK62Z3Hg4wTeuQTQJK1Ha1fqWTcDC1cuqVJn5IZ1QzJp12n2cQAHzB3HdzYg8ey8NFrs29lhp43OiOlYhtBcAH9x6e0bzNw+TYnX7+cc97ikqPWqqpXIOYxf8LsN6aU3QZiedhFwgiSrWOdH3rvGqM75gyDux4uMb+LRfx2H+qPsNrl6jT8DUITL06CwIoBFKNoKTORqwfPI4j4m8qGqeWtjJU+zAaVDas9O69LSUa/2qpzG68xX1SMrOvz8Y7FVSZFz1HUMRwKi/0DrS4YMeICsgbA4snKVV8vDMdZ6+4VX/nQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KTgn2EWjjn+rS+bSHliVGTsdpvEfQxE1Q0038kDg4kU=; b=K3UaPTPjGd49k8nsMVau2WMb0QUXLfJgJ+iJLJsVQrtAPkiC5xwsZ7FIlDBE4IVMms/trBa2FQyr9hQW7cq2IlY/1v3T7TQOH9W5W+Taaqf76H18aJ55zhqqwSYZurfJAqXkEiOvNbgWy1oGdNcIhJIvKiYAE+uLpgvetKmJIdU= Received: from BN7PR11MB2753.namprd11.prod.outlook.com (2603:10b6:406:b0::23) by BN7PR11MB2642.namprd11.prod.outlook.com (2603:10b6:406:ab::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.22; Thu, 26 Mar 2020 20:28:53 +0000 Received: from BN7PR11MB2753.namprd11.prod.outlook.com ([fe80::acc4:5dcb:804c:2e1c]) by BN7PR11MB2753.namprd11.prod.outlook.com ([fe80::acc4:5dcb:804c:2e1c%5]) with mapi id 15.20.2835.023; Thu, 26 Mar 2020 20:28:53 +0000 From: "Mo Zanaty (mzanaty)" To: "v3@ietf.org" CC: Martin Thomson Thread-Topic: [V3] Virtual IETF 107 Meeting WebEx Invitation: RIPT Thread-Index: AQHWA60q34JAONkDeUqC1DxXUAIxjA== Date: Thu, 26 Mar 2020 20:28:52 +0000 Message-ID: References: <158472539746.13570.11062487766981484925@ietfa.amsl.com> In-Reply-To: <158472539746.13570.11062487766981484925@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mzanaty@cisco.com; x-originating-ip: [107.15.209.8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5ac63675-ebd1-4d12-a662-08d7d1c44cfb x-ms-traffictypediagnostic: BN7PR11MB2642: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0354B4BED2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(346002)(396003)(376002)(39860400002)(76116006)(86362001)(36756003)(186003)(16799955002)(4326008)(71200400001)(2906002)(2616005)(26005)(6916009)(4744005)(8676002)(66476007)(316002)(6506007)(81166006)(81156014)(478600001)(53546011)(66946007)(5660300002)(6486002)(66556008)(6512007)(8936002)(66446008)(966005)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2642; H:BN7PR11MB2753.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: O4HGca77+5z716q+4SvWlTNva7wrV+rLX+NDKgwdgKItJM1nJDjCbd67FgXUs4i2ZHv6vfC1rr7jxdNkcM8wVzLt3zOe7z0CPuCTpKOCZN1VYTBsGv9sU8QIQQcDdXGBmbB0K1FEdvWLb3LwKyz7ji00i+ccdAB1ccHW/ft0hm65HEuci8W/ix6IwGCoLfi5TJWh5nbg+l/Pa8M+Eyf6paNJOzzuJ95nPd0OWRwDlhXv/yqr1U6IyAPwOM7xpYWE/+wi0b04IviXskDIDzpmy6l2QSWRc3ER2jjMQ9zKfbC3M981gwc1ILXr+Q/XCKl5IYtzVcFQTVjSQyNsYaJQq1XbIYPAkT9vFTUjX8J3/tYsbpeWG4SFvbnM+vF7XRPxiFn7jXZHO7gMy3werA9yt4lQFf3wOtQIt+t5cgBY0tiOga7lzZ2yuqJCvl0quqvNJCc+48IF89UezJvk6EENfWk84eZ8kpy9JVq9d4tM6wDHycI8QMxiRDo8Bhww2V4JLOx6MVWTLg3DZmTfnAQBCQ== x-ms-exchange-antispam-messagedata: 4RFr5jtkJRAFL+5HCsZ+pfNJZsYIRbJEL1sm5a8QFEdIDwo3n50zud/XrxvYLMeZ8Fr9s9y20JVVxs+vGLmpZaB+XZeUP585B1ZJHtCXN7+TOWA6+nTS+Qhf60i6R9rNGwgxgQ4gvdP/VTPPKcK6bw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <5D18B8C24E51114585FB8EAEC749E982@namprd11.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5ac63675-ebd1-4d12-a662-08d7d1c44cfb X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2020 20:28:52.9261 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: w8vIok6dvDsC5HDTokPR+Rx1DTl4NAgn2OXCVZ73C23e5sBEU+M4bOgecbXi679zFZA0P8eLqeHfdi3TTMDReQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2642 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [V3] Virtual IETF 107 Meeting WebEx Invitation: RIPT X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 20:29:15 -0000 The RIPT BOF will begin in 2 hours at the Webex link below. https://ietf.webex.com/ietf/j.php?MTID=3Dm77168c5c7592f30d7f369b49b47cfcf3 Please sign the virtual blue sheet in Etherpad: https://etherpad.ietf.org/p/notes-ietf-107-ript?useMonospaceFont=3Dtrue Please join Jabber for general chat: xmpp:ript@jabber.ietf.org?join Webex chat is only to join the mic queue ("+q", or "-q" to cancel). We need volunteer Note Takers and a Jabber Scribe; please unicast the chairs. Thanks, Mo & Martin On 3/20/20, 1:29 PM, "V3 on behalf of IETF Agenda" wrote: >RIPT Session at IETF 107 > >Thursday, March 26, 2020 >22:10-00:10 UTC > >Join meeting:=20 > > >Meeting number (access code): 646 916 587 >Meeting password: avEzuWXp427 > >IETF 107 Agenda: > >--=20 >V3 mailing list >V3@ietf.org >https://www.ietf.org/mailman/listinfo/v3 From nobody Thu Mar 26 18:03:51 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FAE3A0CBB for ; Thu, 26 Mar 2020 18:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=lowentropy.net header.b=GOOIRzUx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mMTDW7Rp 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 gO7Dqe4pQtBh for ; Thu, 26 Mar 2020 18:03:47 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9073A0DEE for ; Thu, 26 Mar 2020 18:03:47 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 6101941F for ; Thu, 26 Mar 2020 21:03:46 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Thu, 26 Mar 2020 21:03:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=lks2881LLOUeT5JKw5fWb7h+pGtJZqkUxCmPg4brfYU=; b=GOOIRzUx ApwPkjADqmILluxJMgxh2ky2wWcciQxSnn802hVi6k6i5+WyVRUeYq8rZXBEIoHa v30Ro2oRehhAp/Hmu/GkCTt1QiwoqIkTI6zQqgPvEfYNF2HmCMA2m1MwXXwqgYd8 1UCTLLpVDlrCvWGlnnlYIsZeieBm6yLgsGHh4irZ3ZaGcUk0EEz3bbgORVxZ5nDy Ol4t/JehuwIS6i/+paDmoBYr6TSchP0iqj9J4OmeV/XWbXR/UofhpDBRMH2NFA38 N6bAEgKO6W3Ew9l4VXsI4wMlk5zjJA/9/Pi7T9c3j8sTHVOPEa3/878ve2YcOu44 WX2TEDDZHcwuIQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=lks2881LLOUeT5JKw5fWb7h+pGtJZ qkUxCmPg4brfYU=; b=mMTDW7RpmSKM3YbTqk/QDnRh9cFeRylLF3xg4i9GfUtIU ar/tsPFG02SjYZqhRib7EfIvkH/GbYB4dIXOCoxdS7y729Wtv/4U+rwkRWFeck5i L24WQ9bOnH8DNsmGV2fAwxHdmgl0LBW3WjMdw7XGB7/pp3wNMdAACtVDaYH3bY85 o3rU7Iji3QsyF7/Qbuqf62LkBO1zyo6FSW64eIAnNxISeaU+oR0onkDZioKl3PjD Os+ZcSEsx9Ji4KzCzo4CJyM35ZgEYmLH+aFAn2G5D02s8HUIOh5Qjz+4yWyCO+0j 6LsrlnpuqKtaT/ytzy71u6qNa6VOGHMBTWZmjUrXg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehjedguddvlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhht rhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A6CE1E00BB; Thu, 26 Mar 2020 21:03:45 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-Id: <2cc05d77-a28f-4c16-8507-0cdc124a8d9a@www.fastmail.com> Date: Fri, 27 Mar 2020 12:03:25 +1100 From: "Martin Thomson" To: v3@ietf.org Content-Type: text/plain Archived-At: Subject: [V3] Minutes from BoF session X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 01:03:49 -0000 https://datatracker.ietf.org/doc/minutes-107-ript/ contains both the minutes from Dan York that were collected in Etherpad and some bonus minutes prepared by Jean Mahoney. Thank you both very much for your contribution and the excellent notes. And thank you everyone who contributed to a productive discussion. We have some more work to do on refining the scope of this work. I encourage those people who had specific issues with scope to again raise them on the list so that we can work through them. Related to the scoping question, it seems to me that the question of how to structure any effort in this space is going to be quite important. If people have concrete suggestions about how that might be done, then input on that would also be valuable. From nobody Fri Mar 27 07:24:07 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19B13A0A4E for ; Fri, 27 Mar 2020 07:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 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 ZqQiGhZXT9Nd for ; Fri, 27 Mar 2020 07:24:03 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0601.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::601]) (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 C27A03A0B77 for ; Fri, 27 Mar 2020 07:24:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VCyLYuJVc17QHwEs8vV5KZmhKBy2wiyXUa+7hsE7wr66fP/558IaDyAoENjQNDdIeTCGYs/ViN8+g8O6ZOa+YW/acyGQRz2AxGg5E3N9jmPUKrZ4NwAZzeny8nX6ijxMZbznEMjedb/mgfiBLQX/dT2wNbL4X7EknGP281FDsXwWTQeTkDcf40SIPkADefqGZaO9ejCUobUOr+P58L0+OozNNRBnkGdUN1bbYJeh9UAILdyYLbTvn95kQY601Jp8k/zZ0ktt6yhRsdRxvBAnUQmTIYK6/BO9CxKbwVS83As0VY/MEgkDbFxxoHZpt3hqGZhtJ44xOrbGBdogBCqqSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E6+t8yzA/Ia+H6f4stjwoZkCzJm87hFK3VzknCmbn6E=; b=hSE9qtBmW0v5pMd/9E/fYvNQmAsUbrppmexyhpmJ7Yp6kVJqKmD2SHDBy06rIiTgH71RBhbCfVN0XTT1M2/QewBRFMlDnrCdh/JuMedaO4TM9WAACx5RYBwQmwvM4tqDyVLRSehAPAo17w60abs/cy1gRPmKt82t179ZsR8esPROaGuTmMgUn6dwV8G46Xp1qa3D7JGXJsW91Jy5HPED/WSR3vXnoFOIIO1+2HSJA0FKSOPENhQtDRguHDRsgi12Pf+41Qk4FnNi0Q5e/nvH4C+G2CGOAMcyBXk7NRsoTr82SEBURigX5D35Obxyg7NiVw9DYLmt5mXLHKbEVAlKQA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=E6+t8yzA/Ia+H6f4stjwoZkCzJm87hFK3VzknCmbn6E=; b=lUVjnM/GzaR0LLD7rC6aoJiDP+SNipe0BFQbN3qrBqrnwX1/yPkl99YDwWJFOXTGAwIKyETGVrlfMhXriCzL5aIZ3JRE+kp2PRD55GTnjCOwCyfTy3P3/OAMCbv8V3ibiG/PrUwTs9pS91N3IEuuctuWqHEy2vCY3uyRczeZ7vI= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (52.133.7.14) by HE1PR0702MB3577.eurprd07.prod.outlook.com (10.167.124.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.9; Fri, 27 Mar 2020 14:23:59 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8bd:85b0:d547:9eed]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8bd:85b0:d547:9eed%6]) with mapi id 15.20.2856.018; Fri, 27 Mar 2020 14:23:59 +0000 From: Magnus Westerlund To: "v3@ietf.org" Thread-Topic: High level comments on the RIPT charter and scope Thread-Index: AQHWBENbus/fvMWAlEybhl6kdLAG2A== Date: Fri, 27 Mar 2020 14:23:59 +0000 Message-ID: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1 authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [158.174.118.23] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e2b7c7da-8d91-4e9d-a46c-08d7d25a7dff x-ms-traffictypediagnostic: HE1PR0702MB3577: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0355F3A3AE x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(366004)(136003)(376002)(346002)(396003)(6916009)(36756003)(316002)(44832011)(81156014)(6486002)(81166006)(8676002)(2906002)(8936002)(71200400001)(66476007)(76116006)(6506007)(478600001)(66574012)(186003)(64756008)(66556008)(6512007)(66616009)(5660300002)(2616005)(66446008)(86362001)(26005)(66946007)(99106002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rcy/6Uu9LsO0mQRaWFiTW3T4Ec/0uBF0p01HX+sdStSOLxJBSOMBe30fI5j2y34BOrW0UPysS0YzY6H2qIT1fW9QB5W8QMZRoFXq2C63ghKrFs4EFvJ5kOTc6bHiKpYgGoNxNkzPTNQ3B4ljSgiSZJSSDYdSogsc8sGz4xKMIsaAf12owTNIwpJziiI0njIlr+YIsTOOchW1+3stl1LXHw/fk1bm/67PnAtqVLcIIuwml5YSKhnnMwNWFNh0rDSyWoKDm4AThsqYAkJlxAEFS1TWD01quMgjaGRYuBj7zifISsS5SxwDWForhT4otAekoljpBWa3AT8Zbo04PUbbfpRFBQIJ40/QE+En19OH1ppJ7/igFiZnNxS50DpcULAcyvvZ4+lpR2TvKoCngKRA6QSNcgq46m/VNNw/fqMo11SFKTDx5IxcIRyXC3E/6TqIbaXxT3CnmwTImpHYeBImTevi9VF4S7Z4ATLTv62FjLdaTe7Lbwk2N4W9UrAb9D7U x-ms-exchange-antispam-messagedata: OSq+zuPcqJrqeXmr/9vJmLEg6295u2A2pmp2EPvhSSA+bDvrWKmWkMtjNrSEwzYv7kcGELcfpaa2RxdoFWbNUHYaM7TYIsen+PJe3w993rwVFJTcFHTf/h7pkngnxrVmi/XYsF6IgrC4ZALa16HpMQ== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-POrPBlyi4qckmp7Lqz2l" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e2b7c7da-8d91-4e9d-a46c-08d7d25a7dff X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2020 14:23:59.7730 (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-CrossTenant-userprincipalname: hpZB57u227IchrqIbfHir9kw+VipT2XajuLjnJFb7e0sdcFL3xoYVhAP/jF1hbXMc+Ghqq90+d5Eh6+jnbcvE4fcyLdLRLHAdS9NkvqANoc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3577 Archived-At: Subject: [V3] High level comments on the RIPT charter and scope X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 14:24:05 -0000 --=-POrPBlyi4qckmp7Lqz2l Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, So this is my personal opinion and based on my long work with RTP.=20 Yes, there are clearly interest in chartering some work in IETF. Howver, I = think there is significant diversity in what people are interested in actually happening.=20 Clearly there is the signalling protocol for seession/call establishment an= d control between peering provider nodes. Lets call this the outbound part. T= he main issue I see in this area is the quetion of feature creap. It would be = good to figure out what core functionality is really needed and actually get tha= t described in a charter. A Question is if conference applications impacts th= is scope or not.=20 The next part is the inbound problem, i.e. having end-user devices/applicat= ion being able to register to their provider as being ready to receive/answer c= alls. This may actually be sufficient similar to the outbound part that they can = be done in the same WG.=20 However, an interesting question for both of the above is if the solution i= s required to be able to be implemented in a browser, at least the client par= t. I think the signalling is fairly straight forward to be able to implement in = JS as long as we ignore the media.=20 The third big part is the media transport. I think we need to strongly cons= ider if this can be broken out in to it seperate WG. There are several aspects h= ere. First of the split in expertise between the media transport and the signall= ing folks. The next aspect is the resuability of the media transport, that anyw= ay need to be define as individual reusable protocol component that is not dependent on the signalling. I don't see a huge problem with being able to initiate a media transport channel into the relevant server node using an initial HTTP request. I am thinking WebSocket like establishment of the med= ia transport channel here. And possibly there will be need for a fallback to H= TTP only, but also that should be further discussed.=20 I am also very worried that if the model for the media transport is only po= int to point calls then we get something that will become obsolete or at least = need hacks immediately. This thing need to support centralized conferences with cascaded or meshed central media nodes. So I think it is cruical that one d= efine the usage model with switched central nodes and have that in mind so that o= ne can actually support the applications needed. I think by defining a strict = model one can actually avoid a lot of feature creep in the media transport.=20 We also have use cases that has practical total overlapp, namely real-time sensor streaming services, where cameras, and other frequently sampling sen= sors send data of real-time control loop nature. There is also the media industr= ies need for content contribution, i.e. how to get camera's media into the production centers. These are similar enough and need of standardized proto= cols. SRT in Dispatch is only one aspect of this. What we don't need to take on f= or this is the one-to-many distribution only. So broadcast and multicast can b= e declared out of scope.=20 I think E2E media secruity need to be defined from day one. It will be a ce= ntral part of these systems even if in the legacy interconnect there will be the termination in gateways. Also media processing nodes can be included but th= e inclusion of them in the trust will need to be explicit in this model.=20 People have been voicing that we don't need things to work as well as RTP. = I think in fact that a dedicated real-time media over QUIC (with datagram) ca= n actually achieve better than RTP performance by using a mix of reliable and semi-reliable transport primitives on applciation data unit level, i.e. aud= io and video frames.=20 The next media transport issue that was barely discussed in the BOF is the legacy (RTP) interoperate question. This is going to come back in the scope discussion and do needs at least a direction.=20 Coming back to my initial statement about diversity, I think there at least= two communities that are interested in this. And I think we actually need to at= tempt to make relevant protocol work for both these communities. For the moment t= he most outspoken people in this effort have been the signalling people. The m= edia transport crowd have been waiting for their turn until QUIC to matured sufficiently to be a realistic start. But as people know some discussion ha= ve happened. However we are this point now I think where work can start in ern= est also on this topic.=20 So can we seriously consider writing two different charter that together en= able the intended use cases?=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-POrPBlyi4qckmp7Lqz2l Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDMyNzE0MjM1OFowLwYJKoZIhvcN AQkEMSIEIGy98v+XQU7aVvNlyGvNoPy/wRc60LNCjdI/BVAsWbTTMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAOiK838ysUhy2 +tPCpf3gfdk4cWu+ZsTYj94lv3zbKghTvCxUulzUOAp7bNQnq0jQIPT0W9kqkVX8gLqI/pmCmjKG EsTVKwpjR0L5DNYBsUs78aQU/vDfny5ZMBiAAY+76PHp9Vu2dGd6amae4TneavP9GSViiT+H4e93 oRR+Bf1/WTghClyw5/VFbfGpRspd6ntsOlfN9y6P1rbdWBKYymQe0tK9Juf7C8/+c9nID1jQ/mqg jm86ESxiZN93QRu3GWa11XrsAaAFh1rXVapu+FZM97RVLy9L2yGTKgAv7CDJkYUboWVpJjD0NEcq PTIyTwPPQbEU2EW8MVC1OL4JCgAAAAAAAA== --=-POrPBlyi4qckmp7Lqz2l-- From nobody Fri Mar 27 09:11:04 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A703A0C83 for ; Fri, 27 Mar 2020 09:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 GIRoDHP5IAvW for ; Fri, 27 Mar 2020 09:11:00 -0700 (PDT) Received: from smtp76.ord1c.emailsrvr.com (smtp76.ord1c.emailsrvr.com [108.166.43.76]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F37C43A0C6B for ; Fri, 27 Mar 2020 09:10:59 -0700 (PDT) X-Auth-ID: fluffy@iii.ca Received: by smtp26.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id F0F1AE02F7; Fri, 27 Mar 2020 12:10:58 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [50.66.148.85]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 27 Mar 2020 12:10:59 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_1269667F-8794-4909-987C-CF24C4464EE5" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Cullen Jennings In-Reply-To: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> Date: Fri, 27 Mar 2020 10:10:58 -0600 Cc: "v3@ietf.org" Message-Id: <43DAEFA6-7258-4477-8DD7-65B6FE7E1D5D@iii.ca> References: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3445.104.14) X-Classification-ID: 9b5fb209-1ca6-4228-ba9e-4c1274872065-1-1 Archived-At: Subject: [V3] Centralized conference media X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 16:11:02 -0000 --Apple-Mail=_1269667F-8794-4909-987C-CF24C4464EE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 27, 2020, at 8:23 AM, Magnus Westerlund = wrote: >=20 > I am also very worried that if the model for the media transport is = only point > to point calls then we get something that will become obsolete or at = least need > hacks immediately. This thing need to support centralized conferences = with > cascaded or meshed central media nodes. So I think it is cruical that = one define > the usage model with switched central nodes and have that in mind so = that one > can actually support the applications needed. I think by defining a = strict model > one can actually avoid a lot of feature creep in the media transport.=20= I think it does make sense to support some meta data on a media flow for = centralized conferencing support. What semantic level information do you = think is needed in the media ? --Apple-Mail=_1269667F-8794-4909-987C-CF24C4464EE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Mar 27, 2020, at 8:23 AM, Magnus Westerlund <magnus.westerlund=3D40ericsson.com@dmarc.ietf.org> = wrote:

I am also very worried that if = the model for the media transport is only point
to point calls then we get = something that will become obsolete or at least need
hacks immediately. This thing = need to support centralized conferences with
cascaded or meshed central media = nodes. So I think it is cruical that one define
the usage model with switched = central nodes and have that in mind so that one
can actually support the = applications needed. I think by defining a strict model
one can actually avoid a lot of = feature creep in the media transport. 

I think it does = make sense to support some meta data on a media flow for centralized = conferencing support. What semantic level information do you think is = needed in the media ?



= --Apple-Mail=_1269667F-8794-4909-987C-CF24C4464EE5-- From nobody Fri Mar 27 09:24:54 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631F83A0783 for ; Fri, 27 Mar 2020 09:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 QMbaXg17_HLO for ; Fri, 27 Mar 2020 09:24:47 -0700 (PDT) Received: from smtp88.ord1d.emailsrvr.com (smtp88.ord1d.emailsrvr.com [184.106.54.88]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E6C33A0484 for ; Fri, 27 Mar 2020 09:19:10 -0700 (PDT) X-Auth-ID: fluffy@iii.ca Received: by smtp4.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 4098040108; Fri, 27 Mar 2020 12:19:08 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [50.66.148.85]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Fri, 27 Mar 2020 12:19:08 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_21EC913E-35C6-4463-9068-08200770284A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Cullen Jennings In-Reply-To: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> Date: Fri, 27 Mar 2020 10:19:07 -0600 Cc: "v3@ietf.org" Message-Id: <7028E641-D015-4E2B-BAA3-865B13535912@iii.ca> References: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3445.104.14) X-Classification-ID: 3fb9c469-14cd-470a-bd21-4be7a68fc4fb-1-1 Archived-At: Subject: Re: [V3] High level comments on the RIPT charter and scope X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 16:24:54 -0000 --Apple-Mail=_21EC913E-35C6-4463-9068-08200770284A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 27, 2020, at 8:23 AM, Magnus Westerlund = wrote: >=20 > The third big part is the media transport. I think we need to strongly = consider > if this can be broken out in to it seperate WG. I think the WG we are talking about here is the WG to do media of H3. So = we can talk about other things being in or out of it but that is the = core thing.=20 I would like to point out that one of the design properties that has = been making this easier is that media is self describing. What I mean by = that is that if a device receives media that is one of the supported = formats and within in the limits of that device supports, the media has = all the information the device needs to decode it. No out of band = information needed. That is key to making this easier to deal with HA = and scalability on cloud side. I think that is a good property for = modern designs. We have been going that way for a long time with things = like opus and it works out well.=20 > here are several aspects here. > First of the split in expertise between the media transport and the = signalling > folks.=20 I=E2=80=99m not sure what you mean by signalling but the the singling = here was mostly start media , stop media. It is not call routing, = forking etc that is done by SIP.=20 --Apple-Mail=_21EC913E-35C6-4463-9068-08200770284A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 27, 2020, at 8:23 AM, Magnus Westerlund <magnus.westerlund=3D40ericsson.com@dmarc.ietf.org> = wrote:

The third big part is the media = transport. I think we need to strongly consider
if this can be broken out in to = it seperate WG.

I= think the WG we are talking about here is the WG to do media of H3. So = we can talk about other things being in or out of it but that is the = core thing. 

I would like to = point out that one of the design properties that has been making this = easier is that media is self describing. What I mean by that is that if = a device receives media that is one of the supported formats and within = in the limits of that device supports, the media has all the information = the device needs to decode it. No out of band information needed. That = is key to making this easier to deal with HA and scalability on cloud = side. I think that is a good property for modern designs. We have been = going that way for a long time with things like opus and it works out = well. 

here are = several aspects here.
First of the split in expertise between the media transport = and the signalling
folks. 
I=E2=80=99m not sure what you mean by signalling = but the the singling here was mostly start media , stop media. It is not = call routing, forking etc that is done by SIP. 



= --Apple-Mail=_21EC913E-35C6-4463-9068-08200770284A-- From nobody Fri Mar 27 09:27:49 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FBF3A1604 for ; Fri, 27 Mar 2020 09:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ngNmzLIrFB4j for ; Fri, 27 Mar 2020 09:27:28 -0700 (PDT) Received: from smtp69.ord1d.emailsrvr.com (smtp69.ord1d.emailsrvr.com [184.106.54.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94823A077F for ; Fri, 27 Mar 2020 09:23:47 -0700 (PDT) X-Auth-ID: fluffy@iii.ca Received: by smtp1.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 0564640262; Fri, 27 Mar 2020 12:23:46 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [50.66.148.85]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Fri, 27 Mar 2020 12:23:47 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_F5E04A4E-13A5-4902-A8DE-4BD89A6F06AB" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Cullen Jennings In-Reply-To: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> Date: Fri, 27 Mar 2020 10:23:46 -0600 Cc: "v3@ietf.org" Message-Id: References: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3445.104.14) X-Classification-ID: 69ab0285-d219-4044-9986-2353e9ffba2f-1-1 Archived-At: Subject: [V3] Gateway new to old X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 16:27:44 -0000 --Apple-Mail=_F5E04A4E-13A5-4902-A8DE-4BD89A6F06AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 27, 2020, at 8:23 AM, Magnus Westerlund = wrote: >=20 > The next media transport issue that was barely discussed in the BOF is = the > legacy (RTP) interoperate question. This is going to come back in the = scope > discussion and do needs at least a direction.=20 In WebRTC, we decided to be able to gateway SIP to WebRTC without = processing media. That turned out to be a major limitation to how WebRTC = worked. That is good and we have WebRTC but for this, I am storngly of = the view we should not have that design constraint.=20 I think it is fine to require a media gateway to go from RIPT to RTP. = Sure that should be pretty easy - one of the major use cases for this = work will likely involve building SBCs that talk RIPT on one side and = SIP on the other. Pretty sure that a bunch of other people are thinking = about the same.=20 That sound right to you are or are you arguing for something else ? --Apple-Mail=_F5E04A4E-13A5-4902-A8DE-4BD89A6F06AB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Mar 27, 2020, at 8:23 AM, Magnus Westerlund <magnus.westerlund=3D40ericsson.com@dmarc.ietf.org> = wrote:

The next media transport issue = that was barely discussed in the BOF is the
legacy (RTP) interoperate = question. This is going to come back in the scope
discussion and do needs at least = a direction. 

In WebRTC, we decided to be able to = gateway SIP to WebRTC without processing media. That turned out to be a = major limitation to how WebRTC worked. That is good and we have WebRTC = but for this, I am storngly of the view we should not have that design = constraint. 

I think it is fine to require a media gateway to go from RIPT = to RTP. Sure that should be pretty easy - one of the major use cases for = this work will likely involve building SBCs that talk RIPT on one side = and SIP on the other. Pretty sure that a bunch of other people are = thinking about the same. 

That sound right to you are or are you = arguing for something else ?


= --Apple-Mail=_F5E04A4E-13A5-4902-A8DE-4BD89A6F06AB-- From nobody Fri Mar 27 09:33:02 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBE13A08DB for ; Fri, 27 Mar 2020 09:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 bOT-hhNuzmak for ; Fri, 27 Mar 2020 09:32:57 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 72CFE3A17A1 for ; Fri, 27 Mar 2020 09:28:28 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id a63so6552595vsa.8 for ; Fri, 27 Mar 2020 09:28:28 -0700 (PDT) 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=lGXeg1a8pDbC1YI6i6aYV+XcPM4AFBtbPcjYTDy55U4=; b=iXXDUJa6ZXVeYBN4gabCfizEYlcBfM076NGHM7C0LDgKcj4P1BHvGysc2Hbnl8YgQl SiHntU2XU/mMxWBZCs81yO6GpoljJ+C6xhDK3RVAGITUNUwjCoK5WVkNqSG2Nc24k1p6 Bt8g7zaX81wlID7RMXr5bHKE06NhYM6wFe0tt0tsMCCkVsoIeSY4wCLZ7IqY8wEvgxDn q4NeF9gm2ZD6Rb3myneLDlwLMLunOofCSsEg/ylBjUrIsQDzAVajeIxqpoBdmMT2HVbN FzIIggg0x64VwR+Skakwl9tUtNSUZV9CYLRwUmI0iF/fmcy5YmFL5Wq/fk98z36Czktq lx2A== 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=lGXeg1a8pDbC1YI6i6aYV+XcPM4AFBtbPcjYTDy55U4=; b=jGoCZCYqdyOdv4paDWt3u5fLmTfhjjscrPCNoKyEnebZnWtFT1s1mfggk/uF1BtpuT GIFRTAXT3/tKP/ptrf1ovZ7T7KLHz/xYQlRbmqYj8/N4RebifamWRUPFRgnbqM8ihq5S iqBPclitPTyHw7vDCFP+z3WiKFgtD+ZHSMFDb6noHAu+AUllDdAOoO0h4AsUsN57rVio ZPgQ89KR19b6VQgMA5fKKHkAFuJVneU4EKhJ6t02z2+55oEqNKv+9A4Mulf28LJWX0Kj wIwuZVZVLb/RpONBzTZKbwHesKZM2GyeF2LL0NsR2MCF4hFzxQ4g8adbzQnUxSLh+5UQ Mdnw== X-Gm-Message-State: ANhLgQ3F1xVp0hxFYryDao8T7avC9NmBNw5hQ0JwFK9P37crP9Lpgzve mklZvYxi7LnzGn241lVGbP9RipPVleKFzXPISzCfPDQE X-Google-Smtp-Source: ADFU+vsy30LFFcVRLJYSbZlDYgLIhBxVa46lSyhu3W4EnqZAsm7jzdQILZPbksvMADIExbutX+No4AOlqsM/o6QCCAU= X-Received: by 2002:a67:ec81:: with SMTP id h1mr10355767vsp.96.1585326506946; Fri, 27 Mar 2020 09:28:26 -0700 (PDT) MIME-Version: 1.0 References: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> <43DAEFA6-7258-4477-8DD7-65B6FE7E1D5D@iii.ca> In-Reply-To: <43DAEFA6-7258-4477-8DD7-65B6FE7E1D5D@iii.ca> From: Justin Uberti Date: Fri, 27 Mar 2020 09:28:15 -0700 Message-ID: To: Cullen Jennings Cc: Magnus Westerlund , "v3@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004d37c005a1d8978d" Archived-At: Subject: Re: [V3] Centralized conference media X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 16:33:00 -0000 --0000000000004d37c005a1d8978d Content-Type: text/plain; charset="UTF-8" I think Magnus is trying to establish the conference topology, which has ramifications on how we want to handle things like RTCP. One strawman could be to focus on RTCP-terminating SFUs, i.e., cementing the notion that RIPT media flows are indeed point-to-point (i.e., client-to-SFU, as opposed to client-to-client1, client2, client3). On Fri, Mar 27, 2020 at 9:11 AM Cullen Jennings wrote: > > > On Mar 27, 2020, at 8:23 AM, Magnus Westerlund < > magnus.westerlund=40ericsson.com@dmarc.ietf.org> wrote: > > I am also very worried that if the model for the media transport is only > point > to point calls then we get something that will become obsolete or at least > need > hacks immediately. This thing need to support centralized conferences with > cascaded or meshed central media nodes. So I think it is cruical that one > define > the usage model with switched central nodes and have that in mind so that > one > can actually support the applications needed. I think by defining a strict > model > one can actually avoid a lot of feature creep in the media transport. > > > I think it does make sense to support some meta data on a media flow for > centralized conferencing support. What semantic level information do you > think is needed in the media ? > > > > -- > V3 mailing list > V3@ietf.org > https://www.ietf.org/mailman/listinfo/v3 > --0000000000004d37c005a1d8978d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think Magnus is trying to establish the conference topol= ogy, which has ramifications on how we want to handle things like RTCP.
One strawman could be to focus on RTCP-terminating SFUs, i.= e., cementing the notion that RIPT media flows are indeed point-to-point (i= .e., client-to-SFU, as opposed to client-to-client1, client2, client3).

On Fri, Mar 27, 2020 at 9:11 AM Cullen Jennings <fluffy@iii.ca> wrote:
--
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3
--0000000000004d37c005a1d8978d-- From nobody Fri Mar 27 13:22:49 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFF03A0F6B for ; Fri, 27 Mar 2020 13:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 5-jm0rnpAedn for ; Fri, 27 Mar 2020 13:22:36 -0700 (PDT) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 C14F43A0FB8 for ; Fri, 27 Mar 2020 13:22:20 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id x206so7072168vsx.5 for ; Fri, 27 Mar 2020 13:22:20 -0700 (PDT) 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=PpinHgG05xSUoUSPRxcwQal2/AV77vchLZM1LdYsT/U=; b=BF1BJQB5I3ceDmXJhF9Dzg3uyziaWwYUYrIh2tLzv4F1rOhrETGGDmqcRmaldLAfxx JZHAG1AxWBL0g3HEB+4dG2cZXH8P72CT5EUHQslCgeX8yVxVrri9az8HQQG75Ym8G5tb IgEzvPP1zHus2G5tVabKm5Rb4M5joS72oWTPStMOxbnCPYOiI+lBAhIDMIl0d8J5zwI3 b2LOX76UK1Y5rg7KJtxQbGJ+6KuPYPEhskrA9bwh636AzbJBQIUi8Ukiv29JVpR1eJMF aIKz1fC0hlJUwetclJGP3hvRGde9i7Q34Y3bpFX1jGDO7A4xZ8btoX4A1qBqhjjmdXUZ luZQ== 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=PpinHgG05xSUoUSPRxcwQal2/AV77vchLZM1LdYsT/U=; b=OGeCY9DC26ysGCa6NyoT7WdVD0eMwjHyQOokJ6N8tz8qRV4lKDmg5I5q1IVqA8I8q2 NbVXPzlmfklxWTqNK6ShWFga1jLVWZQ76ZgP5N6RtI3ucK/5GjkEzN8SNxm4pmYwng31 Im56I41X/7fpUtwLv7EC5LovD5hUUayfvdtfFo/DOTQ1rJiWBxHW9Me6CIQRFu/JhRxC 8LUlKeOx1F59w9drZ8TqJfe6uD7N53EuYXouGGvxcRoE6BrmxLTNTHDmD0t4D0dC67PE ykKyrc64PaRazYiL/HexdpoMKPM2AIsQuMkM8RdAU7jzpx7YAR0hd48HTJc55J1VNMP0 RBwg== X-Gm-Message-State: AGi0PuYjTkHCgqNCrfd7lHCBnEl5+5nmbeS3+fYhMCFs2tt6TvvdUigX g7yk0D+cUncJNHv0ffQkgOWMjfgGPvce3DkeMHUBUA== X-Google-Smtp-Source: APiQypK/XcjHrCAwHf3+bOwEXp0ZeOjCJOa5tqqshJ95paMJ6Lu7Rxpy6ZSyFIGPm1Tn1I0UrCV/2CtfPkuh1iLaQMw= X-Received: by 2002:a67:ec81:: with SMTP id h1mr622303vsp.96.1585340539299; Fri, 27 Mar 2020 13:22:19 -0700 (PDT) MIME-Version: 1.0 References: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> In-Reply-To: From: Justin Uberti Date: Fri, 27 Mar 2020 13:22:07 -0700 Message-ID: To: Cullen Jennings Cc: Magnus Westerlund , "v3@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b1f1b605a1dbdb75" Archived-At: Subject: Re: [V3] Gateway new to old X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 20:22:48 -0000 --000000000000b1f1b605a1dbdb75 Content-Type: text/plain; charset="UTF-8" It's hard to imagine that we can avoid this if we are in fact going to use H3 as a substrate. I do think it would be useful to ensure the RIPT->RTP gateway can be stateless and transparent (i.e., you can transform a RIPT frame into a RTP packet with reasonable fidelity), so that said gateway is all you need in order for existing services to participate in the RIPT ecosystem. On Fri, Mar 27, 2020 at 9:32 AM Cullen Jennings wrote: > > > On Mar 27, 2020, at 8:23 AM, Magnus Westerlund < > magnus.westerlund=40ericsson.com@dmarc.ietf.org> wrote: > > The next media transport issue that was barely discussed in the BOF is the > legacy (RTP) interoperate question. This is going to come back in the scope > discussion and do needs at least a direction. > > > In WebRTC, we decided to be able to gateway SIP to WebRTC without > processing media. That turned out to be a major limitation to how WebRTC > worked. That is good and we have WebRTC but for this, I am storngly of the > view we should not have that design constraint. > > I think it is fine to require a media gateway to go from RIPT to RTP. Sure > that should be pretty easy - one of the major use cases for this work will > likely involve building SBCs that talk RIPT on one side and SIP on the > other. Pretty sure that a bunch of other people are thinking about the > same. > > That sound right to you are or are you arguing for something else ? > > > -- > V3 mailing list > V3@ietf.org > https://www.ietf.org/mailman/listinfo/v3 > --000000000000b1f1b605a1dbdb75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's hard to imagine that we can avoid this if we are = in fact going to use H3 as a substrate.=C2=A0

I do think= it would be useful to ensure the RIPT->RTP gateway can be stateless and= transparent (i.e., you can transform a RIPT frame into a RTP packet with r= easonable fidelity), so that said gateway is all you need in order for exis= ting services to participate=C2=A0in the RIPT ecosystem.

On Fri, Mar 2= 7, 2020 at 9:32 AM Cullen Jennings <flu= ffy@iii.ca> wrote:


On Mar 27, 2020, at 8:23 AM, Magnus Westerlund <magnus.westerlund=3D40ericsson.com@dmarc.ietf.org> wrote= :

The next me= dia transport issue that was barely discussed in the BOF is the
legacy (RTP)= interoperate question. This is going to come back in the scope
discussion a= nd do needs at least a direction.=C2=A0

In WebRTC, we decided to be able to gateway SIP to WebRTC= without processing media. That turned out to be a major limitation to how = WebRTC worked. That is good and we have WebRTC but for this, I am storngly = of the view we should not have that design constraint.=C2=A0

=
I think it is fine to require a media gateway to go from RIPT to= RTP. Sure that should be pretty easy - one of the major use cases for this= work will likely involve building SBCs that talk RIPT on one side and SIP = on the other. Pretty sure that a bunch of other people are thinking about t= he same.=C2=A0

That sound right to you are or are = you arguing for something else ?


-= -
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3
--000000000000b1f1b605a1dbdb75-- From nobody Fri Mar 27 15:35:55 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B3C3A0D84 for ; Fri, 27 Mar 2020 15:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 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 L1XW4nUVj1az for ; Fri, 27 Mar 2020 15:35:43 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2042.outbound.protection.outlook.com [40.107.21.42]) (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 758F43A0CE3 for ; Fri, 27 Mar 2020 15:35:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FZHja3E0UlBcCyk775Ed4snc2Lcug72nhe8uSS9NqnJVQ+tREBUrRuPkvaVIenhqrTBIHJasXv5mMdQTqOXCMMYv3oNdDJB9SglP3Ci2DvOBbNljtqtQ9n74Bs/ie2EABYNd1PULj4ZcsklyWZ6q5aKXN+SmNhI5tr3R8rY04V7W145LqYlUbf0kdcH3vT8DUj7HmcopT7NSm6IlDt+WxTwl0aZ+PpGU2AfgwixgbbLSU82mER9sXbEYqC48/8WntirvO7pXlYDgYFf+Y4TzfX3Dv/rf2fqz7+gTGHIvRm+g3eHvaZ0FiBe89gSv4PlQ27PdyMWtuDxn+eiYG+BvMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8XgGv4pHdA4d0u8CFJlSJUx8+LroVgSMlTS6bBsKHxM=; b=CAZqIx9AuScMSJe0++yTJT0aTPz4aTMKd3A0J8MWCZEVdHyK7hZvA+Q1NNU3HCDKknj8b4FoDIFVjqZW3O+I3/Kb/kmLLHjLcDEz3pgNDvbyzHJayvPvL5x8Ptagn6gWOrY0vBRTYkd5+nAJwxP7dMYg56MGIS/v73OjaqJmIUVPyQuQhC5jcBqgI+C+RviTWu0RAtrKcM5fS/gKP9bkqN7HJ18r79CnkINowwD1qDa42f9Pe5r79b9jiBpy2Wx+2MlZgJyptcaEqVMujgoLv1HFeuq07mahgAz1GE30XARGYM6hytm1SimuGVOPRCll5r03dTpjLV9AzA+Mf80quA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=8XgGv4pHdA4d0u8CFJlSJUx8+LroVgSMlTS6bBsKHxM=; b=Tf9z7dwbvxgZ1PfZtqT6rSSPi/LR/uMjyNDBTJsnXsNYX2GrJOhiDckUB1nDzZLEGa/0RknS3PORlmdYxQZNqWuX6YAPHphwXP/K6LNY8Su39iefrzuiz34zrhfTs/RNbZX0cdKM54uaV6SHD0WFN3rtLRGCzD+8R45h9MTuonA= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (52.133.7.14) by HE1PR0702MB3529.eurprd07.prod.outlook.com (10.167.127.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.15; Fri, 27 Mar 2020 22:35:40 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8bd:85b0:d547:9eed]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8bd:85b0:d547:9eed%6]) with mapi id 15.20.2856.018; Fri, 27 Mar 2020 22:35:40 +0000 From: Magnus Westerlund To: "juberti=40google.com@dmarc.ietf.org" , "fluffy@iii.ca" CC: "v3@ietf.org" Thread-Topic: [V3] Centralized conference media Thread-Index: AQHWBFJWG0bO+pRsckSnNW6fjLLU26hcoMmAgABmp4A= Date: Fri, 27 Mar 2020 22:35:39 +0000 Message-ID: <3c2943c636663908da232674719abbf6c7ea7918.camel@ericsson.com> References: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> <43DAEFA6-7258-4477-8DD7-65B6FE7E1D5D@iii.ca> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1 authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [158.174.118.23] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3eafd39e-ab35-4636-ea35-08d7d29f2d78 x-ms-traffictypediagnostic: HE1PR0702MB3529: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1079; x-forefront-prvs: 0355F3A3AE x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(396003)(366004)(136003)(39860400002)(346002)(44832011)(966005)(71200400001)(64756008)(2616005)(5660300002)(76116006)(6512007)(186003)(36756003)(66946007)(26005)(66556008)(478600001)(66616009)(66476007)(81156014)(6506007)(8936002)(81166006)(8676002)(86362001)(110136005)(6486002)(4326008)(316002)(2906002)(66446008)(53546011)(99106002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8J/Zzqa8MA1Lpf6965GSBjceMwpKa98dnyx9Ey3L9cB/uh7ZPgEaTPs9j8bs4uiYBtizlhgreDRHO7vV6u9w0OWKWI+590p4A9VaO78LJ3Yxjeg+eHXLDZnY+11yxRbu/r/ft+4bYoK1Vf7enM0lbYmDQbinc2MDGVwm2mxT5aOp2aEbKf1jUGhyogDn1p2al+NFO74P6xlUF7l4Oa3NowVCANZRJB4/3gkmMny/p/ljoyXTt+xyErYVVbp269ZkO0grPSQ7fk0y8nxctxaZnMqHVnoyeCpEkgNBf+x+KJH4MN7k/EwL+YAYQfpQEo32FAp0bwQmueSy9/VYVm44g0vHRvMrj2uWP2JbexVWWKyI2Lf8k8ne/LQS3ViM8HghassLBrQYBXWyQmS8Ueouy/XIJdylIaZ7/oIR/8Gi/XH7UjWMgRF6ie/4Rr1Jgwj/exKFHfGHSzIOfL0bTGYJFmatn4mKZLRK7VuZpYrIpX5qqlU82zaOgA1RlYmQjTf6ogtjaD69xcl2ugKrYRbgJdoy5DFO74q9uBDAoUy0D1lMbnV85Ka61BL45/I/5fjs x-ms-exchange-antispam-messagedata: jG/pJanvicMj5keAlBJgvmm45yWTz+sGEyyfPZ+ugWcHD16FeI4zj3Wr5IdcKzjRQ4VegP/3BoapnT6MmMR3sh4aZdCD+KfysLjWdT7jbhfkVka9cmjiJ0wC1ln9EV/cFoeowSj586UeDv56D2Cxtg== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-anGFtqim255BViDXwg8h" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3eafd39e-ab35-4636-ea35-08d7d29f2d78 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2020 22:35:39.9507 (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-CrossTenant-userprincipalname: Bx9huQWXIlDvLeiAfbe2lbGCp6631GwadwHDLVnn7RB9B22MBEDimglaySf69ES4kGwlKOA4FXebVmMIWif8VnH/Sm85aDqpNTrYq82QhXY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3529 Archived-At: Subject: Re: [V3] Centralized conference media X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 22:35:54 -0000 --=-anGFtqim255BViDXwg8h Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, So yes, I think there are the aspect of the topology as well as how one han= dle the media related controll messages, i.e. the equivalent of RTCP. For examp= le things like FIR, PAUSE/Resume.=20 So, if one with RTCP terminating middleboxes means that the ID spaces are s= oley locally that could be a choice. I will note that in some cases one still ne= ed to have the complete set of media sources from all end-points in a conference = be identified at a specific point to point leg. Even if only a subset is curre= ntly transmitted over this leg. There are both benefits and downsides I think of using a local namespace and having each node translate these. I will note that one may still need to have end-to-end identies on media AD= Us if one are going to have any end-to-end security.=20 Cheers Magnus Westerlund On Fri, 2020-03-27 at 09:28 -0700, Justin Uberti wrote: > I think Magnus is trying to establish the conference topology, which has > ramifications on how we want to handle things like RTCP. >=20 > One strawman could be to focus on RTCP-terminating SFUs, i.e., cementing = the > notion that RIPT media flows are indeed point-to-point (i..e., client-to-= SFU, > as opposed to client-to-client1, client2, client3). >=20 > On Fri, Mar 27, 2020 at 9:11 AM Cullen Jennings wrote: > >=20 > > > On Mar 27, 2020, at 8:23 AM, Magnus Westerlund < > > > magnus.westerlund=3D40ericsson.com@dmarc.ietf.org> wrote: > > >=20 > > > I am also very worried that if the model for the media transport is o= nly > > > point > > > to point calls then we get something that will become obsolete or at = least > > > need > > > hacks immediately. This thing need to support centralized conferences= with > > > cascaded or meshed central media nodes. So I think it is cruical that= one > > > define > > > the usage model with switched central nodes and have that in mind so = that > > > one > > > can actually support the applications needed. I think by defining a s= trict > > > model > > > one can actually avoid a lot of feature creep in the media transport.= =20 > >=20 > > I think it does make sense to support some meta data on a media flow fo= r > > centralized conferencing support. What semantic level information do yo= u > > think is needed in the media ? > >=20 > >=20 > >=20 > > --=20 > > V3 mailing list > > V3@ietf.org > > https://www.ietf.org/mailman/listinfo/v3 --=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-anGFtqim255BViDXwg8h Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDMyNzIyMzUzOVowLwYJKoZIhvcN AQkEMSIEIILWvRl0DLEzTEYlNVwLW/lvEXUP4XxUU8NGVG2XmYkdMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAZw5eiunKMtDi krU5o/5GPbAOE9T/nvv8UAbj8iZjPh+iJx7+D9YXoJGTxUehnHGKATgsYVW6PKjfG9swdNejfuoZ IPXVxVIQ/2cAqpevGGxZ4kuOiC1tvvEwZ5TeQcoWcVdDOmlyAX4qZl3dt/2kzPkkP1RS0/v0WKXx e788sLhCEQUZoVH3rVlmscgLzJUXEn2ys144FLadEzhHmfXx2tsMHXtV1Zh4crQ7QIsMmkkaSAQv EljPAi0Px4b5qwOQ5T8eMEdEx5J8VfK3ZhuFW2iZABK5pHDSqo+W7df70lAfmQFS3zWfLqQHlQEV g6rYUnO6yElRqkldka0G2nGLeAAAAAAAAA== --=-anGFtqim255BViDXwg8h-- From nobody Sun Mar 29 15:05:59 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63693A0DEB for ; Sun, 29 Mar 2020 15:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 fIV5vmoZ99LV for ; Sun, 29 Mar 2020 15:05:56 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 F37343A0DEE for ; Sun, 29 Mar 2020 15:05:55 -0700 (PDT) Received: from [81.187.2.149] (port=44574 helo=[192.168.0.80]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jIg3w-0002UZ-9z; Sun, 29 Mar 2020 23:05:52 +0100 From: Colin Perkins Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B3625465-9EE6-4875-A2D6-955C0D79B77B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Sun, 29 Mar 2020 23:05:43 +0100 In-Reply-To: Cc: Cullen Jennings , Magnus Westerlund , "v3@ietf.org" To: Justin Uberti References: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> X-Mailer: Apple Mail (2.3445.104.14) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [V3] Gateway new to old X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 22:05:58 -0000 --Apple-Mail=_B3625465-9EE6-4875-A2D6-955C0D79B77B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It may be a reasonable goal to aim to re-use RTP payload formats as the = media packetisation within the new transport. That is, different headers = and transport, but format the media content the same way. Since payload format packetisation already all have registered media = types this would make the media content easy to identify, and save a lot = of work in re-defining packetisation schemes. Colin > On 27 Mar 2020, at 20:22, Justin Uberti = wrote: >=20 > It's hard to imagine that we can avoid this if we are in fact going to = use H3 as a substrate.=20 >=20 > I do think it would be useful to ensure the RIPT->RTP gateway can be = stateless and transparent (i.e., you can transform a RIPT frame into a = RTP packet with reasonable fidelity), so that said gateway is all you = need in order for existing services to participate in the RIPT = ecosystem. >=20 > On Fri, Mar 27, 2020 at 9:32 AM Cullen Jennings > wrote: >=20 >=20 >> On Mar 27, 2020, at 8:23 AM, Magnus Westerlund = > wrote: >>=20 >> The next media transport issue that was barely discussed in the BOF = is the >> legacy (RTP) interoperate question. This is going to come back in the = scope >> discussion and do needs at least a direction.=20 >=20 > In WebRTC, we decided to be able to gateway SIP to WebRTC without = processing media. That turned out to be a major limitation to how WebRTC = worked. That is good and we have WebRTC but for this, I am storngly of = the view we should not have that design constraint.=20 >=20 > I think it is fine to require a media gateway to go from RIPT to RTP. = Sure that should be pretty easy - one of the major use cases for this = work will likely involve building SBCs that talk RIPT on one side and = SIP on the other. Pretty sure that a bunch of other people are thinking = about the same.=20 >=20 > That sound right to you are or are you arguing for something else ? >=20 >=20 > --=20 > V3 mailing list > V3@ietf.org > https://www.ietf.org/mailman/listinfo/v3 = > --=20 > V3 mailing list > V3@ietf.org > https://www.ietf.org/mailman/listinfo/v3 --Apple-Mail=_B3625465-9EE6-4875-A2D6-955C0D79B77B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
It may be a reasonable goal to aim to re-use RTP payload = formats as the media packetisation within the new transport. That is, = different headers and transport, but format the media content the same = way.

Since = payload format packetisation already all have registered media types = this would make the media content easy to identify, and save a lot of = work in re-defining packetisation schemes.

Colin



On 27 = Mar 2020, at 20:22, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:

It's hard to imagine that we can avoid this if we are in fact = going to use H3 as a substrate. 

I do think it would be useful to ensure = the RIPT->RTP gateway can be stateless and transparent (i.e., you can = transform a RIPT frame into a RTP packet with reasonable fidelity), so = that said gateway is all you need in order for existing services to = participate in the RIPT ecosystem.

On Fri, Mar = 27, 2020 at 9:32 AM Cullen Jennings <fluffy@iii.ca> wrote:


On Mar = 27, 2020, at 8:23 AM, Magnus Westerlund <magnus.westerlund=3D40ericsson.com@dmarc.ietf.org> = wrote:

The next media = transport issue that was barely discussed in the BOF is the
legacy (RTP) = interoperate question. This is going to come back in the scope
discussion and = do needs at least a direction. 

In WebRTC, we decided to be able to gateway = SIP to WebRTC without processing media. That turned out to be a major = limitation to how WebRTC worked. That is good and we have WebRTC but for = this, I am storngly of the view we should not have that design = constraint. 

I think it is fine to require a media gateway to go from RIPT = to RTP. Sure that should be pretty easy - one of the major use cases for = this work will likely involve building SBCs that talk RIPT on one side = and SIP on the other. Pretty sure that a bunch of other people are = thinking about the same. 

That sound right to you are or are you = arguing for something else ?


--
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3
--
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3

= --Apple-Mail=_B3625465-9EE6-4875-A2D6-955C0D79B77B-- From nobody Mon Mar 30 06:16:49 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111A93A15AE for ; Mon, 30 Mar 2020 06:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 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 zIIjpsgHjs9v for ; Mon, 30 Mar 2020 06:16:47 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on20622.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1a::622]) (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 F37A93A15AD for ; Mon, 30 Mar 2020 06:16:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZLdM305jLOGe+gp4nBE+AHR6JL+mWRRwFRHF93hpN/0aPumHO3pfQuNrgBLqt1754g2JOVcOx0GtVM2LN++UWut/OLzRJnRSM4zHhKCozo8gebO2OMqOSi3SL2jTVjWurvBbZTzXJLdIfFE+pWiMP4Xkq2drWxrrP6l0uSAlPE/iXvxsLmxnIwLyxHRNPtto3QHYVN5VN8n4fZutqq6W9YxAiQXIuSLQqeUlaTj1G7LWpCs1dU5ALO7J9PSBnfR5BDDPUJ4OU9gZEhH+nRLVH1DcWSn8dc71fy77diOqXr/FhtnIkF81qhJlWnsGfWJAH2OsWTCqji5qh/fdcOot8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q98Z9Mplg05+hYIyxHcYwTEe13rwbTNQIx5wSMcy8pQ=; b=Gpcf/sx/RLRJUCjGGziu9M4OzmFStbpWm57UbfSm9KHTy0mGpptxnE45zNEDI78lq0C1lWgbjjWIwberGvEkJFl+YcgI+mgQmROP0Og3I6ePQM7V3Zua2/1MyJGewSE3kzClB+WW3nqeZoWt8C9pC17N6BhIHitemrEyz1vGTVgZctCV1b01kBolavnFbQu7Oo4DVCPxZ493vBEUuApsw/OKBMMRaE1ZBu/vaEJL4xvaVJ6d85ytMp7G0xEIYnvGPva+T/vHTfV7nH+oqj+7+OqCi9VQACJWBLPN+qQbKZia3h8DqfLcBaVwKT7sIIpxA6As7yQGlum49NQy9s7eQw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=Q98Z9Mplg05+hYIyxHcYwTEe13rwbTNQIx5wSMcy8pQ=; b=FOpJEC9qilmMrPa71fPwLxw1F1CFAvSMOfWY8ntJVYCE3Z9l3IEStoG/fySDhc+uqbP+33P2lcDLwg3JKqMiQJ5Fji1PIdOWcJjkfvoh5k5TKIOYUTI2sTTmdyblNJ4QUeZf5Ynfj/2qXWzKAl/rHAXVaC5WenKJZXkFkuqqp+c= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (52.133.7.14) by HE1PR0702MB3690.eurprd07.prod.outlook.com (10.167.35.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.12; Mon, 30 Mar 2020 13:16:44 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8bd:85b0:d547:9eed]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8bd:85b0:d547:9eed%6]) with mapi id 15.20.2856.018; Mon, 30 Mar 2020 13:16:44 +0000 From: Magnus Westerlund To: "juberti@google.com" , "csp@csperkins.org" CC: "v3@ietf.org" , "fluffy@iii.ca" Thread-Topic: [V3] Gateway new to old Thread-Index: AQHWBFVSXOX482LXA0SXiiRX6Tm1mqhc4huAgANBm4CAAP6CAA== Date: Mon, 30 Mar 2020 13:16:44 +0000 Message-ID: References: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1 authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [158.174.118.23] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e0533011-a791-41db-2932-08d7d4ac97e4 x-ms-traffictypediagnostic: HE1PR0702MB3690: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:608; x-forefront-prvs: 0358535363 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(39860400002)(366004)(396003)(376002)(346002)(2906002)(966005)(478600001)(2616005)(44832011)(86362001)(4326008)(5660300002)(6512007)(54906003)(316002)(71200400001)(6486002)(186003)(6506007)(53546011)(110136005)(8936002)(26005)(36756003)(8676002)(81156014)(81166006)(64756008)(99936003)(66446008)(66616009)(76116006)(66946007)(66476007)(66556008)(99106002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XClM3OXsRa+B0gf0M3a5iAyuQyfd3NBugnDmSwt/j9MdBijWUu0LlEIL2ust71ShAXTPEcAggatYwE4sdQ1qtMCCHp5I0qUAFiEnuKmwKoa8YP8hfE/BsRMHhvVOiWMt7tcf8jVuQESTP/ZylfmnYb+a43C6jsgzmtjHbtTuM39hP1wbdVWWup2MT1RKi/TCemgQBiYq7UOlb8/jtoZtUpbgVSUEIMxgemFNUP+N+MIp4L08X1XUXGZMiv7ZIa0qhOmye3sJXw/smJE5dwgRc9KyAycmZDUnaqsj4d5lirVEcgh1OAWZtctVQ6cvZe6vvvZu4UWmZoLc4sr6zV5KDRuoIibWXCoR/R1WgKbLUZXFerWiV20vu9dSRQQcQqXDSK4gp2AlrRNqlLzUM47a2QfuCAHZs/LZDDX2Th6cWWXfgo/d0uf98yZ+xzQ4sPDB3b7UTDVdFSHXgZ312rycd53S5Z8mZv3Oi9DyLqj2IswWbiZ53vF/12Iisns928tR9c6uKaDQtB7HdfDBo5/JUEVf+z0FQ6uN7OnVDd7WghJ77yFI73lni/E2VC/Tu9m4 x-ms-exchange-antispam-messagedata: 7ozTUq4kgBp55xwsxwO/DoQn3NqbQWk4WywpH5/AI9e5sgrOHA/pL+CL7GQpERTjcMGs0SAALM8l1K52TudbJlgFBHY1ahm8Iy8I2WKBOQ54US8gLuU7Z5ubnhRsp2nxxZSlvA1k2qyCz5cwuL7DIA== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-PZa23dzUX/BmhQo+tnz1" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e0533011-a791-41db-2932-08d7d4ac97e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2020 13:16:44.2401 (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-CrossTenant-userprincipalname: hQO7N3NfNgepoqj/eEd9aUT9QgEe+xp16R1xYEyz5WSqMsSzgAlKDkvZTJ/JyHP13f5D4Xh8ur18R4sBz5bunQ9Z17yJ4/cjfCmacpzNgLQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3690 Archived-At: Subject: Re: [V3] Gateway new to old X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 13:16:49 -0000 --=-PZa23dzUX/BmhQo+tnz1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, (Still as invidual) Attempting to answer Cullen's question I think there are significant points= in trying to actually enabling the utilization of the advantages this redefini= tion can enable. For example to me it appears that one should ensure that the me= dia transport becomes more ADU focused rather than packet focused. With 1080p o= r 4K video in good quality the number of 1400 bytes packets needed to carry a si= ngle frame are more in the range of hundreds than in single digit. I think one s= hould try to ensure that this work as well as possible. Thus semi-reliable head o= f line blocking free transport of whole ADUs becomes of more interest.=20 I think there is a point to re-use the RTP payload format. If one has such support in the end-point one can use the RTP payload fragmentation when nee= ded for interconnect with RTP systems and not use it if one can rely on QUIC+RI= PT primitives. Reusing RTP payload formats also have the advantage of avoiding= to have to redefine all the codecs of interest. Cheers Magnus Westerlund On Sun, 2020-03-29 at 23:05 +0100, Colin Perkins wrote: > It may be a reasonable goal to aim to re-use RTP payload formats as the m= edia > packetisation within the new transport. That is, different headers and > transport, but format the media content the same way. >=20 > Since payload format packetisation already all have registered media type= s > this would make the media content easy to identify, and save a lot of wor= k in > re-defining packetisation schemes. >=20 > Colin >=20 >=20 >=20 > > On 27 Mar 2020, at 20:22, Justin Uberti > > wrote: > >=20 > > It's hard to imagine that we can avoid this if we are in fact going to = use > > H3 as a substrate.=20 > >=20 > > I do think it would be useful to ensure the RIPT->RTP gateway can be > > stateless and transparent (i.e., you can transform a RIPT frame into a = RTP > > packet with reasonable fidelity), so that said gateway is all you need = in > > order for existing services to participate in the RIPT ecosystem. > >=20 > > On Fri, Mar 27, 2020 at 9:32 AM Cullen Jennings wrote: > > >=20 > > > > On Mar 27, 2020, at 8:23 AM, Magnus Westerlund < > > > > magnus.westerlund=3D40ericsson.com@dmarc.ietf.org> wrote: > > > >=20 > > > > The next media transport issue that was barely discussed in the BOF= is > > > > the > > > > legacy (RTP) interoperate question. This is going to come back in t= he > > > > scope > > > > discussion and do needs at least a direction.=20 > > >=20 > > > In WebRTC, we decided to be able to gateway SIP to WebRTC without > > > processing media. That turned out to be a major limitation to how Web= RTC > > > worked. That is good and we have WebRTC but for this, I am storngly o= f the > > > view we should not have that design constraint.=20 > > >=20 > > > I think it is fine to require a media gateway to go from RIPT to RTP.= Sure > > > that should be pretty easy - one of the major use cases for this work= will > > > likely involve building SBCs that talk RIPT on one side and SIP on th= e > > > other. Pretty sure that a bunch of other people are thinking about th= e > > > same.=20 > > >=20 > > > That sound right to you are or are you arguing for something else ? > > >=20 > > >=20 > > > --=20 > > > V3 mailing list > > > V3@ietf.org > > > https://www.ietf.org/mailman/listinfo/v3 > >=20 > > --=20 > > V3 mailing list > > V3@ietf.org > > https://www.ietf.org/mailman/listinfo/v3 >=20 >=20 --=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-PZa23dzUX/BmhQo+tnz1 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDMzMDEzMTY0M1owLwYJKoZIhvcN AQkEMSIEIHjhE7dliCchFnfOiGkrh/IEopIdmzRPcTHv9FYm4yJaMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEArqv5JzK4AHeu t1XOAJdsdxHXvMy760jPb/BSDnkrv7bIcGBKX2LhzMxIzn85pLVJmW2T+AzOsGLfDN4rSs5Zrc3u XEvqzrAVTwX6a4oDTk2iaPolHrrd67wF5C2CfD5RF/uJlGBh/1A9l3r5hExcADF1UuEEFdSZRcl9 iqcRsSw6+qPhVMGDvapR+Bj83Y4zuY8bIluG+ogTJ0hnyfeHvmIqFwHbRIEJKoFKxEVuTk230w6Y IP+FyuCTSAEEdFLqBbecqQhCt5HaQrxvgQxw1zdoVPkcA0KfcScoj5nIqo1MFvKU3Qe634zvG9ko 6MjsCTSUsWF71EKVMklUAGmMNwAAAAAAAA== --=-PZa23dzUX/BmhQo+tnz1-- From nobody Mon Mar 30 06:23:40 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE493A15BB for ; Mon, 30 Mar 2020 06:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 LRcKhC8AV_v5 for ; Mon, 30 Mar 2020 06:23:36 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.in.tum.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36E5B3A15B9 for ; Mon, 30 Mar 2020 06:23:35 -0700 (PDT) Received: by mail.in.tum.de (Postfix, from userid 107) id D434D1C081B; Mon, 30 Mar 2020 15:23:33 +0200 (CEST) Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id 733B21C07F7; Mon, 30 Mar 2020 15:23:30 +0200 (CEST) (Extended-Queue-bit tech_omcif@fff.in.tum.de) To: Magnus Westerlund , "juberti@google.com" , "csp@csperkins.org" Cc: "v3@ietf.org" , "fluffy@iii.ca" References: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> From: Joerg Ott Message-ID: Date: Mon, 30 Mar 2020 15:23:27 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.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: [V3] Gateway new to old X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 13:23:38 -0000 Hi, one should add that the payload formats are mostly not overly complex and their design is defined by the needs of the codecs -- plus mapping to an unreliable packet transport. The codecs don't change and the unreliability still holds with QUIC underneath. So, there would seem to be little gain to begin with in attempting to redo all of this. Cheers, Jörg On 30.03.20 15:16, Magnus Westerlund wrote: > Hi, > > (Still as invidual) > > Attempting to answer Cullen's question I think there are significant points in > trying to actually enabling the utilization of the advantages this redefinition > can enable. For example to me it appears that one should ensure that the media > transport becomes more ADU focused rather than packet focused. With 1080p or 4K > video in good quality the number of 1400 bytes packets needed to carry a single > frame are more in the range of hundreds than in single digit. I think one should > try to ensure that this work as well as possible. Thus semi-reliable head of > line blocking free transport of whole ADUs becomes of more interest. > > I think there is a point to re-use the RTP payload format. If one has such > support in the end-point one can use the RTP payload fragmentation when needed > for interconnect with RTP systems and not use it if one can rely on QUIC+RIPT > primitives. Reusing RTP payload formats also have the advantage of avoiding to > have to redefine all the codecs of interest. > > Cheers > > Magnus Westerlund > > > On Sun, 2020-03-29 at 23:05 +0100, Colin Perkins wrote: >> It may be a reasonable goal to aim to re-use RTP payload formats as the media >> packetisation within the new transport. That is, different headers and >> transport, but format the media content the same way. >> >> Since payload format packetisation already all have registered media types >> this would make the media content easy to identify, and save a lot of work in >> re-defining packetisation schemes. >> >> Colin >> >> >> >>> On 27 Mar 2020, at 20:22, Justin Uberti >>> wrote: >>> >>> It's hard to imagine that we can avoid this if we are in fact going to use >>> H3 as a substrate. >>> >>> I do think it would be useful to ensure the RIPT->RTP gateway can be >>> stateless and transparent (i.e., you can transform a RIPT frame into a RTP >>> packet with reasonable fidelity), so that said gateway is all you need in >>> order for existing services to participate in the RIPT ecosystem. >>> >>> On Fri, Mar 27, 2020 at 9:32 AM Cullen Jennings wrote: >>>> >>>>> On Mar 27, 2020, at 8:23 AM, Magnus Westerlund < >>>>> magnus.westerlund=40ericsson.com@dmarc.ietf.org> wrote: >>>>> >>>>> The next media transport issue that was barely discussed in the BOF is >>>>> the >>>>> legacy (RTP) interoperate question. This is going to come back in the >>>>> scope >>>>> discussion and do needs at least a direction. >>>> >>>> In WebRTC, we decided to be able to gateway SIP to WebRTC without >>>> processing media. That turned out to be a major limitation to how WebRTC >>>> worked. That is good and we have WebRTC but for this, I am storngly of the >>>> view we should not have that design constraint. >>>> >>>> I think it is fine to require a media gateway to go from RIPT to RTP. Sure >>>> that should be pretty easy - one of the major use cases for this work will >>>> likely involve building SBCs that talk RIPT on one side and SIP on the >>>> other. Pretty sure that a bunch of other people are thinking about the >>>> same. >>>> >>>> That sound right to you are or are you arguing for something else ? >>>> >>>> >>>> -- >>>> V3 mailing list >>>> V3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v3 >>> >>> -- >>> V3 mailing list >>> V3@ietf.org >>> https://www.ietf.org/mailman/listinfo/v3 >> >> >> From nobody Mon Mar 30 06:42:33 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55B23A083F for ; Mon, 30 Mar 2020 06:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 2Yx2rTAvlv9H for ; Mon, 30 Mar 2020 06:42:31 -0700 (PDT) Received: from smtp68.ord1d.emailsrvr.com (smtp68.ord1d.emailsrvr.com [184.106.54.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D1D3A0831 for ; Mon, 30 Mar 2020 06:42:31 -0700 (PDT) X-Auth-ID: fluffy@iii.ca Received: by smtp17.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 303EB202B3; Mon, 30 Mar 2020 09:42:30 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [50.66.148.85]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Mon, 30 Mar 2020 09:42:30 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_35E70BE7-8B15-430D-B534-AD6EE2060C27" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Cullen Jennings In-Reply-To: Date: Mon, 30 Mar 2020 07:42:29 -0600 Cc: Justin Uberti , Magnus Westerlund , "v3@ietf.org" Message-Id: References: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> To: Colin Perkins X-Mailer: Apple Mail (2.3445.104.14) X-Classification-ID: 44aef7a2-4377-4f96-a049-6ec15697d7a8-1-1 Archived-At: Subject: Re: [V3] Gateway new to old X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 13:42:33 -0000 --Apple-Mail=_35E70BE7-8B15-430D-B534-AD6EE2060C27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 29, 2020, at 4:05 PM, Colin Perkins wrote: >=20 > It may be a reasonable goal to aim to re-use RTP payload formats as = the media packetisation within the new transport. That is, different = headers and transport, but format the media content the same way. >=20 > Since payload format packetisation already all have registered media = types this would make the media content easy to identify, and save a lot = of work in re-defining packetisation schemes. >=20 > Colin >=20 >=20 +1 on reusing the RTP payload formats. As Joerg points out they are a = good design for what is needed here.=20 --Apple-Mail=_35E70BE7-8B15-430D-B534-AD6EE2060C27 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Mar 29, 2020, at 4:05 PM, Colin Perkins <csp@csperkins.org> = wrote:

It may be a reasonable goal to aim to re-use RTP payload formats = as the media packetisation within the new transport. That is, different = headers and transport, but format the media content the same = way.

Since payload = format packetisation already all have registered media types this would = make the media content easy to identify, and save a lot of work in = re-defining packetisation schemes.

Colin



+1 on reusing the RTP payload formats. As = Joerg points out they are a good design for what is needed = here. 

= --Apple-Mail=_35E70BE7-8B15-430D-B534-AD6EE2060C27-- From nobody Mon Mar 30 06:44:32 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC843A1604 for ; Mon, 30 Mar 2020 06:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 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 Kafs7XckUmzJ for ; Mon, 30 Mar 2020 06:44:30 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00064.outbound.protection.outlook.com [40.107.0.64]) (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 A06BF3A15FE for ; Mon, 30 Mar 2020 06:44:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Tbkcg7bgy2iGKvDlYPKOQalfJ5pT7T4qYx3qNZtIuaoTrzoAmy+gQD+4pzuyXNI/csFoiwcXtFt+9376OYNhdmmoshL+4lQR5m4btRaXz1FCIbLmOwIZiXvCAyCEFXE5FMy/8KnHKc4OJSGLVLB+2Vl2J/w+LkTEPKgiTpanZilC/GMeFq+yzJYnCQ0B6NZLshaH2v+WqgR2nHqH9PL0tt/pPhY8WKHsymW75Bn4LcQ3AhCFPcxFt3Y28NhSZOItUK8/P3sgBUNaJ9nxvFvdIcuobh2g99tmD9e8aZ9fFCNKwcmVoTXdHedpyccxqH1S2LxXe4GdiGMxiMXMYAN1rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=166QEkeLnGp2t4RdYyWIY8RxtrC9/OMUSzcU/WcOHaQ=; b=VOk5q8Vp/lknMAxhQEBqX7ke0y4LvMyIoLjm1LlvvR/+zs0A8drgBz2CjbBIUOdrSPPhYN3ml9TIDBNUKm0BjP4Cf+lhLoQoooHqeUxO/SXxVUjKJ2FsYwYV9sHUX916PXLxwytJvXz94DZpni0r+ecRW5LO1dzJeR1WlepkZQKZJF/bOS/FF/NbQY3R+hXHH6g3hBkgV8xL5Dx4G6+ltW6+3uQ6J2qpCboiCOXtEWfGRmGCupZqg4u86nz8+/QKO37NRHy10CEkag9LwpNDXUHiKQxGwssDUKF0cVrrMMLb1BnCB7VMbxQJup6uWQjKW0q5qlYf2+VFj9pTIg3EIw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=166QEkeLnGp2t4RdYyWIY8RxtrC9/OMUSzcU/WcOHaQ=; b=GKWVFOgTZhDHUmLY2RY61emhoBiM/muP1g4lpKEwTieG39u4HZg4+kLihBeXN0ZlMNzH+e+7X8ZAwb0NZaZCwIiZthzVTA4JtepTBrm8Tbb72XF7U/Tj92LIiGDblY/Uklq2hKgzmo1hgSs0ICFNZjVIbQjpmSItvgXn5mOowKI= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (52.133.7.14) by HE1PR0702MB3819.eurprd07.prod.outlook.com (10.167.126.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.13; Mon, 30 Mar 2020 13:44:26 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8bd:85b0:d547:9eed]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8bd:85b0:d547:9eed%6]) with mapi id 15.20.2856.018; Mon, 30 Mar 2020 13:44:26 +0000 From: Magnus Westerlund To: "magnus.westerlund=40ericsson.com@dmarc.ietf.org" , "fluffy@iii.ca" CC: "v3@ietf.org" Thread-Topic: [V3] High level comments on the RIPT charter and scope Thread-Index: AQHWBENbus/fvMWAlEybhl6kdLAG2KhcnlqAgASLxYA= Date: Mon, 30 Mar 2020 13:44:26 +0000 Message-ID: References: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> <7028E641-D015-4E2B-BAA3-865B13535912@iii.ca> In-Reply-To: <7028E641-D015-4E2B-BAA3-865B13535912@iii.ca> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1 authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [158.174.118.23] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6cc56ac7-e366-4ac3-3ca6-08d7d4b076b6 x-ms-traffictypediagnostic: HE1PR0702MB3819: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0358535363 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(396003)(136003)(366004)(186003)(6512007)(99936003)(8676002)(71200400001)(36756003)(2906002)(44832011)(66946007)(86362001)(66476007)(66556008)(64756008)(66446008)(76116006)(66616009)(53546011)(2616005)(5660300002)(26005)(478600001)(110136005)(6486002)(4326008)(81156014)(8936002)(81166006)(316002)(6506007)(99106002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8w1MN3PiqKEBPZgEvC+eOhFxVUnCoiQg+BYNtI84BKNG8z59ywyjHAn9Q2FBcjRIJTMRnyMbMPpy+7nXW44Id6KJJ7HHLKRbDGFf8Wz+2mOCkPmDVZKvqLO1rnlQwas+yPfKNkJkTZb3pqEGep84f+9r1w7mghHYdLUVTEkGJF8prdm37/sK4bmiFbmRWJAu64YG6uMZH6R2GE/n0QyxtT2aouglBcy+YBoOZgdBBE1Si3fcU+uZ8p0bZKcR4eEfmUvOIwdV0BBmTE/GeJOKxAw+e3fK08iSijxMOTkMwSx1gzGOUfLnUodr8vClPJ69e5xb21yI0iAgHAfeGYnKi1iiGx8sVsG669BlL/kxvc0wHgELlqcvmBLsfxdCOwT12M2JzkjHnkAR8LuaOx8sRaJK4ipy5LCuVBZ30q4waICEaxqYMsVeK89D6kz79qRCplYdM8C2Mq1qdRcoTyXH0kyjH+Zm+OkrZEuZdzFuyxiAdIUTJ9ubsj1Puz4vm+D2 x-ms-exchange-antispam-messagedata: wWa7CN9szzLkOoO6HLd2FztWcKep0tbyhtmtuf0SfBoxp5KRDdE9ehbm2JvpcFh3HS3aplgoTCBPOcrJRnCD7crKbIeQv5oAhYdsMpNJIXnn0jSwm2wu4gsX9M6TVKg2YMHWuC8Xzo7D60Hq/N80KQ== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-MY2yp3CDfk0LxoOiO2UZ" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6cc56ac7-e366-4ac3-3ca6-08d7d4b076b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2020 13:44:26.6092 (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-CrossTenant-userprincipalname: 5yqryukWq1OWdKib9QlzamfR6jq1nIkHtgiIl41oviaxslBBjS9/35l6vLCa8qNeMUevT5ILgt0AD7jRIrjAVZ5WD5LwsBfjYvWkkRR+ZO0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3819 Archived-At: Subject: Re: [V3] High level comments on the RIPT charter and scope X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 13:44:32 -0000 --=-MY2yp3CDfk0LxoOiO2UZ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2020-03-27 at 10:19 -0600, Cullen Jennings wrote: >=20 >=20 > > On Mar 27, 2020, at 8:23 AM, Magnus Westerlund < > > magnus.westerlund=3D40ericsson.com@dmarc.ietf.org> wrote: > >=20 > > The third big part is the media transport. I think we need to strongly > > consider > > if this can be broken out in to it seperate WG. >=20 > I think the WG we are talking about here is the WG to do media of H3. So = we > can talk about other things being in or out of it but that is the core th= ing.=20 >=20 > I would like to point out that one of the design properties that has been > making this easier is that media is self describing. What I mean by that = is > that if a device receives media that is one of the supported formats and > within in the limits of that device supports, the media has all the > information the device needs to decode it. No out of band information nee= ded. > That is key to making this easier to deal with HA and scalability on clou= d > side. I think that is a good property for modern designs. We have been go= ing > that way for a long time with things like opus and it works out well.=20 So, let me ask a question here. How important is it be capable to transmitt individual media ADU or even RTP payloads in a single HTTP request that rip= ples through the system independent compared to have a system that can in a 0-rt= t fashion (re-)establish an point to point by initiating an HTTP request?=20 Treating each media ADU as its own request potentially being routed in a no= n- sticky way will induce significant jitter would it not? The drafts talks ab= out sticky routing, and I did notice some comments about that assumption alread= y. Thus, from my perspective it appears that the high-performance target would= be to establish an point to point quic based transport with the relevant serve= r node that handles media forwarding. If that fails have a mechanism that can rapidly re-establish that connection with what ever node that is now the appointed one for the given call/conference.=20 Then I do understand the desire to have a fallback, and maybe that is plain= HTTP requests, but let that be the fallback and not the primary mechanism. Becas= ue I think that would unnecessary limit the potential of this system.=20 >=20 > > here are several aspects here. > > First of the split in expertise between the media transport and the > > signalling > > folks.=20 >=20 > I=E2=80=99m not sure what you mean by signalling but the the singling her= e was mostly > start media , stop media. It is not call routing, forking etc that is don= e by > SIP.=20 Yes, but even session establishment and control is still signalling from my perspective.=20 =20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-MY2yp3CDfk0LxoOiO2UZ Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDMzMDEzNDQyNVowLwYJKoZIhvcN AQkEMSIEIEbZjHcBKxPLM6Wb4yvlKNB+7kGnNhShoLdh2brpQWBkMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEApD26n/aHNFfP VFy6nh6lp7jtsKxaqqJxPydhz+zHDw77wK28TxJlbGzsJIe4n4rbgNGls8BSAmioapT40eBPIhXg saSkzbLByVMPoWZQMTquz47qtiWER9QV10lC2CS/7Kmg9X1pt93UslsLe4RNhAWCe9ZGW7BoJBJs R+UHPp8JU6tyHMl3Qdr6P8eHSzDQsolYLCcD0M/cGiCZxEhYDT3gidmRighQw2MZAusoz5Tdx1cX G43Y9fWi+3YTjHx94kjJw2o7aQsbq2Mmv3PFzgdjTC9E4eXOxGpjdn7H2TesIu+cff87rSHKcQLG ICc55s1VIS2bTIXkgKgqSOWeFQAAAAAAAA== --=-MY2yp3CDfk0LxoOiO2UZ-- From nobody Mon Mar 30 06:55:53 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05573A1625 for ; Mon, 30 Mar 2020 06:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 x_1Vc8j2PgyX for ; Mon, 30 Mar 2020 06:55:50 -0700 (PDT) Received: from smtp73.iad3a.emailsrvr.com (smtp73.iad3a.emailsrvr.com [173.203.187.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053263A161C for ; Mon, 30 Mar 2020 06:55:49 -0700 (PDT) X-Auth-ID: fluffy@iii.ca Received: by smtp26.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id D61494353; Mon, 30 Mar 2020 09:55:48 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [50.66.148.85]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Mon, 30 Mar 2020 09:55:49 -0400 From: Cullen Jennings Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DC919A2F-E800-4A60-8042-54B1C601C913" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Mon, 30 Mar 2020 07:55:47 -0600 In-Reply-To: To: Justin Uberti , "v3@ietf.org" References: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> X-Mailer: Apple Mail (2.3445.104.14) X-Classification-ID: c7f8e3f1-1f98-4679-ad29-9f4aed01a9fa-1-1 Archived-At: Subject: Re: [V3] Gateway new to old X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 13:55:52 -0000 --Apple-Mail=_DC919A2F-E800-4A60-8042-54B1C601C913 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On the stateless or not =E2=80=A6 I=E2=80=99ve tried implementing this a = few different ways and I think what we want is a sort of mostly = stateless with frequent sate updates for the parts that are not = stateless. Let me explain =E2=80=A6. First keep in mind there is nothing stateless about the QUIC connection. = Lots of state for crypto. It also seems like it would be a good thing to = allow state for compression. So we are already out of a fully stateless = design before we even start.=20 So when we say RIPT can map to RTP, we really mean RTP + RTCP as that is = needed. In the RTCP we need things like the NTP timestamp. I don=E2=80=99t= think we want to send the full NTP timestamp in ever RIPT packet which = probably rules out a fully stateless design. In WebRTC we took the = approach of putting some data in RTP header extensions and sending them = not ever packet but relatively frequently like every second or every = IFrame. I think we should do the same thing here - we should have some = stuff that is sent frequently enough that if you loose all state until = it is resent, it is not a huge deal.=20 This would allow us to do things like send the info to map to NTP time = once a second not in every packet. When you look at what is in a basic = RTP packet, I think it is easy to have that 1:1 mapping of all that data = to something in the RIPT packet but when you start looking at the RTCP = data or some of the RTP header extensions, I think that needs to all map = to stuff in RIPT but probably not something that has to be every RIPT = packet.=20 Hope that makes sense. That said, I think this still is an extremely = mostly 1:1 and simple 20 lines of code to map between RTP/RTCP and RIPT = but I think we will end up with a bit of state that if frequently = refreshed and is no worse than loosing an IFrame if you loose that = state.=20 =20 > On Mar 27, 2020, at 2:22 PM, Justin Uberti = wrote: >=20 > It's hard to imagine that we can avoid this if we are in fact going to = use H3 as a substrate.=20 >=20 > I do think it would be useful to ensure the RIPT->RTP gateway can be = stateless and transparent (i.e., you can transform a RIPT frame into a = RTP packet with reasonable fidelity), so that said gateway is all you = need in order for existing services to participate in the RIPT = ecosystem. >=20 > On Fri, Mar 27, 2020 at 9:32 AM Cullen Jennings > wrote: >=20 >=20 >> On Mar 27, 2020, at 8:23 AM, Magnus Westerlund = > wrote: >>=20 >> The next media transport issue that was barely discussed in the BOF = is the >> legacy (RTP) interoperate question. This is going to come back in the = scope >> discussion and do needs at least a direction.=20 >=20 > In WebRTC, we decided to be able to gateway SIP to WebRTC without = processing media. That turned out to be a major limitation to how WebRTC = worked. That is good and we have WebRTC but for this, I am storngly of = the view we should not have that design constraint.=20 >=20 > I think it is fine to require a media gateway to go from RIPT to RTP. = Sure that should be pretty easy - one of the major use cases for this = work will likely involve building SBCs that talk RIPT on one side and = SIP on the other. Pretty sure that a bunch of other people are thinking = about the same.=20 >=20 > That sound right to you are or are you arguing for something else ? >=20 >=20 > --=20 > V3 mailing list > V3@ietf.org > https://www.ietf.org/mailman/listinfo/v3 = > --=20 > V3 mailing list > V3@ietf.org > https://www.ietf.org/mailman/listinfo/v3 --Apple-Mail=_DC919A2F-E800-4A60-8042-54B1C601C913 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On the stateless or not =E2=80=A6 I=E2=80=99= ve tried implementing this a few different ways and I think what we want = is a sort of mostly stateless with frequent sate updates for the parts = that are not stateless. Let me explain =E2=80=A6.

First keep in mind there is nothing = stateless about the QUIC connection. Lots of state for crypto. It also = seems like it would be a good thing to allow state for compression. So = we are already out of a fully stateless design before we even = start. 

So = when we say RIPT can map to RTP, we really mean RTP + RTCP as that is = needed. In the RTCP we need things like the NTP timestamp. I don=E2=80=99t= think we want to send the full NTP timestamp in ever RIPT packet which = probably rules out a fully stateless design. In WebRTC we took the = approach of putting some data in RTP header extensions and sending them = not ever packet but relatively frequently like every second or every = IFrame.  I think we should do the same thing here - we should have = some stuff that is sent frequently enough that if you loose all state = until it is resent, it is  not a huge deal. 

This would allow us to = do things like send the info to map to NTP time once a second not in = every packet. When you look at what is in a basic RTP packet, I think it = is easy to have that 1:1 mapping of all that data to something in the = RIPT packet but when you start looking at the RTCP data or some of the = RTP header extensions, I think that needs to all map to stuff in RIPT = but probably not something that has to be every RIPT = packet. 

Hope that makes sense. That said, I think this still is an = extremely mostly 1:1 and simple 20 lines of code to map between RTP/RTCP = and RIPT but I think we will end up with a bit of state that if = frequently refreshed and is no worse than loosing an IFrame if you loose = that state. 
 

On Mar = 27, 2020, at 2:22 PM, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:

It's hard to imagine that we can avoid this if we are in fact = going to use H3 as a substrate. 

I do think it would be useful to ensure = the RIPT->RTP gateway can be stateless and transparent (i.e., you can = transform a RIPT frame into a RTP packet with reasonable fidelity), so = that said gateway is all you need in order for existing services to = participate in the RIPT ecosystem.

On Fri, Mar = 27, 2020 at 9:32 AM Cullen Jennings <fluffy@iii.ca> wrote:


On Mar = 27, 2020, at 8:23 AM, Magnus Westerlund <magnus.westerlund=3D40ericsson.com@dmarc.ietf.org> = wrote:

The next media = transport issue that was barely discussed in the BOF is the
legacy (RTP) = interoperate question. This is going to come back in the scope
discussion and = do needs at least a direction. 

In WebRTC, we decided to be able to gateway = SIP to WebRTC without processing media. That turned out to be a major = limitation to how WebRTC worked. That is good and we have WebRTC but for = this, I am storngly of the view we should not have that design = constraint. 

I think it is fine to require a media gateway to go from RIPT = to RTP. Sure that should be pretty easy - one of the major use cases for = this work will likely involve building SBCs that talk RIPT on one side = and SIP on the other. Pretty sure that a bunch of other people are = thinking about the same. 

That sound right to you are or are you = arguing for something else ?


--
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3
--
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3

= --Apple-Mail=_DC919A2F-E800-4A60-8042-54B1C601C913-- From nobody Mon Mar 30 07:15:32 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706D03A1665 for ; Mon, 30 Mar 2020 07:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 b-c4AN7jGo0S for ; Mon, 30 Mar 2020 07:15:25 -0700 (PDT) Received: from smtp86.iad3b.emailsrvr.com (smtp86.iad3b.emailsrvr.com [146.20.161.86]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C493A165D for ; Mon, 30 Mar 2020 07:15:24 -0700 (PDT) X-Auth-ID: fluffy@iii.ca Received: by smtp11.relay.iad3b.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 85310400CF; Mon, 30 Mar 2020 10:15:23 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [50.66.148.85]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Mon, 30 Mar 2020 10:15:24 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Cullen Jennings In-Reply-To: <3c2943c636663908da232674719abbf6c7ea7918.camel@ericsson.com> Date: Mon, 30 Mar 2020 08:15:13 -0600 Cc: "juberti=40google.com@dmarc.ietf.org" , "v3@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> <43DAEFA6-7258-4477-8DD7-65B6FE7E1D5D@iii.ca> <3c2943c636663908da232674719abbf6c7ea7918.camel@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3445.104.14) X-Classification-ID: 1f84d220-e855-48d7-a02f-e594b2eeb425-1-1 Archived-At: Subject: Re: [V3] Centralized conference media X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 14:15:31 -0000 I=E2=80=99m thinking of this as 100% client / server. Sure you can = build a conferences on top of that but the RIPT layer would not even = need to have a clue about the overall conference media topology. The = server can do things like pause / resume media FIR etc but it all just = two parties involved - the client and the server. Assuming a server that = maps media is one of the things that make this so much easier than an = RTP multicast conferences.=20 > On Mar 27, 2020, at 4:35 PM, Magnus Westerlund = wrote: >=20 > Hi, >=20 > So yes, I think there are the aspect of the topology as well as how = one handle > the media related controll messages, i.e. the equivalent of RTCP. For = example > things like FIR, PAUSE/Resume.=20 >=20 > So, if one with RTCP terminating middleboxes means that the ID spaces = are soley > locally that could be a choice. I will note that in some cases one = still need to > have the complete set of media sources from all end-points in a = conference be > identified at a specific point to point leg. Even if only a subset is = currently > transmitted over this leg. There are both benefits and downsides I = think of > using a local namespace and having each node translate these. >=20 > I will note that one may still need to have end-to-end identies on = media ADUs if > one are going to have any end-to-end security.=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 >=20 >=20 > On Fri, 2020-03-27 at 09:28 -0700, Justin Uberti wrote: >> I think Magnus is trying to establish the conference topology, which = has >> ramifications on how we want to handle things like RTCP. >>=20 >> One strawman could be to focus on RTCP-terminating SFUs, i.e., = cementing the >> notion that RIPT media flows are indeed point-to-point (i..e., = client-to-SFU, >> as opposed to client-to-client1, client2, client3). >>=20 >> On Fri, Mar 27, 2020 at 9:11 AM Cullen Jennings = wrote: >>>=20 >>>> On Mar 27, 2020, at 8:23 AM, Magnus Westerlund < >>>> magnus.westerlund=3D40ericsson.com@dmarc.ietf.org> wrote: >>>>=20 >>>> I am also very worried that if the model for the media transport is = only >>>> point >>>> to point calls then we get something that will become obsolete or = at least >>>> need >>>> hacks immediately. This thing need to support centralized = conferences with >>>> cascaded or meshed central media nodes. So I think it is cruical = that one >>>> define >>>> the usage model with switched central nodes and have that in mind = so that >>>> one >>>> can actually support the applications needed. I think by defining a = strict >>>> model >>>> one can actually avoid a lot of feature creep in the media = transport.=20 >>>=20 >>> I think it does make sense to support some meta data on a media flow = for >>> centralized conferencing support. What semantic level information do = you >>> think is needed in the media ? >>>=20 >>>=20 >>>=20 >>> --=20 >>> V3 mailing list >>> V3@ietf.org >>> https://www.ietf.org/mailman/listinfo/v3 > --=20 > Cheers >=20 > Magnus Westerlund=20 >=20 >=20 > ---------------------------------------------------------------------- > Networks, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 > --=20 > V3 mailing list > V3@ietf.org > https://www.ietf.org/mailman/listinfo/v3 From nobody Mon Mar 30 07:37:41 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881073A16C7 for ; Mon, 30 Mar 2020 07:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 icn-l1g-LXWN for ; Mon, 30 Mar 2020 07:37:37 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 0AE9A3A16C3 for ; Mon, 30 Mar 2020 07:37:36 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id u15so5278071lfi.3 for ; Mon, 30 Mar 2020 07:37:36 -0700 (PDT) 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=I19dJyaXloCiON7EnYe+HRTkVLzZlObRznN7XjpjsQk=; b=IgZvV6xI21UiBBKolcTFY34aEb3vAJRyNk0JUAw/NX7IUbl7xvim0tTe562GDMXtfO BvhGTjAf/F80gyHXCquhDYlT6vmmYyGpdE6VNVu8ZPi53pGrcFc7UOtJW2UqrQdjVyj6 6ypJMNZfd6N+9QOEj9Sv4XCGs5bOPBli8DtHijxpv6u/8NbJnvGbNDuNSVbf6qwOiZ55 gavBTSSsbyk7v+GRJBLKEhizm3P5MZPXNGd24dG3BHSOWa/a3q7GhwWXLttt4zP/gWON e3c5oN/Vmc53/L2vbuqyN/dOPJHFsWJ19ge4y/0DWo/U6IlNGRODHLL/AdQkaBq0jZOx hC+w== 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=I19dJyaXloCiON7EnYe+HRTkVLzZlObRznN7XjpjsQk=; b=WOnxoXhfDIH1uEcOVkMLtYGoxl5ql7b+Rjq9lyKfO1OCH7A3N4FmtmQ+/wMlikhiMu XFflDEF86zJ7c94CU8jAzyVFvLYnP38861v6Q+nOfFv1SisSjtRDJdiEh7DZfPIrsBuZ hjRJONgpJUr1/y3Sihmo7uWjAZHjzAxB1yLIJsX6Q07GxUB0ed42F0KPZ4DYuNIWfDB8 dv1cO/hoa5UQY7JU1a5aNSs/UZTJIawQ4l4KVIHPFcjuj8vyfHFlILdN3GWq5XwZx+FW 5V4gzk3xE4Sf99Y23e8BXJXBXRHtKdxWGF2sKswdqw94nq9LDFRDVE5GSIMW2C37u4mt bywQ== X-Gm-Message-State: AGi0PuYMWTK6NDSUn469HhCNbt15jraIBQd/G6gXR3GthHcDI4/BO7bP w58YDdKX0aWxS4IjdNSl0hW2shWi9J8zOVatTPCBVw== X-Google-Smtp-Source: APiQypL58/09A7yIVqgvMIBdlyQbGXXCizFQ6o/fMlRFC3iWnJITbXFT+o04oGfcU3AEC1z7OQDWGnHQXhNNUG5JgyE= X-Received: by 2002:a19:2d15:: with SMTP id k21mr8323942lfj.137.1585579054942; Mon, 30 Mar 2020 07:37:34 -0700 (PDT) MIME-Version: 1.0 References: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> <7028E641-D015-4E2B-BAA3-865B13535912@iii.ca> In-Reply-To: From: Spencer Dawkins at IETF Date: Mon, 30 Mar 2020 09:37:07 -0500 Message-ID: To: Magnus Westerlund Cc: "fluffy@iii.ca" , "v3@ietf.org" Content-Type: multipart/alternative; boundary="000000000000554d9605a2136471" Archived-At: Subject: Re: [V3] High level comments on the RIPT charter and scope X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 14:37:40 -0000 --000000000000554d9605a2136471 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For what it's worth, On Mon, Mar 30, 2020 at 8:44 AM Magnus Westerlund wrote: > On Fri, 2020-03-27 at 10:19 -0600, Cullen Jennings wrote: > > > > > > > On Mar 27, 2020, at 8:23 AM, Magnus Westerlund < > > > magnus.westerlund=3D40ericsson.com@dmarc.ietf.org> wrote: > > > > > > The third big part is the media transport. I think we need to strongl= y > > > consider > > > if this can be broken out in to it seperate WG. > > > > I think the WG we are talking about here is the WG to do media of H3. S= o > we > > can talk about other things being in or out of it but that is the core > thing. > > > > I would like to point out that one of the design properties that has be= en > > making this easier is that media is self describing. What I mean by tha= t > is > > that if a device receives media that is one of the supported formats an= d > > within in the limits of that device supports, the media has all the > > information the device needs to decode it. No out of band information > needed. > > That is key to making this easier to deal with HA and scalability on > cloud > > side. I think that is a good property for modern designs. We have been > going > > that way for a long time with things like opus and it works out well. > > So, let me ask a question here. How important is it be capable to transmi= tt > individual media ADU or even RTP payloads in a single HTTP request that > ripples > through the system independent compared to have a system that can in a > 0-rtt > fashion (re-)establish an point to point by initiating an HTTP request? > > Treating each media ADU as its own request potentially being routed in a > non- > sticky way will induce significant jitter would it not? The drafts talks > about > sticky routing, and I did notice some comments about that assumption > already. > Thus, from my perspective it appears that the high-performance target > would be > to establish an point to point quic based transport with the relevant > server > node that handles media forwarding. If that fails have a mechanism that c= an > rapidly re-establish that connection with what ever node that is now the > appointed one for the given call/conference. > > Then I do understand the desire to have a fallback, and maybe that is > plain HTTP > requests, but let that be the fallback and not the primary mechanism. > Becasue I > think that would unnecessary limit the potential of this system. > > > > > > here are several aspects here. > > > First of the split in expertise between the media transport and the > > > signalling > > > folks. > > > > I=E2=80=99m not sure what you mean by signalling but the the singling h= ere was > mostly > > start media , stop media. It is not call routing, forking etc that is > done by > > SIP. > > Yes, but even session establishment and control is still signalling from = my > perspective. > I've certainly been thinking of "everything except media payload" as signaling in my own comments. So, close to Magnus here, IIUC. If we don't have a common understanding of this (and it sounds like we might not), that would be a good thing to talk about during the charter development. Best, Spencer > Cheers > > Magnus Westerlund > > > ---------------------------------------------------------------------- > Networks, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > -- > V3 mailing list > V3@ietf.org > https://www.ietf.org/mailman/listinfo/v3 > --000000000000554d9605a2136471 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For what it's worth,=C2=A0

<= div class=3D"gmail_quote">
On Mon, Mar= 30, 2020 at 8:44 AM Magnus Westerlund <magnus.westerlund=3D40ericsson.com@dmarc.ietf.org> = wrote:
On Fri, 2= 020-03-27 at 10:19 -0600, Cullen Jennings wrote:
>
>
> > On Mar 27, 2020, at 8:23 AM, Magnus Westerlund <
> > magnus.westerlund=3D40ericsson.com@dmarc.ietf.org> wrote:
> >
> > The third big part is the media transport. I think we need to str= ongly
> > consider
> > if this can be broken out in to it seperate WG.
>
> I think the WG we are talking about here is the WG to do media of H3. = So we
> can talk about other things being in or out of it but that is the core= thing.
>
> I would like to point out that one of the design properties that has b= een
> making this easier is that media is self describing. What I mean by th= at is
> that if a device receives media that is one of the supported formats a= nd
> within in the limits of that device supports, the media has all the > information the device needs to decode it. No out of band information = needed.
> That is key to making this easier to deal with HA and scalability on c= loud
> side. I think that is a good property for modern designs. We have been= going
> that way for a long time with things like opus and it works out well. =

So, let me ask a question here. How important is it be capable to transmitt=
individual media ADU or even RTP payloads in a single HTTP request that rip= ples
through the system independent compared to have a system that can in a 0-rt= t
fashion (re-)establish an point to point by initiating an HTTP request?
Treating each media ADU as its own request potentially being routed in a no= n-
sticky way will induce significant jitter would it not? The drafts talks ab= out
sticky routing, and I did notice some comments about that assumption alread= y.
Thus, from my perspective it appears that the high-performance target would= be
to establish an point to point quic based transport with the relevant serve= r
node that handles media forwarding. If that fails have a mechanism that can=
rapidly re-establish that connection with what ever node that is now the appointed one for the given call/conference.

Then I do understand the desire to have a fallback, and maybe that is plain= HTTP
requests, but let that be the fallback and not the primary mechanism. Becas= ue I
think that would unnecessary limit the potential of this system.

>
> > here are several aspects here.
> > First of the split in expertise between the media transport and t= he
> > signalling
> > folks.
>
> I=E2=80=99m not sure what you mean by signalling but the the singling = here was mostly
> start media , stop media. It is not call routing, forking etc that is = done by
> SIP.

Yes, but even session establishment and control is still signalling from my=
perspective.

I've certainly been t= hinking of "everything except media payload" as signaling in my o= wn comments. So, close to Magnus here, IIUC.=C2=A0

If we don't have a common understanding of this (and it sounds like we= might not), that would be a good thing to talk about during the charter de= velopment.=C2=A0

Best,

Sp= encer
=C2=A0
Cheers

Magnus Westerlund


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile +46 73 0= 949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3
--000000000000554d9605a2136471-- From nobody Mon Mar 30 09:56:52 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E2C3A00AE for ; Mon, 30 Mar 2020 09:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 81sv7N-nQwx4 for ; Mon, 30 Mar 2020 09:56:47 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 A10153A0064 for ; Mon, 30 Mar 2020 09:56:47 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id u11so11534977vsg.2 for ; Mon, 30 Mar 2020 09:56:47 -0700 (PDT) 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=UQCbjNeA4MQqeN/mdw2oHlF3Cxv7N2wPWumLucqkQU0=; b=RQdbjfRL2qGZFZrZECa+ynNBBwnm9FV7ER0ArKOes3VNVwKfXnCOqbhmQQwstKQaSe TWKExwYuK1CFoCSx7erYL1cRId9hCXvbVUlvzZfRtoUX9Ey1dg6nqY4fmewQve9fSrZ8 p1fHW0F46rV4ayM7CCCXTrIjAzuibRD6+hiJ6r6pfaM9K80dV5ygT6Iq0TDyIn8h6DgR uASGTNkcFKvi6GIalKJJ51j1pT5RymbfBuNAgH6MqDN+DX+rwVO+1ZwDWyun+xaXHDGg qfCFD7ohbQbV+zMg+elEwHSPMjtg1Zk7+wqje+Gnw+QwexHC+NiaP4OOmY1MV9u/D4HK E6LQ== 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=UQCbjNeA4MQqeN/mdw2oHlF3Cxv7N2wPWumLucqkQU0=; b=RWSy2naw+qobgd9oxrryDXFsnkOyKtW1u8+wcPo+Vf4lEnz+1mOGRt4WKs4uzCkwrE 7JgWdbGF/lq5CsefLkosE4raL2371hQJ6EbetnP+Rop+DiteRHn7FKHfaLbbcn8Q0bQZ Wd1rc11QFp3tPZ+vED8meNEULa0l496PZENuDldyrfzppNBNJa4ztFxLM06ikvKXN5An /j//lSXjyCAnXRy7vjSRjCfx631eZHYLF3uBiQd7JPDYiKZ14YrnitKxXFJbCZ8swyXH SZzrLRfdCP6qgfnL5y/OKTH9nQr/ve4ZC0yAt2sUl+XsQCErKNEib8i6+OGEH4EBolYo /yuw== X-Gm-Message-State: AGi0PubecvSMG8l0Row0eQabS9GNOfekQbnPN3gQakk2lrt34dXqPzTI nQuYr0NFWQdriqBcYuljHsPzBw1Y6uIG0prFFd/9baWy X-Google-Smtp-Source: APiQypJcnnFfOWdT1EMLN8lCICvGI4Y7p1mZLI5dhJAQ029jKMKxqg2+0kjezeCINrP6AAgIF2NGPXk9GW/el7iHuYA= X-Received: by 2002:a67:fd6f:: with SMTP id h15mr4765624vsa.96.1585587406007; Mon, 30 Mar 2020 09:56:46 -0700 (PDT) MIME-Version: 1.0 References: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> In-Reply-To: From: Justin Uberti Date: Mon, 30 Mar 2020 09:56:34 -0700 Message-ID: To: Cullen Jennings Cc: "v3@ietf.org" Content-Type: multipart/alternative; boundary="000000000000195a2e05a215561a" Archived-At: Subject: Re: [V3] Gateway new to old X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 16:56:51 -0000 --000000000000195a2e05a215561a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 30, 2020 at 6:55 AM Cullen Jennings wrote: > > On the stateless or not =E2=80=A6 I=E2=80=99ve tried implementing this a = few different > ways and I think what we want is a sort of mostly stateless with frequent > sate updates for the parts that are not stateless. Let me explain =E2=80= =A6. > > First keep in mind there is nothing stateless about the QUIC connection. > Lots of state for crypto. It also seems like it would be a good thing to > allow state for compression. So we are already out of a fully stateless > design before we even start. > Sure, there is lots of state for crypto. But this will typically be handled by a frontend server at the edge of the cloud infra, so we should focus on the RTP-specific parts. > > So when we say RIPT can map to RTP, we really mean RTP + RTCP as that is > needed. In the RTCP we need things like the NTP timestamp. I don=E2=80=99= t think we > want to send the full NTP timestamp in ever RIPT packet which probably > rules out a fully stateless design. In WebRTC we took the approach of > putting some data in RTP header extensions and sending them not ever pack= et > but relatively frequently like every second or every IFrame. I think we > should do the same thing here - we should have some stuff that is sent > frequently enough that if you loose all state until it is resent, it is > not a huge deal. > > This would allow us to do things like send the info to map to NTP time > once a second not in every packet. When you look at what is in a basic RT= P > packet, I think it is easy to have that 1:1 mapping of all that data to > something in the RIPT packet but when you start looking at the RTCP data = or > some of the RTP header extensions, I think that needs to all map to stuff > in RIPT but probably not something that has to be every RIPT packet. > > Hope that makes sense. That said, I think this still is an extremely > mostly 1:1 and simple 20 lines of code to map between RTP/RTCP and RIPT b= ut > I think we will end up with a bit of state that if frequently refreshed a= nd > is no worse than loosing an IFrame if you loose that state. > I can get on board with this. As you say, there already is some state with RTP/RTCP in terms of the timestamp mapping. The main thing is that this needs to be loss-tolerant (which makes compression somewhat harder) and self-healing, e.g., on a gateway failover. But yeah, it would be nice to not have to send the ~same 12 bytes + 0xBEDE in every packet. (And this is why I think we can reach parity or better with RTP efficiency.) > > > On Mar 27, 2020, at 2:22 PM, Justin Uberti < > juberti=3D40google.com@dmarc.ietf.org> wrote: > > It's hard to imagine that we can avoid this if we are in fact going to us= e > H3 as a substrate. > > I do think it would be useful to ensure the RIPT->RTP gateway can be > stateless and transparent (i.e., you can transform a RIPT frame into a RT= P > packet with reasonable fidelity), so that said gateway is all you need in > order for existing services to participate in the RIPT ecosystem. > > On Fri, Mar 27, 2020 at 9:32 AM Cullen Jennings wrote: > >> >> >> On Mar 27, 2020, at 8:23 AM, Magnus Westerlund < >> magnus.westerlund=3D40ericsson.com@dmarc.ietf.org> wrote: >> >> The next media transport issue that was barely discussed in the BOF is t= he >> legacy (RTP) interoperate question. This is going to come back in the >> scope >> discussion and do needs at least a direction. >> >> >> In WebRTC, we decided to be able to gateway SIP to WebRTC without >> processing media. That turned out to be a major limitation to how WebRTC >> worked. That is good and we have WebRTC but for this, I am storngly of t= he >> view we should not have that design constraint. >> >> I think it is fine to require a media gateway to go from RIPT to RTP. >> Sure that should be pretty easy - one of the major use cases for this wo= rk >> will likely involve building SBCs that talk RIPT on one side and SIP on = the >> other. Pretty sure that a bunch of other people are thinking about the >> same. >> >> That sound right to you are or are you arguing for something else ? >> >> >> -- >> V3 mailing list >> V3@ietf.org >> https://www.ietf.org/mailman/listinfo/v3 >> > -- > V3 mailing list > V3@ietf.org > https://www.ietf.org/mailman/listinfo/v3 > > > --000000000000195a2e05a215561a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Mar 30, 2020 at 6:55 AM Culle= n Jennings <fluffy@iii.ca> wrote= :

On the stateless or not =E2=80= =A6 I=E2=80=99ve tried implementing this a few different ways and I think w= hat we want is a sort of mostly stateless with frequent sate updates for th= e parts that are not stateless. Let me explain =E2=80=A6.

First keep in mind there is nothing stateless about the QUIC connection. = Lots of state for crypto. It also seems like it would be a good thing to al= low state for compression. So we are already out of a fully stateless desig= n before we even start.=C2=A0

S= ure, there is lots of state for crypto. But this will typically be handled = by a frontend server at the edge of the cloud infra, so we should focus on = the RTP-specific parts.=C2=A0

So= when we say RIPT can map to RTP, we really mean RTP + RTCP as that is need= ed. In the RTCP we need things like the NTP timestamp. I don=E2=80=99t thin= k we want to send the full NTP timestamp in ever RIPT packet which probably= rules out a fully stateless design. In WebRTC we took the approach of putt= ing some data in RTP header extensions and sending them not ever packet but= relatively frequently like every second or every IFrame.=C2=A0 I think we = should do the same thing here - we should have some stuff that is sent freq= uently enough that if you loose all state until it is resent, it is =C2=A0n= ot a huge deal.=C2=A0

This would allow us to do th= ings like send the info to map to NTP time once a second not in every packe= t. When you look at what is in a basic RTP packet, I think it is easy to ha= ve that 1:1 mapping of all that data to something in the RIPT packet but wh= en you start looking at the RTCP data or some of the RTP header extensions,= I think that needs to all map to stuff in RIPT but probably not something = that has to be every RIPT packet.=C2=A0

Hope that = makes sense. That said, I think this still is an extremely mostly 1:1 and s= imple 20 lines of code to map between RTP/RTCP and RIPT but I think we will= end up with a bit of state that if frequently refreshed and is no worse th= an loosing an IFrame if you loose that state.=C2=A0

I can get on board with this. As you say, there alread= y is some state with RTP/RTCP in terms of the timestamp mapping. The main t= hing is that this needs to be loss-tolerant (which makes compression somewh= at harder) and self-healing, e.g., on a gateway failover.

But yeah, it would be nice to not have to send the ~same 12 bytes= =C2=A0+ 0xBEDE in every packet. (And this is why I think we can reach parit= y or better with RTP efficiency.)
=C2=A0

On Mar 27, 2020, at 2:22 PM, Justin Ube= rti <juberti=3D40google.com@dmarc.ietf.org> wrote:

=
It's hard to imagine that we can avoid this if we are = in fact going to use H3 as a substrate.=C2=A0

I do think= it would be useful to ensure the RIPT->RTP gateway can be stateless and= transparent (i.e., you can transform a RIPT frame into a RTP packet with r= easonable fidelity), so that said gateway is all you need in order for exis= ting services to participate=C2=A0in the RIPT ecosystem.

On Fri, Mar 2= 7, 2020 at 9:32 AM Cullen Jennings <fluffy@iii.ca> wrote:


On Mar 27, 2020, at 8:23 AM, Magnus Westerlund <magnus.wes= terlund=3D40ericsson.com@dmarc.ietf.org> wrote:

The next media transport issue th= at was barely discussed in the BOF is the
legacy (RTP) interoperate question= . This is going to come back in the scope
discussion and do needs at least a= direction.=C2=A0

In W= ebRTC, we decided to be able to gateway SIP to WebRTC without processing me= dia. That turned out to be a major limitation to how WebRTC worked. That is= good and we have WebRTC but for this, I am storngly of the view we should = not have that design constraint.=C2=A0

I think it = is fine to require a media gateway to go from RIPT to RTP. Sure that should= be pretty easy - one of the major use cases for this work will likely invo= lve building SBCs that talk RIPT on one side and SIP on the other. Pretty s= ure that a bunch of other people are thinking about the same.=C2=A0

That sound right to you are or are you arguing for someth= ing else ?


--
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3
--
V3 mailing list
= V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3

--000000000000195a2e05a215561a-- From nobody Mon Mar 30 16:20:05 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394EB3A1570 for ; Mon, 30 Mar 2020 16:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=rbbn.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 856YKN3Ed8d4 for ; Mon, 30 Mar 2020 16:20:02 -0700 (PDT) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [216.205.24.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EADD13A156F for ; Mon, 30 Mar 2020 16:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1585610400; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=VoklanE5GprvNdfJ04cM2FQryDuLTZWRw0tWQy4vOX8=; b=qgfYLJu3XCq9J6172OWCRf1lP1IO6nHH3d5BGRA9TLIcptN9h0oONBmX1E4U1D2PK30FdO 4ATW0dWMYB3puCCWOQxcesLb3uq7mZ4tNX6ciNhy2rtPduOPnzMlKUOcOylAiR7MDAJ+9x vNwLR4qUq3jKhcYVCZ6uJLSoaYjUmY4= Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11lp2174.outbound.protection.outlook.com [104.47.56.174]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-181-GARKHmsOOnOLc-7Y8CzXLg-1; Mon, 30 Mar 2020 19:19:57 -0400 Received: from BN7PR03MB3827.namprd03.prod.outlook.com (2603:10b6:408:23::13) by BN7PR03MB4563.namprd03.prod.outlook.com (2603:10b6:408:36::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Mon, 30 Mar 2020 23:19:55 +0000 Received: from BN7PR03MB3827.namprd03.prod.outlook.com ([fe80::1513:1e58:3df9:e82a]) by BN7PR03MB3827.namprd03.prod.outlook.com ([fe80::1513:1e58:3df9:e82a%7]) with mapi id 15.20.2856.019; Mon, 30 Mar 2020 23:19:55 +0000 From: "Asveren, Tolga" To: "v3@ietf.org" Date: Mon, 30 Mar 2020 19:19:55 -0400 Thread-Topic: LB / Failure Detection Thread-Index: AdYG6btUA0vrNC4WR7ioGZcCpQmceA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-originating-ip: [73.80.74.66] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7602a86c-7638-4d9c-a9c1-08d7d500dbaa x-ms-traffictypediagnostic: BN7PR03MB4563: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3826; x-forefront-prvs: 0358535363 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR03MB3827.namprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(396003)(39860400002)(346002)(376002)(366004)(316002)(6916009)(478600001)(66946007)(33656002)(4744005)(71200400001)(76116006)(81156014)(7696005)(186003)(26005)(9686003)(55016002)(86362001)(66476007)(2906002)(66556008)(52536014)(5660300002)(64756008)(81166006)(8676002)(6506007)(66446008)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gdMayLBarSmE7rBEyxm5y1+RTQlAa8Sr9x42N/uPEXasZ46bF58rZB/ZvIvtV9W48V3a/dIewrK/nibQF1IjJ6ArLcHbfHQZRgbNRjR8tABeMjZbpGEpiDXM1w0HpknfHP9warwrlj7735JsT4qj58lKVMwRm7T8v7VXWysUJcb7Q/h50FTYP48glQmz49LXWAcBTKmfEpQBXYa/dAV9E9dpX8c9QQftViXsQqxFiWrCet7RPhnQjn+D0GCvaWpXcrT7xQdrFyuJ1/D1YBsw6vlwXlsnr1vcN5/q9wM3NSDsyWWt7eCKsCrrlAWzfavtGkQjGRps+kkAttL+lDYBs8a1bCFava31EAZ0TL8fTwWC/GVh5DKdW9A7mOUN5h6819sYRPN8DcTk1166b1YXe2/hD3cXq3KanVkTw8MWi99yYSkkcU+MzZ/0L4LoGffE x-ms-exchange-antispam-messagedata: VKjMTinL1y9370deCF/kOvtBqpOjlcIxuOcxkuobF6ib2D6jMuCjBLnWtMTtB8/E+JneSrv10lAXajbrlmjTIyMIwcHQwhQEH4i/8zOYy3fEPmtPZGUZBLqDtS2OZ5EsQTnDTkldVXlvP9jultKkwQ== x-ms-exchange-transport-forked: True x-mc-unique: GARKHmsOOnOLc-7Y8CzXLg-1 x-originatororg: rbbn.com x-ms-exchange-crosstenant-network-message-id: 7602a86c-7638-4d9c-a9c1-08d7d500dbaa x-ms-exchange-crosstenant-originalarrivaltime: 30 Mar 2020 23:19:55.7186 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: ZlIbNuJ05qR0QUfS9UpypsmOZmt5+WK2X/rbhmM4yTZ/01nQetQBpQS4dfO8mtEmYnvBLMyAEMxbKm052aLzCg== x-ms-exchange-transport-crosstenantheadersstamped: BN7PR03MB4563 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: rbbn.com Content-Type: multipart/alternative; boundary="_000_BN7PR03MB3827DB56F2D404541FF8A6C0A5CB0BN7PR03MB3827namp_" Archived-At: Subject: [V3] LB / Failure Detection X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 23:20:03 -0000 --_000_BN7PR03MB3827DB56F2D404541FF8A6C0A5CB0BN7PR03MB3827namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A basic question about how RIPT would make things better compared to RTP in= terms of making use of Public Cloud Load-balancers: With RTP: One can use L4 LB distributing traffic to a Redundancy Group. The= pain point is that LB is slow in detecting failures of Redundancy Group me= mbers. With RIPT media: One can use HTTP LB distributing traffic a Redundancy Grou= p. I would think failure detection characteristics will be similar to L4 LB= and delayed failure detection issue would continue to be an issue. In a nutshell, what would one gain by using a HTTP LB instead of L4 LB? Thanks, Tolga ---------------------------------------------------------------------------= -------------------------------------------- Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipie= nt. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly= prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies,= including any attachments. ---------------------------------------------------------------------------= -------------------------------------------- --_000_BN7PR03MB3827DB56F2D404541FF8A6C0A5CB0BN7PR03MB3827namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

A basic = question about how RIPT would make things better compared to RTP in terms o= f making use of Public Cloud Load-balancers:

 

With RTP: One can use L4 LB = distributing traffic to a Redundancy Group. The pain point is that LB is sl= ow in detecting failures of Redundancy Group members.

With RIPT media: One can use HTTP LB distributing traffic a R= edundancy Group. I would think failure detection characteristics will be si= milar to L4 LB and delayed failure detection issue would continue to be an = issue.

 

In a nutshell, what would one gain by using a HTTP LB instead of L= 4 LB?

 

Thanks,

Tolga



Notice: = This e-mail together with any attachments may contain information of Ribbon= Communications Inc. that is confidential and/or proprietary for the sole u= se of the intended recipient. Any review, disclosure, reliance or distribu= tion by others or forwarding without express permission is strictly prohibi= ted. If you are not the intended recipient, please notify the sender immed= iately and then delete all copies, including any attachments.
 --_000_BN7PR03MB3827DB56F2D404541FF8A6C0A5CB0BN7PR03MB3827namp_-- From nobody Mon Mar 30 17:06:22 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CB63A161C for ; Mon, 30 Mar 2020 17:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=rbbn.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 gyxeys_ES8m9 for ; Mon, 30 Mar 2020 17:06:17 -0700 (PDT) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [216.205.24.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9158C3A161A for ; Mon, 30 Mar 2020 17:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1585613176; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=EYN4uDXo7OZ/shWuJUO06PjW7HVLnegZ32LhUcp9P8M=; b=Zsu9zCcXDgBOA0abNEUFy22xwtsrypuLQpZzdF7piu+mjw+oFC5dsSsTP63pm60YD7BVAX wHxz9Sx9jf2dLknt2qaE9UGVkDuz6dW6cqpl8mrRXwsU1QcPKdkWgnY9rKIlJ6OqUG+rJo DD26zvyHeNF2x5gW+6O5zkTCeqo9lvA= Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2173.outbound.protection.outlook.com [104.47.58.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-479-eOs_crvQMgOpvcr5tdQ2Mw-1; Mon, 30 Mar 2020 20:06:13 -0400 Received: from BN7PR03MB3827.namprd03.prod.outlook.com (2603:10b6:408:23::13) by BN7PR03MB3715.namprd03.prod.outlook.com (2603:10b6:406:c3::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Tue, 31 Mar 2020 00:06:11 +0000 Received: from BN7PR03MB3827.namprd03.prod.outlook.com ([fe80::1513:1e58:3df9:e82a]) by BN7PR03MB3827.namprd03.prod.outlook.com ([fe80::1513:1e58:3df9:e82a%7]) with mapi id 15.20.2856.019; Tue, 31 Mar 2020 00:06:11 +0000 From: "Asveren, Tolga" To: "v3@ietf.org" Date: Mon, 30 Mar 2020 20:06:10 -0400 Thread-Topic: RIPT/RTP interworking Thread-Index: AdYG76jExRB1nO8MQxeZ+fxoUNuIfQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-originating-ip: [73.80.74.66] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 190f9969-751b-46ae-84e0-08d7d50751ec x-ms-traffictypediagnostic: BN7PR03MB3715: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0359162B6D x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR03MB3827.namprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(39860400002)(376002)(396003)(346002)(366004)(76116006)(55016002)(316002)(66946007)(9686003)(71200400001)(81166006)(478600001)(66446008)(558084003)(6916009)(186003)(8936002)(66556008)(2906002)(81156014)(7696005)(52536014)(8676002)(64756008)(66476007)(33656002)(6506007)(86362001)(26005)(5660300002)(3480700007); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JpZ+Ek7oO/jSi68yiWDU7p9KH0u+/ljw++9hYOA2Zz6jN7vhKz+Bnz2s9j2ZqqH5RKnVDwoayWXBgnDLqTOVOGH+xiIkQ93URhn3C+YTF5YkptOlXN/5HbKbnqtRdc5rb846PQb4F99KKRgO4bP4pxlRMpvfguwQfaq76LD9sBghn1/y2nTelkBmOKRlAS0EPlSPmW73izMvFasf5mz6aQt/YtlUG8nJLuu/Ei6y0/EBbhNpEEIlkcd6ICWyf+/VtXRvrLiGXOAdxBF7RlyohkdtrbHygsppiiUKOpcBw63eacHBV1mtKwUwKi7Vtcxgh34nXO2oLakLIp3MkzzcwUJA5GpH7S47e/LI2/ZtJasSEcRy3WHcUZZCjVW2F6ylTDU+V9y6xzk8BNI3ri+ttUurKQ0pzmptR4N+8mYTfblhtvPbStWN1cP6JbCGjgQd x-ms-exchange-antispam-messagedata: B8vekAq/YeH6o8ytwm1/srmFVgPUv6LWgd00lMjCW3VSeg0Xa5HXeMPwLM1wzs1tpMOPRYLVwfLHd1mDnLmP3FfKzW7V9XkYz+tKFAD7rubj31nrT8eG8/peYo/SKsJnxjyxC8ST8u5+3zYMw19Wog== x-ms-exchange-transport-forked: True x-mc-unique: eOs_crvQMgOpvcr5tdQ2Mw-1 x-originatororg: rbbn.com x-ms-exchange-crosstenant-network-message-id: 190f9969-751b-46ae-84e0-08d7d50751ec x-ms-exchange-crosstenant-originalarrivaltime: 31 Mar 2020 00:06:10.8508 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: H4spZybP53rPRknYgl/L+VugwYkDLvGBRDXWsGmvzKVjWWEkcOeM69q7RCB12E37gMBNCyZyKuJbE5KdK/88dw== x-ms-exchange-transport-crosstenantheadersstamped: BN7PR03MB3715 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: rbbn.com Content-Type: multipart/alternative; boundary="_000_BN7PR03MB3827E65FC1F7F79B79AFEF54A5C80BN7PR03MB3827namp_" Archived-At: Subject: [V3] RIPT/RTP interworking X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2020 00:06:21 -0000 --_000_BN7PR03MB3827E65FC1F7F79B79AFEF54A5C80BN7PR03MB3827namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To be able to perform RIPT/RTP interworking, I think it is unavoidable that= one has to address all the existing difficulties with RTP in Public Cloud.= So, this translates to that any potential benefits of RIPT would be mainly= for cases not requiring interworking, or? Thanks, Tolga ---------------------------------------------------------------------------= -------------------------------------------- Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipie= nt. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly= prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies,= including any attachments. ---------------------------------------------------------------------------= -------------------------------------------- --_000_BN7PR03MB3827E65FC1F7F79B79AFEF54A5C80BN7PR03MB3827namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

To be ab= le to perform RIPT/RTP interworking, I think it is unavoidable that one has= to address all the existing difficulties with RTP in Public Cloud. So, thi= s translates to that any potential benefits of RIPT would be mainly for cas= es not requiring interworking, or?

=  

Thanks,

Tolga



Notice: This e-mail together with any attachments may = contain information of Ribbon Communications Inc. that is confidential and/= or proprietary for the sole use of the intended recipient. Any review, dis= closure, reliance or distribution by others or forwarding without express p= ermission is strictly prohibited. If you are not the intended recipient, p= lease notify the sender immediately and then delete all copies, including a= ny attachments.
 --_000_BN7PR03MB3827E65FC1F7F79B79AFEF54A5C80BN7PR03MB3827namp_-- From nobody Mon Mar 30 17:08:56 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106A33A0FCF for ; Mon, 30 Mar 2020 17:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 MIr2tH6z88SX for ; Mon, 30 Mar 2020 17:08:54 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 8F69F3A0FCE for ; Mon, 30 Mar 2020 17:08:54 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id x206so12363807vsx.5 for ; Mon, 30 Mar 2020 17:08:54 -0700 (PDT) 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=xWQSoNaQsp/vDIrUH+ZohR+7LupRyW9W9YRyc6XaCIA=; b=gZbXhvvD1SAZHGO34foATWELMlVh4hZD0KdLjuWJMLKN9cBWaw1rucOGxjKHuUVWl3 b7u+7acvaq5PmNphiXCmf+a8Zw1BwN3FA/1axTxG+ocamCXa4KRYKCSRrD63+F+wPem3 BstEjMITlsdBwV7cI1KXffK2Bit4olhjzLR/MItlKRM30eQOJmfZ5bGUi1ISf1sSH6mV xTYBBZYPijfTcMff7bb0wHKw07J0/ihshUklkffr2y9b6su9EC3JvCGEgWARyfCHrmwW X+fHJWYeYB8Z1F8ULxC9jixzkXuxUP5RmUm5AANvM8Vf7LiUkRdENvMRjiKF8qQwnN4c Fgww== 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=xWQSoNaQsp/vDIrUH+ZohR+7LupRyW9W9YRyc6XaCIA=; b=LyTR92EwuYZXdnboQ1qDOVZNWOzHgAUA0uVHplUpgsT1lNLOYbgTVPKX3M0qR8Uwer BsjykOKyCsvhwA84zhpcaK1NVJV3jnIK03/Qy5GMLHMblRTIHB13o9D1AwIf4nD6yg01 Wno6QOv8YAjmdcE1Zs1tN5pxe8fXW2ZmQqjaaFM4Uw8wMN7cMA+PxJPK0YmWqE76nhIa piRfg/t6QvcxUxX7FijyQHWTS+6Pj77vM3q0t2xL7TqQPyMo015498XtKH5A/IcIn3ZH IH/TWiehrRwzB+7A9uxt+hr4x3ruXesykp3KMxF/uY+3j7iMZo6rRuinj27DWjYroKmp zBdw== X-Gm-Message-State: AGi0PuZLF9YO9l6A5RuI2r8Akb7d9su5gtjWOyrag/UJMi2oiUS9PGzF vk0eTaTSlMxOocCD7Fxh1T9rh7/7sc2FSKDzL9FNCA== X-Google-Smtp-Source: APiQypKpJKg+l99XaISXjELNJA2l4z5LgpVW3CSoG6ysPvT4lSfNaYRk1osJcylXbneBsYLgbjHWAcz3CaPvK6E4OoM= X-Received: by 2002:a67:4c5:: with SMTP id 188mr9870229vse.43.1585613333169; Mon, 30 Mar 2020 17:08:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Mon, 30 Mar 2020 17:08:41 -0700 Message-ID: To: "Asveren, Tolga" Cc: "v3@ietf.org" Content-Type: multipart/alternative; boundary="00000000000079e7be05a21b5f58" Archived-At: Subject: Re: [V3] RIPT/RTP interworking X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2020 00:08:56 -0000 --00000000000079e7be05a21b5f58 Content-Type: text/plain; charset="UTF-8" Interworking with the RTP world would be addressed via RIPT/RTP gateways, as discussed on the "Gateway new to old" thread. On Mon, Mar 30, 2020 at 5:06 PM Asveren, Tolga wrote: > To be able to perform RIPT/RTP interworking, I think it is unavoidable > that one has to address all the existing difficulties with RTP in Public > Cloud. So, this translates to that any potential benefits of RIPT would be > mainly for cases not requiring interworking, or? > > > > Thanks, > > Tolga > > > ------------------------------ > Notice: This e-mail together with any attachments may contain information > of Ribbon Communications Inc. that is confidential and/or proprietary for > the sole use of the intended recipient. Any review, disclosure, reliance or > distribution by others or forwarding without express permission is strictly > prohibited. If you are not the intended recipient, please notify the sender > immediately and then delete all copies, including any attachments. > ------------------------------ > -- > V3 mailing list > V3@ietf.org > https://www.ietf.org/mailman/listinfo/v3 > --00000000000079e7be05a21b5f58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Interworking with the RTP world would be addressed via RIP= T/RTP gateways, as discussed on the "Gateway new to old" thread.<= /div>
O= n Mon, Mar 30, 2020 at 5:06 PM Asveren, Tolga <tasveren@rbbn.com> wrote:

To be able to perform RIPT/RTP interworking, I think it= is unavoidable that one has to address all the existing difficulties with = RTP in Public Cloud. So, this translates to that any potential benefits of = RIPT would be mainly for cases not requiring interworking, or?

=C2=A0

= Thanks,

Tolga



Notice: Thi= s e-mail together with any attachments may contain information of Ribbon Co= mmunications Inc. that is confidential and/or proprietary for the sole use = of the intended recipient. Any review, disclosure, reliance or distributio= n by others or forwarding without express permission is strictly prohibited= . If you are not the intended recipient, please notify the sender immediat= ely and then delete all copies, including any attachments.
 --
V3 mailing list
V3@ietf.org
https://www.ietf.org/mailman/listinfo/v3
--00000000000079e7be05a21b5f58-- From nobody Mon Mar 30 17:21:22 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C233A1641 for ; Mon, 30 Mar 2020 17:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=rbbn.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 kWwTjkwIl8g9 for ; Mon, 30 Mar 2020 17:21:14 -0700 (PDT) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [63.128.21.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C7663A1640 for ; Mon, 30 Mar 2020 17:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1585614073; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=mlZUN8mTjCfhyHFn9trrWID2xWRcrU1MKD1uJvnnSGE=; b=WF6CYYqjYaoZvyrbYMp7lsrmOOf1+GdLw6GZYBpmpo3Y/ykgMLMhojfQyWXEFED7KHcYUf D5jt5HbJMVgrke6BZYt3I8hD2JooNk+9PdsSNGm4LoCS8aK5Avr0VFjQvmJw2HNoJerXmy N8cIk8t1H5crKllom3k/gSaQGVK4dLA= Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2044.outbound.protection.outlook.com [104.47.66.44]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-494-3mG0OCj9PS-n6wgVgwPjlg-1; Mon, 30 Mar 2020 20:21:11 -0400 Received: from BN7PR03MB3827.namprd03.prod.outlook.com (2603:10b6:408:23::13) by BN7PR03MB4436.namprd03.prod.outlook.com (2603:10b6:408:3d::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Tue, 31 Mar 2020 00:21:07 +0000 Received: from BN7PR03MB3827.namprd03.prod.outlook.com ([fe80::1513:1e58:3df9:e82a]) by BN7PR03MB3827.namprd03.prod.outlook.com ([fe80::1513:1e58:3df9:e82a%7]) with mapi id 15.20.2856.019; Tue, 31 Mar 2020 00:21:07 +0000 From: "Asveren, Tolga" To: Justin Uberti CC: "v3@ietf.org" Date: Mon, 30 Mar 2020 20:21:07 -0400 Thread-Topic: [V3] RIPT/RTP interworking Thread-Index: AdYG76jExRB1nO8MQxeZ+fxoUNuIfQAAN/6AAABl2JA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-originating-ip: [73.80.74.66] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d5cb2a44-c98d-4caf-96ab-08d7d5096851 x-ms-traffictypediagnostic: BN7PR03MB4436: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0359162B6D x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR03MB3827.namprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(396003)(346002)(376002)(136003)(39850400004)(5660300002)(186003)(9686003)(8676002)(7696005)(81166006)(966005)(86362001)(71200400001)(2906002)(478600001)(66556008)(76116006)(66476007)(4326008)(316002)(66446008)(66946007)(6916009)(64756008)(33656002)(53546011)(8936002)(55016002)(26005)(81156014)(52536014)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WfzSXfS76ReKSTnNPUsTnCTvy9VmtE1GWaz555Xqev5NB3wuBj5E7BNQ1/4OAWYNIo4zjuWhH/kpid/dVdVvUzWrzOUxpZIljYWabESUN5NRGywsU3Hxer7PFPPMalR7aPotGAsjBd9WtM5hLZQHO0J/rttc8+9OvNqjR7U859ADTdqXcmf6aJrYM/NegHb9wmrGbmPh4OTh4OROCmJc34U/6E7L/eKVkA+yVjFyfNBXQNIk20sbj6pS/2fFiwTWInil+kFTNZj1ld6HApU3k6D68lvKgXwnrPgLDex9kz4vRovUEbTmB4Bka/H78EUeZ9f3WB5hdDxMwBx8Nj02bMa4KY71N4ytri4/AjzV/whMjXbmh6E6mbJ4ZxnJp2s+Lqdo/3KzkTsxNqQKB1ZmR+QyFUIDYAOA99+6OmDVoO1y4IANHy+o7wUc2uTh88BVo4BUe4r1P9/lllvfFint4PgdH5Vavwgxrt5eyLxIzf5VgnY3lp8ZtmUS9haI4XSSDzINxAXO1bJTEzUNsFlvFA== x-ms-exchange-antispam-messagedata: ng5mNnbjcybc79KO+TzdeQcStb85jAyLWbQBaidQTY0vqr5C7KlgVGuXcXBIKFpzM7SF9+I4XM7ap/r3ub5xaPSfxxVe4XvKm7GtWp8gj2eW8F8DQg/NNB2pPa1vZMRptsbNmML/Ka7XUmAiwcDIfQ== x-ms-exchange-transport-forked: True x-mc-unique: 3mG0OCj9PS-n6wgVgwPjlg-1 x-originatororg: rbbn.com x-ms-exchange-crosstenant-network-message-id: d5cb2a44-c98d-4caf-96ab-08d7d5096851 x-ms-exchange-crosstenant-originalarrivaltime: 31 Mar 2020 00:21:07.5904 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: XU3EYINo+iaPF0+9Iu0IPrWr6Ew8fULgvq6IzKq3KVnlrSYw7XYTDa75cfoRyv6PJCQt/1SkySeouDVCoKNR3Q== x-ms-exchange-transport-crosstenantheadersstamped: BN7PR03MB4436 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: rbbn.com Content-Type: multipart/alternative; boundary="_000_BN7PR03MB38271A4A718B6CC515A17364A5C80BN7PR03MB3827namp_" Archived-At: Subject: Re: [V3] RIPT/RTP interworking X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2020 00:21:20 -0000 --_000_BN7PR03MB38271A4A718B6CC515A17364A5C80BN7PR03MB3827namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 WWVzLCBidXQgR1dzIG1heSBhbHNvIHJlc2lkZSBpbiBQdWJsaWMgQ2xvdWQuIEluIHdoaWNoIGNh c2Ug4oCcUlRQIHByb2JsZW1z4oCdIHdvdWxkIHBlcnNpc3QgQUZBSUNULg0KDQpUaGFua3MsDQpU b2xnYQ0KDQpGcm9tOiBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2dsZS5jb20+DQpTZW50OiBN b25kYXksIE1hcmNoIDMwLCAyMDIwIDg6MDkgUE0NClRvOiBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVy ZW5AcmJibi5jb20+DQpDYzogdjNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVjNdIFJJUFQvUlRQ IGludGVyd29ya2luZw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTk9USUNF OiBUaGlzIGVtYWlsIHdhcyByZWNlaXZlZCBmcm9tIGFuIEVYVEVSTkFMIHNlbmRlcg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KSW50ZXJ3b3JraW5nIHdpdGggdGhlIFJUUCB3 b3JsZCB3b3VsZCBiZSBhZGRyZXNzZWQgdmlhIFJJUFQvUlRQIGdhdGV3YXlzLCBhcyBkaXNjdXNz ZWQgb24gdGhlICJHYXRld2F5IG5ldyB0byBvbGQiIHRocmVhZC4NCg0KT24gTW9uLCBNYXIgMzAs IDIwMjAgYXQgNTowNiBQTSBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5AcmJibi5jb208bWFpbHRv OnRhc3ZlcmVuQHJiYm4uY29tPj4gd3JvdGU6DQpUbyBiZSBhYmxlIHRvIHBlcmZvcm0gUklQVC9S VFAgaW50ZXJ3b3JraW5nLCBJIHRoaW5rIGl0IGlzIHVuYXZvaWRhYmxlIHRoYXQgb25lIGhhcyB0 byBhZGRyZXNzIGFsbCB0aGUgZXhpc3RpbmcgZGlmZmljdWx0aWVzIHdpdGggUlRQIGluIFB1Ymxp YyBDbG91ZC4gU28sIHRoaXMgdHJhbnNsYXRlcyB0byB0aGF0IGFueSBwb3RlbnRpYWwgYmVuZWZp dHMgb2YgUklQVCB3b3VsZCBiZSBtYWlubHkgZm9yIGNhc2VzIG5vdCByZXF1aXJpbmcgaW50ZXJ3 b3JraW5nLCBvcj8NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCk5vdGljZTogVGhpcyBlLW1haWwgdG9nZXRoZXIgd2l0aCBhbnkgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gb2YgUmliYm9uIENvbW11bmljYXRpb25zIEluYy4g dGhhdCBpcyBjb25maWRlbnRpYWwgYW5kL29yIHByb3ByaWV0YXJ5IGZvciB0aGUgc29sZSB1c2Ug b2YgdGhlIGludGVuZGVkIHJlY2lwaWVudC4gQW55IHJldmlldywgZGlzY2xvc3VyZSwgcmVsaWFu Y2Ugb3IgZGlzdHJpYnV0aW9uIGJ5IG90aGVycyBvciBmb3J3YXJkaW5nIHdpdGhvdXQgZXhwcmVz cyBwZXJtaXNzaW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBh bmQgdGhlbiBkZWxldGUgYWxsIGNvcGllcywgaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cy4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQotLQ0KVjMgbWFpbGluZyBsaXN0DQpWM0Bp ZXRmLm9yZzxtYWlsdG86VjNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3YzPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjM+DQo= --_000_BN7PR03MB38271A4A718B6CC515A17364A5C80BN7PR03MB3827namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHls ZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwv aGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1X b3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPlllcywgYnV0IEdXcyBtYXkgYWxzbyByZXNp ZGUgaW4gUHVibGljIENsb3VkLiBJbiB3aGljaCBjYXNlIOKAnFJUUCBwcm9ibGVtc+KAnSB3b3Vs ZCBwZXJzaXN0IEFGQUlDVC48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+VG9sZ2E8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xh c3M9TXNvTm9ybWFsPjxiPkZyb206PC9iPiBKdXN0aW4gVWJlcnRpICZsdDtqdWJlcnRpQGdvb2ds ZS5jb20mZ3Q7IDxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXJjaCAzMCwgMjAyMCA4OjA5IFBN PGJyPjxiPlRvOjwvYj4gQXN2ZXJlbiwgVG9sZ2EgJmx0O3Rhc3ZlcmVuQHJiYm4uY29tJmd0Ozxi cj48Yj5DYzo8L2I+IHYzQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW1YzXSBSSVBU L1JUUCBpbnRlcndvcmtpbmc8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2Vu dGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxp Z249Y2VudGVyPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5OT1RJQ0U6IFRoaXMgZW1haWwgd2Fz IHJlY2VpdmVkIGZyb20gYW4gRVhURVJOQUwgc2VuZGVyPG86cD48L286cD48L3A+PGRpdiBjbGFz cz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGhyIHNp emU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JbnRlcndvcmtpbmcg d2l0aCB0aGUgUlRQIHdvcmxkIHdvdWxkIGJlIGFkZHJlc3NlZCB2aWEgUklQVC9SVFAgZ2F0ZXdh eXMsIGFzIGRpc2N1c3NlZCBvbiB0aGUgJnF1b3Q7R2F0ZXdheSBuZXcgdG8gb2xkJnF1b3Q7IHRo cmVhZC48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiBNb24sIE1hciAzMCwgMjAy MCBhdCA1OjA2IFBNIEFzdmVyZW4sIFRvbGdhICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5A cmJibi5jb20iIHRhcmdldD0iX2JsYW5rIj50YXN2ZXJlbkByYmJuLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbic+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8nPlRvIGJlIGFibGUgdG8gcGVyZm9ybSBSSVBUL1JUUCBpbnRlcndvcmtpbmcsIEkgdGhp bmsgaXQgaXMgdW5hdm9pZGFibGUgdGhhdCBvbmUgaGFzIHRvIGFkZHJlc3MgYWxsIHRoZSBleGlz dGluZyBkaWZmaWN1bHRpZXMgd2l0aCBSVFAgaW4gUHVibGljIENsb3VkLiBTbywgdGhpcyB0cmFu c2xhdGVzIHRvIHRoYXQgYW55IHBvdGVudGlhbCBiZW5lZml0cyBvZiBSSVBUIHdvdWxkIGJlIG1h aW5seSBmb3IgY2FzZXMgbm90IHJlcXVpcmluZyBpbnRlcndvcmtpbmcsIG9yPzxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5Ub2xn YTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJv dHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6IkFy aWFsIixzYW5zLXNlcmlmJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBjbGFzcz1N c29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWYnPjxociBz aXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlcj48L3NwYW4+PC9kaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIixz YW5zLXNlcmlmJz5Ob3RpY2U6IFRoaXMgZS1tYWlsIHRvZ2V0aGVyIHdpdGggYW55IGF0dGFjaG1l bnRzIG1heSBjb250YWluIGluZm9ybWF0aW9uIG9mIFJpYmJvbiBDb21tdW5pY2F0aW9ucyBJbmMu IHRoYXQgaXMgY29uZmlkZW50aWFsIGFuZC9vciBwcm9wcmlldGFyeSBmb3IgdGhlIHNvbGUgdXNl IG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIGRpc2Nsb3N1cmUsIHJlbGlh bmNlIG9yIGRpc3RyaWJ1dGlvbiBieSBvdGhlcnMgb3IgZm9yd2FyZGluZyB3aXRob3V0IGV4cHJl c3MgcGVybWlzc2lvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIHRoZW4gZGVsZXRlIGFsbCBjb3BpZXMsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMuPG86 cD48L286cD48L3NwYW4+PC9wPjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHls ZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIixzYW5zLXNlcmlmJz48aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1j ZW50ZXI+PC9zcGFuPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4tLSA8YnI+VjMgbWFp bGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpWM0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PlYzQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3YzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby92MzwvYT48bzpwPjwvbzpwPjwvcD48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+ PC9ib2R5PjwvaHRtbD4NCg== --_000_BN7PR03MB38271A4A718B6CC515A17364A5C80BN7PR03MB3827namp_-- From nobody Tue Mar 31 22:35:34 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636DA3A0C69 for ; Tue, 31 Mar 2020 22:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.699 X-Spam-Level: X-Spam-Status: No, score=-7.699 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=SXdYlh6J; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WUvHuNBE 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 i3V2qt9QPr9N for ; Tue, 31 Mar 2020 22:35:30 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1FF83A0C66 for ; Tue, 31 Mar 2020 22:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5878; q=dns/txt; s=iport; t=1585719329; x=1586928929; h=from:to:subject:date:message-id:mime-version; bh=UJlOwR8ZHTDdDOoQ1VjUP/nJPzlO9wiUBCoXGzW4L4I=; b=SXdYlh6Jo7B19QcgzPgeJCAGJsGMYJ5CyQiGe5+yMLVjiSu6FHSs5YLe lX5TdzJycHNr7Hc6Vv48hdu83AUNaaUoJSRTqrL90RXzYxxKgB23kaS51 MTO6SrxI7yrUzoAUBEaknVzS559pTCpWB5PZcz74xWzQfXShPHPLu1itl k=; IronPort-PHdr: =?us-ascii?q?9a23=3ANo0RKhBrEY2ydexAWUjdUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs13kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuKezjaSUmDexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqDwCfJ4Re/51dJa1mHgELHIFwC4E?= =?us-ascii?q?lLyknBWxYIAQLKgqHVQOKbU6CEZM8hGGBLoEkA1QKAQEBDAEBLQIEAQGGeyQ?= =?us-ascii?q?2Bw4CAwEBCwEBBQEBAQIBBQRthVYMhXABAQICARIbEwEBIwcKBAQNAQg/ORQ?= =?us-ascii?q?TBAESIoMFgX5NAw4gAaMCAoE5iGKCJ4J/AQEFgkWCYhiCDAmBOIsSgR8agUE?= =?us-ascii?q?/JmuCRFA+ij6NaokQmXcKgj2ReYUeHYJMMYgAkHGPG5wFAgQCBAUCDgEBBYF?= =?us-ascii?q?ZDCaBWHAVO4JsUBgNjh2BJwECgkmKVXSBKYxUAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.72,330,1580774400"; d="scan'208,217";a="456063005" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Apr 2020 05:35:28 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 0315ZSO4023669 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Apr 2020 05:35:28 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 1 Apr 2020 00:35:28 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 1 Apr 2020 00:35:27 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 1 Apr 2020 00:35:27 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H3jmXe/zYXx3zGQT0JmZHhiMdX+BADnYFwLgnbz8Oloa4Qr/wcDOcULGZGStvoeaJ88dQTAJEEd0gM6K0zFgFIxJbP5FBpwcslT26HqXPWQIHwA+zsU/mdjzoZyupCiSL7e8czGfOCkWV7z+r7U7mVB5GeJjvPSZ/Wce4TwEkSP8VVE+1AMJ7IKDm5LVz9FuwunMh/9LjNkD0Mg1fSHeJPpqt5eLvg3Yh70bNB/J1fKCKRJvxBbk6DbCDyJ2oVPz3VtjnqrngSmVlOcx8zG5W4QCNHOdIp3Q/6ZmiBXVL+RwagRSqcR5y3bmA2I+OBKvf2kx33TaYMbyAHrNIvo+uw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=91sNUyJQs0i78dlugPdE1Oze1bR1zhLnWLk8MO1oVAI=; b=KgUvTzoGDWVZE5rCZUEuTz84IVLPZ7gMBNUX+RxuJL1eK14dcaABI8G8+6wz0OJzPkw4kTqf/tzuqid95rmla7MHjTUfgxIJzjvxSkCc/RI5RwtQzGGNqAqEyRWqQh+zqPtIZZBGBcn1DbAs2kzpjTy+isItgzKjsvAFYHgyygkPKbd/B4KyoSseV375yLuv6VScAg8DikS11ALFi42mErc10NZfHZoVnkFFmk1t23YTF/gLiekkjx42W2o1ySLxstHyN271bsninx5ziGvcqFV6g2Xc6sEr4tm/Ws4K3uuBZ7KyhAiKbeOWYq2T1qJk3BSQ+NAzZdIf5lf448U9bA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=91sNUyJQs0i78dlugPdE1Oze1bR1zhLnWLk8MO1oVAI=; b=WUvHuNBEs087o3fMLJPIP9YaFBPviFyaLZoMnSN7UYBithTMYKOsy85a0rihheuIkAi3k9dDb0evtL0tNjJKsWTB4hAjFF3y0gmeR4uwyoBkrNKQxqA6JuoP2cswX5ygixB/u2xMV9R9NK3XClZWN+rMksDUto1uCjA+utRGr5o= Received: from BN7PR11MB2753.namprd11.prod.outlook.com (2603:10b6:406:b0::23) by BN7PR11MB2787.namprd11.prod.outlook.com (2603:10b6:406:b4::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Wed, 1 Apr 2020 05:35:26 +0000 Received: from BN7PR11MB2753.namprd11.prod.outlook.com ([fe80::acc4:5dcb:804c:2e1c]) by BN7PR11MB2753.namprd11.prod.outlook.com ([fe80::acc4:5dcb:804c:2e1c%5]) with mapi id 15.20.2856.019; Wed, 1 Apr 2020 05:35:26 +0000 From: "Mo Zanaty (mzanaty)" To: "Asveren, Tolga" , "v3@ietf.org" Thread-Topic: [V3] LB / Failure Detection Thread-Index: AQHWB+dY9xOXTD1dv0iR+okpkFJ3Fw== Date: Wed, 1 Apr 2020 05:35:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mzanaty@cisco.com; x-originating-ip: [107.15.209.8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aa95f89f-06c0-4678-beb0-08d7d5fe7b96 x-ms-traffictypediagnostic: BN7PR11MB2787: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(366004)(376002)(136003)(39860400002)(346002)(36756003)(110136005)(26005)(71200400001)(2906002)(186003)(316002)(478600001)(6512007)(2616005)(81156014)(76116006)(6506007)(6486002)(53546011)(86362001)(81166006)(66446008)(66476007)(66556008)(8676002)(66946007)(8936002)(64756008)(5660300002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5qiiTmYnrix/vXfj/L8EY6Ksmk7v8ax4TMAuL594N6qBktQSrVWT878pejOS760Cd2UImOOYaInPGh2UkD9eqvBFeQ7XDw87/czfIOkTv0AS/gUJ4AeMftXMOMwad07HV1KXX013qwI4Lke23D5gROVJCkE48fnJ1QDK67m5Yd+VfMNSl5aLCA1qbI73VVpkqshG5WnJ1KWOJYDERxa5tsmg1LZEQjTkmbql4VIDolAMaiZZUYBleTlUckPv8Euf6YFVhhFMmD9FhYgp0pRq4sSZHbC3Yik56F+y6ntch977b3uBDFZLsNpWCI3ywQELsLHVTW1FAA/ZmfrJdn48wBDEgIm74q8u8p3no6pM3HWBM5pDRIiUG4J2ahUqwV5AOP6NUhLW+F+9DmFe1JWpQAYUDVY88w+mPsLqBWNMqhGPGEnmmAFe850USVohpWtn x-ms-exchange-antispam-messagedata: 0y1Xur16gidKWw1ynvaU2zfJ6u5n5uz/2H/5Yj7NxBB3UqT4g4gh23tZdT0/IwAbFa9O/vVLI9S8dg5J7/BTVtu0/8kgau6as1q2fnl7sDPgpUCdmFx4jjwn4n4U3BqVoEZT11euc27g1QgXAOuQEA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DAA98BE896CBEmzanatyciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: aa95f89f-06c0-4678-beb0-08d7d5fe7b96 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2020 05:35:26.5912 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VhjeUmYqJtW8ReHc1NoytlREn9Jp0RmQM7uKt2FaFz0wGEA5oCnT+GhBi3FxOweVHjyE6TAIa1r6osye7q7y2A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2787 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [V3] LB / Failure Detection X-BeenThere: v3@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 05:35:32 -0000 --_000_DAA98BE896CBEmzanatyciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > In a nutshell, what would one gain by using a HTTP LB instead of L4 LB? There are many reasons why HTTP apps use HTTP LB instead of (or in addition= to) L4 LB, such as flexibility, programmability, feature rich ecosystem, e= tc. The HTTP list may be a better place for such a question and discussion = though, since this is not specific to RIPT, but applies to all HTTP apps. Thanks, Mo On 3/30/20, 7:19 PM, "V3 on behalf of Asveren, Tolga" on behalf of tasveren@rbbn.com> wrote: A basic question about how RIPT would make things better compared to RTP in= terms of making use of Public Cloud Load-balancers: With RTP: One can use L4 LB distributing traffic to a Redundancy Group. The= pain point is that LB is slow in detecting failures of Redundancy Group me= mbers. With RIPT media: One can use HTTP LB distributing traffic a Redundancy Grou= p. I would think failure detection characteristics will be similar to L4 LB= and delayed failure detection issue would continue to be an issue. In a nutshell, what would one gain by using a HTTP LB instead of L4 LB? Thanks, Tolga ________________________________ Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. that is confidential and/or proprietary for th= e sole use of the intended recipient. Any review, disclosure, reliance or d= istribution by others or forwarding without express permission is strictly = prohibited. If you are not the intended recipient, please notify the sender= immediately and then delete all copies, including any attachments. ________________________________ --_000_DAA98BE896CBEmzanatyciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6A8D8AFF7A57D54C940C9F9DEDC1FB8C@namprd11.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

> In a nutshell, what would one gain by using a H= TTP LB instead of L4 LB?


There are many reasons why HTTP apps use HTTP LB instead of (or in add= ition to) L4 LB, such as flexibility, programmability, feature rich ecosyst= em, etc. The HTTP list may be a better place for such a question and discus= sion though, since this is not specific to RIPT, but applies to all HTTP apps.

Thanks,
Mo

On 3/30/20, 7:19 PM, "V3 on behalf of Asveren, Tolga" <v3-bounces@ietf.org on behalf of tasveren@rbbn.com> wrote:

A basic question about how RIPT would make things be= tter compared to RTP in terms of making use of Public Cloud Load-balancers:=

 

With RTP: One can use L4 LB distributing traffic to = a Redundancy Group. The pain point is that LB is slow in detecting failures= of Redundancy Group members.

With RIPT media: One can use HTTP LB distributing tr= affic a Redundancy Group. I would think failure detection characteristics w= ill be similar to L4 LB and delayed failure detection issue would continue = to be an issue.

 

In a nutshell, what would one gain by using a HTTP L= B instead of L4 LB?

 

Thanks,

Tolga



Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. that is confidential and/or proprietary for th= e sole use of the intended recipient. Any review, disclosure, reliance or d= istribution by others or forwarding without express permission is strictly prohibited. If you are not the inte= nded recipient, please notify the sender immediately and then delete all co= pies, including any attachments.
--_000_DAA98BE896CBEmzanatyciscocom_--