From nobody Fri Nov 5 04:40:30 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A243A0D4D for ; Fri, 5 Nov 2021 04:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_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 SebYeouKQpbZ for ; Fri, 5 Nov 2021 04:40:20 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70040.outbound.protection.outlook.com [40.107.7.40]) (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 069963A0ACD for ; Fri, 5 Nov 2021 04:40:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j3Jz4pWaIqCHDp2BldF6XONiAWUSpGKBZSfpLX6ZxSq5sOdzM0ziMM6UuPuuVYoUH3GX/UorvXAc/dJOnbzeaFxEgfr2vf92aVNINDaHUeOsQeogMZ/7p3ny1RX2t2UgMWOA7jpdlJuiI3Ekb5hzINq2R9z4Y6EehQg+WihI1z0cwYv2eGqEyIo32sDGQ7J7sGoATREMIk1LzzbnMzFLeJtWGd6ApwcANj4ZH5ud9AvqNK42hQaJVNfOGHAYmTbFm1HI6urFjax8K+O6O47ovJQ17wq0/pZVTNHGmg7NnP5uVmbcf8AcmcJyhw7Dm4Bv9rNZhjjeuxrKms5NPB8XPQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dqZ4JHqdfjJZ5CpKyOFptQrz6E5D3MFHnmFHedP3rDI=; b=bQ8WURikfveWf70PTz+jQ1o70grUFIXqzPVK0nOEfd0eFpzYmsd4feUmz5q287X9IJy/YX0wZvFrJ58RkQqwIugMXmeW7gtRaFbmK/S8UUXoxs7zp4gVlvpcpGcoKtpIGRuVeZoKG9mhD7X1uSTIvjpVWBpOta0IxAa1LLTNFlqtvc6g8Volgxo5m4YL/vffIEGu6lxtZMwHc3ZJfZPaXnbczOrqOtcL8vS5ySTENcmjCaqXrTBtEdcY9AXmxpra5seOFAwhT+S7IC+aam45OM1A+8hv1NmWmqfawxCDNeESoP7aszhW7IiC+0nbbTIEIe9Xkf+XtTZzEh5/LYehzA== 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=dqZ4JHqdfjJZ5CpKyOFptQrz6E5D3MFHnmFHedP3rDI=; b=Lp/FtWoQZdLIKtaPYCLWGdQHi3PFqc1AXNgutOMh15BlfCLNfYR7Cao4VPWSK5gkpE7wIMuUjMGVDtbOH3gah5Ks6e5KQRvWftnDY3BKIlqZxaEakZtse/ZIKN3+eT5zbjqC28LkEHUYk1n6kMHiVVkTmUaTFZbPS28osgSrE6U= Received: from HE1PR07MB4441.eurprd07.prod.outlook.com (2603:10a6:7:9f::27) by HE1PR07MB3515.eurprd07.prod.outlook.com (2603:10a6:7:33::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.9; Fri, 5 Nov 2021 11:40:15 +0000 Received: from HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173]) by HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173%2]) with mapi id 15.20.4690.008; Fri, 5 Nov 2021 11:40:15 +0000 From: Christer Holmberg To: Justin Uberti CC: Cullen Jennings , RTCWeb IETF , Roman Shpount Thread-Topic: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt Thread-Index: AQHXylf+AMpeemP+/Umn4mKjUNsZYKvlgWaAgAAD7wCAAFFxgIAEazaAgAAJNoCAAAJcgIAARq+AgAAFWYCAAD0AgIABPVtQgABvX4CAAHTpwIABOTMAgAB5B32AAGQiAIAA528AgAASO+CAAHHigIAABbShgAAQjQCAADc8UIABZ1UwgAIoRACAAAqQUIAAEN4AgABrqcQ= Date: Fri, 5 Nov 2021 11:40:15 +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: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9c159836-8bb3-4ca9-e1d9-08d9a051090d x-ms-traffictypediagnostic: HE1PR07MB3515: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: O7Z8kXccXn1YhY7qW9DoFC1rxa9VnJPHjdZLKLPl8Xbo/agEeFvToL5j7L8ifO4fgu8BzLUzuyCl4nDZ9ooCzvvCBRiMsu0r4jdx4q9vkJwEHQ2OMHjRoGQlpXcaM1T3vTWoQ36J3GeRxJc0Ew2oBiW3j+46tIQj6mYQfmwrO1KmclOrvktm0PjuMB+egF3c+8PBh2nIhMWwJhZu0WO8kJS6KNf1Xpp8ug59cpp+baAU8+SYblEYvHSbF+GagC80ARsYbKIgJQAeMxBUo/+DmrF295XQvJor56tWzy6eJ6KQI+zfwMiddWhRhK32PXVCnVE1bEBN0QtNcVrxaTjS7I2WY0o7opRwAd9T/rtrCBPBcnR3hAEYd3QzoenvJvFPvArrn0/4TEjySquKEYfjEmli56zK8j+PlamhUZMougf819npUQPcN84DnIQMiF97ISv8EUoSJLp55s6P7GE1vbNuXG1lr9XBRepHSZPWanJy7gr+KWfKBkX6kUSUX4TzydvftODbz1DUtlggTx2814j7JWLmqjHWCUIavr2klQfQe66F8lDUfqrSwF0sE0vQyrA4OwZQsvQNRkLgzzRiNa/4QYNc2xK+z1II5jWGpnLQZ3W2abls79WcXFhOKadUI0KMei30N0CyurXKqBQUvmdNUdrPKMGLfHjmw0HwRHV96R4/jeY24wXrwt9Lido4E0+eAZ/BFqgpmN+0nt9n6RNnxWo0HP6u0BX2Zh3MW3kNKVawXQ0hbJmb02oOZ+KibzBInytHvnw3gLDV5ZEkr9Lag9Yb8/i3twhKYDoBdZIc7BBR/J+llB1SmFPyqD/9a4kegj2YEFEpUiWvgDqGuw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4441.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(5660300002)(316002)(6506007)(82960400001)(26005)(53546011)(52536014)(4326008)(76116006)(45080400002)(71200400001)(33656002)(54906003)(186003)(44832011)(966005)(2906002)(8676002)(8936002)(55016002)(9686003)(66476007)(6916009)(64756008)(66446008)(122000001)(38070700005)(166002)(66556008)(86362001)(38100700002)(7696005)(66946007)(83380400001)(30864003)(508600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?pX6rIqSRlnM/T0gUJoP40jK26g125pyOzFLyErY5AOS8qnjKv2hqI3MM?= =?Windows-1252?Q?AFBb7/MDZdNX9654Sq91B6TnAts9EAmOca8A0f02iVePZiEa/2HDQw8S?= =?Windows-1252?Q?uWnWAHPIFakO5AZ/UE/ayVmBcBYp3byS6E0O9D/TyH9ubp9Tn6AljvwF?= =?Windows-1252?Q?HizLzZk22oLgOuA/3PVexWr6jztNven/LIdXtmGWbr1Pxzol50a6bImo?= =?Windows-1252?Q?Q0mAGyDgYjUkIbbvAnrLY6HSakbzsVGFhScf8Pd8xXdjcI6tvM0laPHP?= =?Windows-1252?Q?N5Tj6/PBofP4DS3jJ6zWjMMQd7BCTsKF+94J18lzDWXJi+ru3ZMuhDQD?= =?Windows-1252?Q?NYYwcJ7rIrPKf0KLrvQwUrNshN3UhodHZUDlAY7Wh4JlSAnyPYffWp3t?= =?Windows-1252?Q?zC9btB4jJgjwl1zwEAn1HyToGOI79UPMBpAr6F4HG7xikl/+zUX/AEYi?= =?Windows-1252?Q?YZnZ1g1BmxNXdtITK2cPOZe+tDH3xDPb90sCfY+y5Iy1XY1O3r0ynZ9j?= =?Windows-1252?Q?iJhORvMyvLdL7iCRyCOFEOypQbidLNYoml16K1jtH95wKQ7Yj5/wKZ4E?= =?Windows-1252?Q?Y2HUTZbBrvLs1ZwiDI+wSAmPCWAWYMM47JT9m65BnbcwsFYX03K0cNBB?= =?Windows-1252?Q?JeVM4tUOn6BaGw0pNrVs9elCjaWmuK/4S2nP0BUQXCj/ZybAfJewjdXs?= =?Windows-1252?Q?Ej0DI0g0mIr86nZIzPmkyRd5r2l16/D/10X8DtWTbuLrtjDp2KZG2HdK?= =?Windows-1252?Q?QCBoEBO0Ckkxq8NRNcSgnG7SUfSBaa2688sVAJh0UQ0jFfpPDVpHexes?= =?Windows-1252?Q?RVzbYEMqEdy22UDLdE9YIPozeL5p3XLjQiVpONUIxh5oNvmH13nYcCmg?= =?Windows-1252?Q?al4WIiW9IIaZbctHfSzJdar71X3u8EnRLXE/q8IDRHEH48QszRIKzKDm?= =?Windows-1252?Q?7MSUiqjEOMCJwfeg7Ak9V73QtEX7bVw3pYQLPnc3i0JtRxknzMdVKsPw?= =?Windows-1252?Q?BlnUa+LdM3r6J6/GW1b46ylM8bTlT/FEqCklXLT+ouO0AgRJsFsDgBuk?= =?Windows-1252?Q?EvlXInmoJFOAki3AcvQCnUjIGnT3oCHmaCyFKqN+UxqRlzkBkHjuBKx1?= =?Windows-1252?Q?y2MNYlN9Ric1pcStI3A0F753J/8xGqu58mtbj8FbYkgJ0NyP59llPTs8?= =?Windows-1252?Q?sGL7y9ZqtvfvbKDw6UVV87F/MRWE7FCP4Ygv2sjZmhTVbV++qzvqSakQ?= =?Windows-1252?Q?lImbsPm25Tsl0grSEzkVm2KHc6bGLUgsaToZmPQCK2pEyp+iX8mK0O2G?= =?Windows-1252?Q?CN/6Jw/9/ZSlgLg8xrxKzn3Q74y6NEfI5z5JGDrzLJgtXmH8BAoTp1rK?= =?Windows-1252?Q?pa70jLKpVSZ9M6fyp8u9TADGSY8jNF+hCF3bqfE58XTlsVSlm58oBGoE?= =?Windows-1252?Q?HqJ5Ms8P2poD2t62YinUgwBKpzwSKyvJNktPEoxadMavsn/hWlJ1SUVE?= =?Windows-1252?Q?48mf4SqQI9jN9nRcxlo7QpulrWj+k11Z/AW/DdCRuFRF3GBGAeWfK0V9?= =?Windows-1252?Q?LMCAmFdeVQrMZGthSdZubC9vfvFY4+iRTOcfP22tQEpUf46Yt5ds4qw5?= =?Windows-1252?Q?Gng6pr9jCc3PM962AacFEG3rzSVphZtZIW144VbYGCtE8pC7jsRzMzGI?= =?Windows-1252?Q?cr/qthde5gbCqUVWu87jvb8IRMcv7frVitDNbWmZK/2JF5Zup8u9W7Uj?= =?Windows-1252?Q?MsxeKH0hbPIVgPhewyaS/qs5tOoniUOTqn/zSh43MW+tXerhrNxhdt91?= =?Windows-1252?Q?IIcqZWYLLNYUbZw3d3gbY7DVCtg=3D?= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB44416A47EAA75FA00C2D8226938E9HE1PR07MB4441eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4441.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9c159836-8bb3-4ca9-e1d9-08d9a051090d X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2021 11:40:15.2766 (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: V6bQyf42IeWqDISsdR4d9y/rHYB7bO+/HiKklVGpprBOjnlNY+j3/rTEnbPV82BD0Yt0g2OAjg1UTT8va9UbdW6BXpBsWi89UUneFSudSxc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3515 Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 11:40:28 -0000 --_000_HE1PR07MB44416A47EAA75FA00C2D8226938E9HE1PR07MB4441eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, If the text is something that everyone can agree on, then I suggest we go w= ith that. It does not require any changes or assumptions regarding the endp= oint behaviour. Regards, Christer Get Outlook for iOS ________________________________ From: Justin Uberti Sent: Friday, November 5, 2021 7:12:02 AM To: Christer Holmberg Cc: Cullen Jennings ; RTCWeb IETF ; Roman S= hpount Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc88= 29bis-01.txt I still feel the cleanest solution would be to allow the answerer to accept= a subsequent offer as an initial offer (since then things will work in 3PC= C with no SDP rewriting), and AFAIK no technical reason has been put forth = to explain why this cannot work. However, I can live with the alternate solution put forth by Christer, and = the proposed text seems reasonable to me. Justin On Thu, Nov 4, 2021 at 9:14 PM Christer Holmberg > wrote: Hi, The question was whether an endpoint would be assumed to be able to accept = a subsequent offer (same address:port in each m- line) as an initial offer.= I did not agree to that. However, the suggestion a couple of days ago, which people seemed to agree = to, does NOT make that assumption anymore. Nothing out of the normal would = be assumed by endpoints, and instead the 3GPP controller will act as a B2BU= A and modify the SDP if needed. Regards, Christer From: Cullen Jennings > Sent: perjantai 5. marraskuuta 2021 5.34 To: Christer Holmberg >; Roman Shpount >; Justin Uberti > Cc: RTCWeb IETF > Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc88= 29bis-01.txt Could we have a quick call on this next week during one of the breaks. I ha= ve tried to follow this whole thread and some it does not make much sense t= o me. I=92m a bit lost on what the varios proposed resolutions are. On Nov 3, 2021, at 12:38 PM, Christer Holmberg > wrote: Justin, are you ok with the suggested text? I would probably be a good idea= to refer it in 8829bis. Regards, Christer ________________________________ From: rtcweb > on b= ehalf of Christer Holmberg > Sent: Tuesday, November 2, 2021 11:13 PM To: Roman Shpount > Cc: Justin Uberti >; RTCWeb I= ETF > Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc88= 29bis-01.txt Hi, >This makes it much better. I think it is missing a couple of commas ("In s= ome 3PCC scenarios," and "In the rewritten offer,") but works for me. I can add them when I add the text to the draft, but I think the RFC editor= will most likely notice such thing. >I have changed the section name so it is clear that it applies to JSEP as = well, not just SIP. Sure, that=92s fine. Regards, Christer On Tue, Nov 2, 2021 at 1:24 PM Christer Holmberg > wrote: Hi, Eventhough I would not like to make more changes than necessary, I am fine = with "3PCC Considerations". However, your suggested text is very difficult to understand in some places= , so let me give it a try. (The first paragraph is generic, the second SIP specific, and the third BUN= DLE specific.) --- 3PCC Considerations In some 3PCC scenarios a new session will be established between an endpoin= t that is currently part of an ongoing session and an endpoint that is curr= ently not part of an ongoing session. The endpoint that is part of a sessio= n will generate a subsequent offer that will be forwarded to the other endp= oint by a 3PCC controller. The endpoint that is not part of a session will = process the offer as an initial offer. The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client = (UAC) to send a re-INVITE request without an SDP body (sometimes referred t= o as an empty re-INVITE). In such cases, the User Agent Server (UAS) will i= nclude an SDP offer in the associated 200 OK response. If the UAS is a part= of an ongoing session, it will include a subsequent offer in the 200 OK re= sponse. The offer will be received by a 3PCC controller (UAC) and then forw= arded to another User Agent (UA). If the UA is not part of an ongoing sessi= on, it will process the offer as an initial offer. When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers, and it cannot be assume= d that a UA is able to correctly process a subsequent offer as an initial o= ffer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offer in= to a valid initial offer, following the procedures in (Section 7.2), before= it forwards the offer to a UA. In the rewritten offer the 3PCC controller = will set the port value to zero (and include an SDP 'bundle-only' attribute= ) for each "m=3D" section within the BUNDLE group, excluding the offerer-ta= gged "m=3D" section. ________________________________ From: Roman Shpount > Sent: Tuesday, November 2, 2021 6:33 PM To: Christer Holmberg > Cc: Justin Uberti >; Justin Uberti >; RTCWeb IETF > Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc88= 29bis-01.txt How about we replace the SIP Considerations with: 3PCC Considerations In some 3PCC scenarios, an offer generated during an ongoing session, i.e.,= a subsequent offer, will be used by a 3PCC controller to establish a new s= ession and forwarded as an initial offer to another endpoint that is curren= tly not part of a session. For example, the Session Initiation Protocol (SIP) [RFC3261] allows a User = Agent Client (UAC) to send a re-INVITE request without an SDP body (sometim= es referred to as an empty re-INVITE). In such cases, the User Agent Server= (UAS) will include an SDP offer in the associated 200 OK response. If UAS = is a part of an ongoing session, it will include a subsequent offer in the = 200 OK response. The offer will be received by a 3PCC controller (UAC) and = then forwarded to another User Agent (UA) as an initial offer. When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers. It cannot be assumed th= at a subsequent offer is a valid initial offer and that the endpoint that e= xpects an initial offer will properly process such a subsequent offer. Ther= efore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid= initial offer before it is used to establish a new session. To make the su= bsequent offer a valid initial offer, 3PCC will need to modify all the non-= tagged m=3D lines to include the bundle-only attribute and set the m=3D lin= e port to zero. _____________ Roman Shpount On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg > wrote: Hi, What about something like this: --- OLD: =93The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Clie= nt (UAC) to send a re-INVITE request without an SDP body (sometimes referre= d to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP Offer in the= associated 200 OK response. This is typically used for 3rd Party Call Cont= rol (3PCC) scenarios. >From a BUNDLE perspective, such SDP Offer SHOULD be generated using the pro= cedures defined in Section 7.2.=94 NEW: =93The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Clie= nt (UAC) to send a re-INVITE request without an SDP body (sometimes referre= d to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP offer in the= associated 200 OK response. This is typically used for 3rd Party Call Cont= rol (3PCC) scenarios. In some 3PCC scenarios the UAS will be part of an ongoing session, and will= therefore include a subsequent offer in the 200 OK responses. The offer wi= ll be received by a 3PCC controller (UAC) and then forwarded as an initial offer = to another User Agent (UA) that is currently not part of a session. When the BUNDLE mechanism is used, as an initial BUNDLE offer look differen= t than a subsequent BUNDLE offer, it cannot be assumed that a UA that expec= ts an initial offer will be able to properly process a subsequent offer. Therefore, the 3PCC co= ntroller needs to act as a Back-To-Back User Agent (B2BUA), and when it rec= eives the subsequent offer it needs to rewrite it into an initial offer before it is forwarded t= o such UA.=94 ---- Regards, Christer From: Roman Shpount > Sent: tiistai 2. marraskuuta 2021 10.41 To: Justin Uberti > Cc: Christer Holmberg >; Justin Uberti >; RTCWeb IETF > Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc88= 29bis-01.txt On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti > wrote: The PROBLEM is that we have two endpoints, where one sends a subsequent off= er, and the other one expects an initial offer. What do you normally do whe= n you have that kind of problem? You use an SBC/B2BUA. In this case that SB= C/B2BUA would be the 3PCC controller. So, my suggestion would be to remove the SHOULD text from 8843bis, and simp= ly add a note somewhere (in 8843bis and/or 8829bis) which describes the iss= ue and says that the 3GPP controller needs to modify the offer accordingly. Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP anyw= ay then maybe adding a=3Dbundle-only isn't the end of the world. I am not opposed to this idea. 3PCC typically knows that the subsequent off= er is going to be used as initial, and should be able to rewrite the offer = to make it valid. We can change SIP Considerations section in 8843bis (http= s://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-sip-c= onsideration), remove the SHOULD, and specify that 3PCC controller should f= ix the offer. We can then reference this note from 8829bis or restate the s= ame guidance. _____________ Roman Shpount _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_HE1PR07MB44416A47EAA75FA00C2D8226938E9HE1PR07MB4441eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi,

If the text is something that everyone can agree on, then = I suggest we go with that. It does not require any changes or assumptions r= egarding the endpoint behaviour.

Regards,

Christer
From: Justin Uberti <jus= tin@uberti.name>
Sent: Friday, November 5, 2021 7:12:02 AM
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Cullen Jennings <fluffy@iii.ca>; RTCWeb IETF <rtcweb@ie= tf.org>; Roman Shpount <roman@telurix.com>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcwe= b-rfc8829bis-01.txt
 
I still feel the cleanest solution would be to allow the = answerer to accept a subsequent offer as an initial offer (since then thing= s will work in 3PCC with no SDP rewriting), and AFAIK no technical reason h= as been put forth to explain why this cannot work.

However, I can live with the alternate solution put forth= by Christer, and the proposed text seems reasonable to me.

Justin

On Thu, Nov 4, 2021 at 9:14 PM Chri= ster Holmberg <christe= r.holmberg@ericsson.com> wrote:

Hi,

 

The question was whether an e= ndpoint would be assumed to be able to accept a subsequent offer (same addr= ess:port in each m- line) as an initial offer. I did not agree to that.<= /u>

 

However, the suggestion a cou= ple of days ago, which people seemed to agree to, does NOT make that assump= tion anymore. Nothing out of the normal would be assumed by endpoints, and = instead the 3GPP controller will act as a B2BUA and modify the SDP if needed.

 

Regards,

 

Christer=

 

From: Cullen Jennings <fluffy@iii.ca>
Sent: perjantai 5. marraskuuta 2021 5.34
To: Christer Holmberg <christer.holmberg@ericsson.com>; Roman Shp= ount <roman@telur= ix.com>; Justin Uberti <justin@uberti.name>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcwe= b-rfc8829bis-01.txt

 

 

Could we have a quick call on this next week durin= g one of the breaks. I have tried to follow this whole thread and some it d= oes not make much sense to me. I=92m a bit lost on what the varios proposed= resolutions are. 

 



On Nov 3, 2021, at 12:38 PM, Christer Holmberg <= ;christer.holmberg=3D40ericsson.com@dmarc.ietf.org> wrot= e:

 

Justin, are you o= k with the suggested text? I would probably be a good idea to refer it in 8= 829bis.

 <= /u>

Regards,

 <= /u>

Christer

From: rtcweb <rtcweb-bounces@ietf.org> on behalf= of Christer Holmberg <christer.holmberg=3D40ericsson.com@dm= arc.ietf.org>
Sent:&= nbsp;Tuesday, November 2, 2021 11:13 PM
To:&nb= sp;Roman Shpount <roman@telurix.com>
Cc:&nb= sp;Justin Uberti <justin@uberti.name>; RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb= -rfc8829bis-01.txt

 

Hi,

 =

>This makes it much better= . I think it is missing a couple of commas ("In some 3PCC scenar= ios," and "In the rewritten offer,") but works for me.

 =

I can add them when I add the= text to the draft, but I think the RFC editor will most likely notice such= thing.

 

>I have changed the sectio= n name so it is clear that it applies to JSEP as well, not just SIP.=

 

Sure, that=92s fine.

 

Regards,=

 

Christer=

 

 =

 =

On Tue, Nov 2, 2021 at 1:24 PM Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,=

 

Eventhough I woul= d not like to make more changes than necessary, I am fine with "3PCC C= onsiderations".

 

However, your sug= gested text is very difficult to understand in some places, so let me give = it a try.

 

(The first paragr= aph is generic, the second SIP specific, and the third BUNDLE specific.)

 

---=

 

3PCC Considerations

 =

In some 3PCC scenarios a new session will be estab= lished between an endpoint that is currently part of an ongoing session and= an endpoint that is currently not part of an ongoing session. The endpoint that is part of a session will generat= e a subsequent offer that will be forwarded to the other endpoint by a 3PCC= controller. The endpoint that is not part of a session will process the of= fer as an initial offer. 

 =

The Session Initiation Protocol (SIP) [RFC3261] al= lows a User Agent Client (UAC) to send a re-INVITE request without an SDP b= ody (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP= offer in the associated 200 OK response. If the UAS is a part of an ongoin= g session, it will include a subsequent offer in the 200 OK response. The o= ffer will be received by a 3PCC controller (UAC) and then forwarded to another User Agent (UA). If the UA = is not part of an ongoing session, it will process the offer as an initial = offer.

When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers, and it cannot be assume= d that a UA is able to correctly process a subsequent offer as an initial o= ffer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid initial offer, following = the procedures in (Section 7.2), before it forwards the offer to a UA. In t= he rewritten offer the 3PCC controller will set the port value to zero (and= include an SDP 'bundle-only' attribute) for each "m=3D" section within the BUNDLE group, excluding the o= fferer-tagged "m=3D" section.

 

 

 

 

 

 

From: Roman Shpount <roman@telurix.com>
Sent:&= nbsp;Tuesday, November 2, 2021 6:33 PM
To:&nb= sp;Christer Holmberg <christer.holmberg@ericsson.com>
Cc:&nb= sp;Justin Uberti <juberti@alphaexplorationco.com>; Justin Uberti = <justin@uberti.n= ame>; RTCWeb IETF <rtcwe= b@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb= -rfc8829bis-01.txt

 =

How about we replace the SIP Considerations with:<= span class=3D"x_m_-3506113441870466143apple-converted-space"> <= u>

 =

3PCC Considerations

 =

In some 3PCC scenarios, an offer generated during = an ongoing session, i.e., a subsequent offer, will be used by a 3PCC contro= ller to establish a new session and forwarded as an initial offer to anothe= r endpoint that is currently not part of a session.

For example, the Session Initiation Protocol (SIP) [RFC3261] allows a User = Agent Client (UAC) to send a re-INVITE request without an SDP body (sometim= es referred to as an empty re-INVITE). In such cases, the User Agent Server= (UAS) will include an SDP offer in the associated 200 OK response. If UAS is a part of an ongoing session,= it will include a subsequent offer in the 200 OK response. The offer will = be received by a 3PCC controller (UAC) and then forwarded to another User A= gent (UA) as an initial offer.

When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers. It cannot be assumed th= at a subsequent offer is a valid initial offer and that the endpoint that e= xpects an initial offer will properly process such a subsequent offer. Therefore, the 3PCC controller SHOULD rew= rite the subsequent offer into a valid initial offer before it is used to e= stablish a new session. To make the subsequent offer a valid initial offer,= 3PCC will need to modify all the non-tagged m=3D lines to include the bundle-only attribute and set the m= =3D line port to zero.

_____________
Roman Shpount

 =

 =

On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

 

What about something like this:=

 =

---

 =

OLD:

 =

=93The Session Initiation Proto= col (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE re= quest without an SDP body (sometimes referred to as an empty re-INVITE).

In such cases, the User Agent S= erver (UAS) will include an SDP Offer in the associated 200 OK response. Th= is is typically used for 3rd Party Call Control (3PCC) scenarios.

From a BUNDLE perspective, such= SDP Offer SHOULD be generated using the procedures defined in Section 7.2.= =94

 =

NEW:

 =

=93The Session Initiation Proto= col (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE re= quest without an SDP body (sometimes referred to as an empty re-INVITE).

In such cases, the User Agent S= erver (UAS) will include an SDP offer in the associated 200 OK response. Th= is is typically used for 3rd Party Call Control (3PCC) scenarios.

 =

In some 3PCC scenarios the UAS = will be part of an ongoing session, and will therefore include a subsequent= offer in the 200 OK responses. The offer will be<= /span>

received by a 3PCC controller (= UAC) and then forwarded as an initial offer to another User Agent (UA) that= is currently not part of a session.

 =

When the BUNDLE mechanism is us= ed, as an initial BUNDLE offer look different than a subsequent BUNDLE offe= r, it cannot be assumed that a UA that expects an initial offer

will be able to properly proces= s a subsequent offer. Therefore, the 3PCC controller needs to act as a Back= -To-Back User Agent (B2BUA), and when it receives the subsequent

offer it needs to rewrite it in= to an initial offer before it is forwarded to such UA.=94=

 =

----

 =

Regards,

 =

Christer

 =

 =

 =

 =

 =

 =

 =

 =

From: = ;Roman Shpount <roman@t= elurix.com> 
Sent:&= nbsp;tiistai 2. marraskuuta 2021 10.41
To:&nb= sp;Justin Uberti <juberti@alphaexplorationco.com>
Cc:&nb= sp;Christer Holmberg <christer.holmberg@ericsson.com>; Justin Ube= rti <justin@uber= ti.name>; RTCWeb IETF <rtcwe= b@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb= -rfc8829bis-01.txt

 

On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti &= lt;jube= rti@alphaexplorationco.com> wrote:

The PROBLEM is that we have two endpoints, whe= re one sends a subsequent offer, and the other one expects an initial offer= . What do you normally do when you have that kind of problem? You use an SBC/B2BUA. In this case that SBC/B2BUA would be the= 3PCC controller.

 

So, my suggestion would be to remove the SHOUL= D text from 8843bis, and simply add a note somewhere (in 8843bis and/or 882= 9bis) which describes the issue and says that the 3GPP controller needs to modify the offer accordingly.

 

Roman, thoughts on this? If the 3PCC is going = to rewrite the offer SDP anyway then maybe adding a=3Dbundle-only isn't the= end of the world.

 

I am not opposed to this idea. 3PCC typic= ally knows that the subsequent offer is going to be used as initial, and sh= ould be able to rewrite the offer to make it valid. We can change SIP Considerations section in 8843bis (https://www.ietf.org/archive/id/draft-ietf-m= music-rfc8843bis-05.html#name-sip-consideration), remove the SHOULD, and specify that 3PCC controller should fix the offer. = We can then reference this note from 8829bis or restate the same guidance.<= u>

_____________
Roman Shpount

 

______________________________________________= _
rtcweb mailing list
rtcweb@ietf= .org
https://www.ietf.org/mailman/listinfo/rtcweb

 

--_000_HE1PR07MB44416A47EAA75FA00C2D8226938E9HE1PR07MB4441eurp_--