IETF Logo Mail Archive

Re: [sipcore] [EXTERNAL] Re: 3264 offer a=sendonly in context of session modification

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 17 November 2023 20:55 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E642CC14CF1E for <sipcore@ietfa.amsl.com>; Fri, 17 Nov 2023 12:55:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.008
X-Spam-Level:
X-Spam-Status: No, score=-2.008 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_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDQ9gsQ9t0sI for <sipcore@ietfa.amsl.com>; Fri, 17 Nov 2023 12:55:30 -0800 (PST)
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2067.outbound.protection.outlook.com [40.107.92.67]) (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 E7BA0C14CE52 for <sipcore@ietf.org>; Fri, 17 Nov 2023 12:55:29 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Gfovqh50NnUxFrnsyZTSnpo7DADFlQ9sJDyvI82eLJT81JnaxHEfY4powTdUWSErleMo+x9jrHZ+ayBPf3U9h+9D06UUP0lK8CJgzkzGw3GNY/bKYWDkpbQFoMrOkMPiTrRvXi1W1ihizibeG3R1+6UaJoRwNkyOBpDovXruPws904bOe5PIuSkFuKImANezyUEHc0lgLEEh0w48Tjve8kK2KhOY+HLnD8h7vPWp9Bki6+2eT72iFDJk831HxpC0rWGg8A9cxLLtInFlerQW2+yLF4021HdnfW18hboL1VOqYjObJXOcJimvzU9fIVIVY4jiIUQ2z7xkIvHb1+W4Xg==
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=2LiQ3XZUIZCcz0hrg9S6fcL+RHTIyWkx0h/pJLIHiz4=; b=EBEGjwNHzAwWd/T1ZtMM2gy+L/AuUwTdgVbhNjGfmrXhYfOm9FejH6ftLK6fbcITZKRRIE0H5KnI5jhxJRySst4GsU2HOYuBqBMQrkCeB5JCwa+8VtxuxK9h3OXSPL0Dt03IIqDxsJeWfhkfQIbn0D+vTZ1ZrFPvTC7zX3dZSJhStM1KGjBD+CURM8oOOlmXg7+F4gOHZEnMaVoARklbYtLiyWX0DExXYzWjgduNiGW1v0W9QHab6R6u+lexZpo4CjUUh0SNMEbDWlWRaV3P/DCrAduNKCETXAP35NHVB3/RYJplN5hfcQWjDXFS0x8OCNSR9dzu5taOlfcbmniwtA==
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=none sp=none 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=2LiQ3XZUIZCcz0hrg9S6fcL+RHTIyWkx0h/pJLIHiz4=; b=fml53zqnN0UDR5Zv5I2+JsxWFKQY7qHvHnt/jQ/GcqdtUSK0ncSmt9k2KzL+Opc9+LEVsgkJtBr8yWhKrFcU9r7s5Xt2Dk/+1XKWVgPwUFdR3wBL0hzA/tv+WFpNk8BTdNHcUUE8uluT14+NHADjWus+/iPlockYPGjPir3SGbQ=
Received: from SN7PR04CA0064.namprd04.prod.outlook.com (2603:10b6:806:121::9) by BL1PR12MB5159.namprd12.prod.outlook.com (2603:10b6:208:318::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7002.23; Fri, 17 Nov 2023 20:55:27 +0000
Received: from SN1PEPF0002636D.namprd02.prod.outlook.com (2603:10b6:806:121:cafe::a0) by SN7PR04CA0064.outlook.office365.com (2603:10b6:806:121::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7002.21 via Frontend Transport; Fri, 17 Nov 2023 20:55:27 +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 SN1PEPF0002636D.mail.protection.outlook.com (10.167.241.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7025.12 via Frontend Transport; Fri, 17 Nov 2023 20:55:26 +0000
Received: from [192.168.1.52] (c-73-143-251-114.hsd1.ma.comcast.net [73.143.251.114]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 3AHKtOx9013208 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 17 Nov 2023 15:55:25 -0500
Message-ID: <0836cdda-28e4-4654-8ed9-65eb5de81c7c@alum.mit.edu>
Date: Fri, 17 Nov 2023 15:55:24 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Russ Penar <russp@microsoft.com>, "sipcore@ietf.org" <sipcore@ietf.org>
References: <BY5PR00MB0691A51D3E0FB33D972EBE63B6B7A@BY5PR00MB0691.namprd00.prod.outlook.com> <0518b9fe-9a7b-4a09-a6e1-e300a8f984f6@alum.mit.edu> <BY5PR00MB0691124C9D16E1EFE11D24B2B6B7A@BY5PR00MB0691.namprd00.prod.outlook.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
In-Reply-To: <BY5PR00MB0691124C9D16E1EFE11D24B2B6B7A@BY5PR00MB0691.namprd00.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF0002636D:EE_|BL1PR12MB5159:EE_
X-MS-Office365-Filtering-Correlation-Id: e4107030-4ecf-42fd-f474-08dbe7af86ae
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: bliW9zray/kmlVsI/R/7chqmsXLDEMCZUE1WHvxHLeJuO6U0+pe521J/M3ezaLEmbDCeoRH676sBdW3HciYyZn+2HE/s8SotcLPC5uMb/U5W/0j3N/0wITolCqSrKZ6kpgOiWKYXjWripm6OBlMTZ7R5T76/hNdZ7J4xVrIZPSmBqQWCFIAAseIuc8iihRKQLQz5L5bmkKJnSnziuaqWoWBAH8vgRroz0rsimR9kHd8VqnRDMehBhRP0EuaLF3tZeq6f0UBkU+FEtgg6HtqAAkJzIaq/Ze5wGRMpbhZy2lseAIK0BiR0rclJ77vkGaFPT1ctIaG7vY5ReT88C+uE9c5W5zaKh3QQ8sUELwv+JbORLnzxONObOd+1os71t0Cd/GgrAcHGcRnwn12tgOfJ6/sA8wvh8lMg210Fh38a7l9VulUQsyCDJK5ma9/EXB7y4Jd16Ifx4jBnmdyIRuk2twRmH7IPt3IQRPOeSIzaW4N/A+HJfhDsUUI3hgJ4TQNhP5DpP8UcicGci4/qITTm6x9FeoC8z3TuIazyoG34Bdn3kf/VaMdB+LsIZBk+3sIEtVqtHTNUVfljnFpSeqHw4Sr5fhPayQ9C59c+4hd1E0jdwNIjFl2VtKPyNp73EL78ebTBrminl4L6UJ+CwYvR/kFmOLKxpOHeDkmTPKwcSY5aDEBU7m4NKR9pgLa3JKTyy/upqICa227BDdWNCRriRavbz14qVVs1/M0vAaLDBxfyKZVOMDhTXYCaB/2eNubACfttFbYTFIrJ8j2gwrNKe5m6g1NaZLyt313zoIfFni0=
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:(13230031)(136003)(396003)(376002)(39860400002)(346002)(230922051799003)(451199024)(1800799009)(186009)(82310400011)(64100799003)(40470700004)(46966006)(36840700001)(336012)(70586007)(70206006)(86362001)(316002)(786003)(31696002)(66899024)(75432002)(110136005)(26005)(40460700003)(8936002)(8676002)(2906002)(36860700001)(47076005)(5660300002)(41320700001)(83380400001)(82740400003)(53546011)(7596003)(31686004)(478600001)(356005)(41300700001)(40480700001)(2616005)(956004)(41600400003)(43740500002); DIR:OUT; SFP:1101;
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Nov 2023 20:55:26.4369 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e4107030-4ecf-42fd-f474-08dbe7af86ae
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: SN1PEPF0002636D.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5159
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/aliJ8cPsJCOhWQugxgP6BLNJNJk>
Subject: Re: [sipcore] [EXTERNAL] Re: 3264 offer a=sendonly in context of session modification
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Nov 2023 20:55:31 -0000

On 11/17/23 11:55 AM, Russ Penar wrote:
> Paul,
> 
> Thank you for the reply and follow up.
> 
> Paul Kyzivat wrote:
>>   Are you asking as a recipient of such an offer? If so, why does it 
> matter?
> 
> Yes, as an offer recipient a client's UI indicates remote party call hold.
> Client logic triggers UI update today based on a=inactive update for 
> established session.

Just to be clear, you are saying that "other party" sends an in-dialog 
offer (via either reINVITE or UPDATE) with a=sendonly, and the client 
you are concerned about sends a corresponding answer with a=inactive?

That is a valid response, as would be a=recvonly.

> To progress the client's 3264 interworking support discussion, I must 
> determine the risk of introducing my interpretation of 3264 8.4, " With 
> conditions met, new offer for established session, supporting a=sendonly 
> modification (in addition to inactive) does not break the existing UI 
> experience of remote party call hold indication."

Do you have reason for concern that the a=inactive is wrong in this 
circumstance? IIUC your implementation is *presuming* that the other 
party is requesting to put the call on hold, and deciding that it 
doesn't want to received the media. (Presumed to be music on hold.)

On what basis would you make any determination? Did the media exchanged 
prior to the "hold" cause your user to be surprised to no longer get media?

> *8.4 <https://www.rfc-editor.org/rfc/rfc3264#section-8.4>** Putting a 
> Unicast Media Stream on Hold*   If a party in a call wants to put the 
> other party "on hold", i.e.,    request that it temporarily stops 
> sending one or more unicast media    streams, a party offers the other 
> an updated SDP.    If the stream to be placed on hold was previously a 
> sendrecv media    stream, it is placed on hold by marking it as 
> sendonly.  If the    stream to be placed on hold was previously a 
> recvonly media stream,    it is placed on hold by marking it inactive.

I suggest you read RFC 6337, especially section 5, for an in-depth 
discussion of this topic.

	Happy Reading,
	Paul

v2.23.0 | Report a Bug | By Email