IETF Logo Mail Archive

Re: [Wish] Proposal: Triggering ICE Restart

Adam Roach <adam@nostrum.com> Fri, 30 July 2021 23:17 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: wish@ietfa.amsl.com
Delivered-To: wish@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9313A15D3 for <wish@ietfa.amsl.com>; Fri, 30 Jul 2021 16:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.08
X-Spam-Level:
X-Spam-Status: No, score=-2.08 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, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6SQKd9pzqTv for <wish@ietfa.amsl.com>; Fri, 30 Jul 2021 16:17:23 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387783A15C7 for <wish@ietf.org>; Fri, 30 Jul 2021 16:17:23 -0700 (PDT)
Received: from Zephyrus.local (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 16UNHHRe036057 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 30 Jul 2021 18:17:18 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1627687039; bh=+KRbuWhrGzLA2Fo1lFsRX+SzDWn696y2udt6sO0CbFY=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=uoX42LyFhkNTS4qcl2NjnDj6yOhko9KLVgGiebOKhJEnS2g+yDY+WRLFWpuo2Eo5J ThBSj174RlmCHIXmnT9I1ibU140eQx3ocWp+LcMQfb2Lig+RjOocMeOK6XMh4bQTST kJSnTg+JEYH75IXIkm9EBuY/03/vq/8j9bouTdk8=
X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be Zephyrus.local
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Cc: WISH List <wish@ietf.org>
References: <bd38b2af-a7a7-e992-ab46-a9fe4f06b305@nostrum.com> <CA+ag07Zy-CGzfWMHQ9kL6j3hS1JhB3P02FJRvMd8Fb7D9HCXKA@mail.gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <1a723b61-ff83-a9e4-c7e9-45950914ba44@nostrum.com>
Date: Fri, 30 Jul 2021 18:17:12 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <CA+ag07Zy-CGzfWMHQ9kL6j3hS1JhB3P02FJRvMd8Fb7D9HCXKA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/wish/107AgargRIhL74cb58r5mwACGwM>
Subject: Re: [Wish] Proposal: Triggering ICE Restart
X-BeenThere: wish@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: WebRTC Ingest Signaling over HTTPS <wish.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wish>, <mailto:wish-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wish/>
List-Post: <mailto:wish@ietf.org>
List-Help: <mailto:wish-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wish>, <mailto:wish-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jul 2021 23:17:29 -0000

On 7/30/21 17:40, Sergio Garcia Murillo wrote:
> I am not sure if I agree with the idea of mapping the operations with 
> jsep. Sure we will make life a bit easier for clients integrating 
> libwebrtc but we may make it much harder to get it implemented in 
> others (like ffmpeg for example).
>
> What i dislike about the idea of generating a new SDP O/A  for ICE 
> restart is that we force the clients/servers to parse the whole sdp 
> for changes that are not just the ice parameters.


Can you expand on this concern? The clients will have code for parsing 
full SDP in order to handle session setup; and the actual parsing 
operation itself is computationally straightforward, so I can't imagine 
it's the parsing itself.

Is the concern that the SDP might change session parameters that the 
server would then need to make adjustments for? If so, we can 
normatively forbid doing so in WHIP (or possibly normatively forbid 
doing so in the absence of explicit indication of server support).

/a

v2.8.7 | Report a Bug | By Email