IETF Logo Mail Archive

[AVTCORE] Re: BUNDLE question - relationship to PR-Answer?

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 22 April 2026 15:33 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: avt@mail2.ietf.org
Delivered-To: avt@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id E10C1E0E5D80 for <avt@mail2.ietf.org>; Wed, 22 Apr 2026 08:33:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776872024; bh=4UIe4aQF+JuI5IxcpPSk9+RcKzfaWe7p7AjxBRqUdUM=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=Fr/+Sj58Qz4Ua0VM/sr66YtDtOGvFLjjaRjBhaR/km9bPlRFPMTgm7lIcH8JDIG94 dlaElW2noME4iY4z5I7oN9RgHvGPsYcEwA9fQ4g+urhPhUHHIOIkMN74eqXO8aWsS+ UPseDKdRSmlIxVr0t9RoQfVtOrE8/cxWtPM6Yg9c=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qkm7qIg_jo2v for <avt@mail2.ietf.org>; Wed, 22 Apr 2026 08:33:40 -0700 (PDT)
Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazon11022139.outbound.protection.outlook.com [40.107.200.139]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 9679AE0E5908 for <avt@ietf.org>; Wed, 22 Apr 2026 08:31:22 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ETLHvgUrj81Vx0ZiKv4dYeULpsBKZ5TYc/QcpePtZmNi4NlIHYNMRqlxfRsgavmd3fOChRwqvMBoGtlsfXYWx4IsxJQj//jhqo7MhNEUtxMiLrCpR/rj2uXFDWv3Pn1jbQy1WabKkzg3W+cZibVOfri7QnCKq7Vnqsad5dkU0Po7wRcCxCB4dNIUHIHXACPzpTGtDpXd+K5bfLlg5RH6Bx/qU6S9iqgG6K8bMKBcZl/GqXcEokTAQUChvOttvA8bWEIvpQbidupmc2aCiwtlynOL3dJwgnN9OWpHCDbDtSVQkN6HbYXQEgwx4IcUKynlyn2BDGpZWWw2rU3pVo1FyQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=f602xixbkVoltqZg1BQ9iUvPPgVU4HPNUHOfOTsdoyk=; b=kXMp119rKHryr5+YDwJ36PRrg2gvI5uy/SqX6rUndyUmEjRPmjLCe6IPxXlhyw/maEfCsO4YFv38DS2DLKsaT08Wd4jq+tLlvjp1lkD5xdnBZcZbamdverCiFwChK+S0pdrL/QkdpYHd7V8Q89FuiTG6F+khl4BaGvs4rHZsnPHPn1hV4MyBHtnK9FDBxfGmyy/LKuMq9/RA1IiiGAlmKhU5No5MauRgsBU32kPxEUmQb/GH8o2B7fluujo66XalnuhxyYxYsMre0zy7JonpKFj/rRNVsb1DhVzqWjPLw7S+FMqxzZGP1HivwtDqKb4sH1hIeQS+FD1al3H3vyf4hQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f602xixbkVoltqZg1BQ9iUvPPgVU4HPNUHOfOTsdoyk=; b=gs0JqYvPLULLrHwzTUm4NQd3kDvKIU8i44IbWveF7H2TDHeTFWdecJzmvPDV4CZ8ytgc4TbGQoFq197jpXNvq5Ko0+4rRedrve4/tMIwHhd/NNp9fiahzAa93z7VgVK2eZ1eGP76M9FZuBGRe3Gf+t/Kboxdi5GhfOTJrfmtpQE=
Received: from DS7PR05CA0071.namprd05.prod.outlook.com (2603:10b6:8:57::14) by DS2PR12MB9661.namprd12.prod.outlook.com (2603:10b6:8:27b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9846.20; Wed, 22 Apr 2026 15:31:14 +0000
Received: from DM2PEPF00003FC9.namprd04.prod.outlook.com (2603:10b6:8:57:cafe::7c) by DS7PR05CA0071.outlook.office365.com (2603:10b6:8:57::14) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9846.20 via Frontend Transport; Wed, 22 Apr 2026 15:31:14 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=alum.mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; pr=C
Received: from outgoing-alum.mit.edu (18.7.68.33) by DM2PEPF00003FC9.mail.protection.outlook.com (10.167.23.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9846.18 via Frontend Transport; Wed, 22 Apr 2026 15:31:14 +0000
Received: from [192.168.1.52] (c-76-19-71-248.hsd1.ma.comcast.net [76.19.71.248]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 63MFVCnB019838 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 22 Apr 2026 11:31:13 -0400
Message-ID: <fa7cb734-30d4-4193-9f7e-a9f8c771cd06@alum.mit.edu>
Date: Wed, 22 Apr 2026 11:31:12 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Roman Shpount <roman@telurix.com>
References: <a758d4db-6744-4998-843d-df5dc4638c16@alvestrand.no> <15764ec5-9ba5-4560-adc6-84ffd22f0acc@alum.mit.edu> <A4E3C8DD-1550-42C0-B162-D52B61BF9798@8x8.com> <a9f3b27e-ba10-4889-8b74-d7166ef3f6b3@alum.mit.edu> <CAD5OKxv1tY+Zy_rHu8K4orSMycCT8Wms1axTNV3tfEXakQGdaA@mail.gmail.com> <f33c8378-3b0d-482a-8628-ef3eecac3f66@alum.mit.edu> <CAD5OKxsJ9Kg1xVh+eOL3eyuascH2dyA6M8Gp89mc2tX-pN_aMw@mail.gmail.com>
Content-Language: en-US
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
In-Reply-To: <CAD5OKxsJ9Kg1xVh+eOL3eyuascH2dyA6M8Gp89mc2tX-pN_aMw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM2PEPF00003FC9:EE_|DS2PR12MB9661:EE_
X-MS-Office365-Filtering-Correlation-Id: 10c08040-6790-4d81-88ce-08dea08430ab
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|376014|82310400026|1800799024|41320700013|786006|56012099003|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info: uMcFDdIoB9/nwCXy6RxOEvH8Ludgopd5rPXgr8WrDF6fzMPbmzxc/bdqzmrC1JDqwbdmVRnZ3qYd136CBGjqsF201JW7UunLaRscsBr804blLTrlR6kg3karPSx37tEdeUIK1zxvQ9ZZEH10+xInJ+Lagvalav2z7dbVQEi2lztEwer5eiGhv6JifLSjemeesgDJTWGX5BQ6snF2LEK3rwFDCGPytoiplwsbKjKospn9Cu2MyYQYlWGtfKSXJzxHSfAJ30XazhhncFjki+JcMEEfaBGOOpDTqSpmq8CHpGyBeKvNyiyh5Sjy8eG5NN+rbuRS28/xz9O2zCcpq0pSRnoe9EZRh77ovLxvnCD8UFk2jFkxhgocy8BgOva7hXYTGMHHfPSUrO3SfXrRMJaCFweDgbv+ERlCdPrvS7gIMSRA2MlLEkN0IcOXwlu/VT3gbR/OaGSjzHOYurZ+9NB6Rc7qptY6FElzQyD5gFBzkZ/AXlaBsYB2koUWdSfhwoAFPgxGCI9/pEN2i71KPuRq+BwO7SVnfBVkPDOAbCYXFpz78T6tXZHOyxf75YTA4ffHmLQLfXeQNc1QevcvpwEXBFxN7IkkgnysWUmTi+WrnJegE3dzmneLpMHpOcIcVxMfLaPLu5Wyifg/70lGzAHP7ImtPy7I3A3h6JCt+/KURGb+5JOO+yZYxz3ToP7AD9j6zbsriuFtKVHzRnHW5hcCF/vSNfLN7hiFLAehjTwe1WmjSptvX8m7A88GkkkjgiWZNkP94ytiWZQiySE0u7pyJQ==
X-Forefront-Antispam-Report: CIP:18.7.68.33;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:outgoing-alum.mit.edu;PTR:outgoing-alum.mit.edu;CAT:NONE;SFS:(13230040)(36860700016)(376014)(82310400026)(1800799024)(41320700013)(786006)(56012099003)(18002099003)(22082099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 011cJFuZ3FPsnAspmNbYofkujO/P4VeBMTGq1BWbgAVEdvCvi0B8RQtOtOBq7CCpZn8c93KVIIxld0xTVEI/3Oa3zhA3mSAuJV7VRBEUiuWa7Fj9UU1T5IhvIGNkO4sjW57cg93rGA0VM6FiUgt4Vz0RGdaXzRnwbbWTSN+1vRXDmoj6OG9QAMiUNoak+GgvTqtvv0LiVoSRK9g4SsTgn9q8JEKdbOJj4FdQaUT/EgCI3vnTtL35VHOOA9w9vQ5LDOO/BrW8joHW+WJK5c2ieTFE4cHMMXGwmbmV73pojlRc/WJGo+FNJz6jNDgxifLpDk1LXe1bm/Jcc8VxZVnJIKCRWQutfveu8NJBngNiqFSs/TmtwZwu2eU95GSX4YqohYI2O5bNSmVwuZNqs2roXtwkQnKrmdUWwm3Nf2GW8vUpBxLc4P8pLWEB7PVIJxCS
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Apr 2026 15:31:14.3200 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 10c08040-6790-4d81-88ce-08dea08430ab
X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f;Ip=[18.7.68.33];Helo=[outgoing-alum.mit.edu]
X-MS-Exchange-CrossTenant-AuthSource: DM2PEPF00003FC9.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS2PR12MB9661
Message-ID-Hash: Q3THHCN7ELCBEKPX3ZSEAEHQFPPYE4PN
X-Message-ID-Hash: Q3THHCN7ELCBEKPX3ZSEAEHQFPPYE4PN
X-MailFrom: pkyzivat@alum.mit.edu
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-avt.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Jonathan Lennox <jonathan.lennox@8x8.com>, avt@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [AVTCORE] Re: BUNDLE question - relationship to PR-Answer?
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/AehgQBx0U9XARm7wQKkKaieF7FI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Owner: <mailto:avt-owner@ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Subscribe: <mailto:avt-join@ietf.org>
List-Unsubscribe: <mailto:avt-leave@ietf.org>

Roman,

On 4/22/26 11:03 AM, Roman Shpount wrote:

> There is no SIP dialog or fork concept in WebRTC. Only offer/answer. It 
> is a pure SDP negotiation interface that can be used to implement SIP or 
> other signaling protocols. The concept of PR-Answer came from mapping 
> multiple SIP dialogs to a single offer/answer negotiation session. So, 
> the PR-Answer and Answer were different in the same SIP dialog; this 
> would be an error. If they are not in the same dialog, then it is legal 
> and will need to be mapped to the WebRTC API somehow. The only way this 
> works is that each new PR-Answer or Answer, if it differs from the 
> previous PR-Answer, is treated independently, as if it came from a new 
> dialog, and that previous answers were never received. WebRTC needs to 
> roll back the negotiation state and restart negotiation.

As I recall, the webrtc offer/answer was initially derived from the sip 
offer/answer. I had the impression that one goal was to preserve the 
ability for them to interoperate. But I imagine that might not have 
turned out to be useful in practice. But then you have to ensure your 
specifications cover all the corner cases. In sip that turned out to be 
remarkably complex.

	Good Luck,
	Paul

v2.46.0 | Report a Bug | By Email | System Status