IETF Logo Mail Archive

Re: [MMUSIC] ICE-SDP: Suggested text to clarify that an ICE transport switch does not require a new offer (in order to match the transport of the c/m- line with the transport of the new candidate)

Roman Shpount <roman@telurix.com> Fri, 13 January 2017 19:12 UTC

Return-Path: <roman@telurix.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECB4129D80 for <mmusic@ietfa.amsl.com>; Fri, 13 Jan 2017 11:12:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 kn-Xk7RstKsn for <mmusic@ietfa.amsl.com>; Fri, 13 Jan 2017 11:12:42 -0800 (PST)
Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 7A36F129410 for <mmusic@ietf.org>; Fri, 13 Jan 2017 11:12:42 -0800 (PST)
Received: by mail-qt0-x22a.google.com with SMTP id k15so56199297qtg.3 for <mmusic@ietf.org>; Fri, 13 Jan 2017 11:12:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rTZ1a2GM090zG5fdXd9OTyoUTDlqNfjozY/Ssg56NWo=; b=SLq6RXsKn2Ni8+AULjIdQ0D5Gl2lKBggHzBRVj+l6osUA3IM+zdyXNZCewlxIVHUun qYFTAM0Zri4OsOGfIYXXO1EYKkfC0LJrmqtxQBxh2Tlkpg3IwyhfFjweMgsoQcxxix9p 517nYObMHHIWm85Cs2p4VwX2E6NZCNz9KQYMVkC2bflTViKIe6gTcXvZ3CRM+cwVheDl 3Q6faNIDUSnhumXRx1doQ5VibYAoa654O+pSbR7LVfRmfWess02uf9DxXO11R8SLhlC9 2eUCWp+K8TGDfaCx8Rnsfjrbwp+edZE7z5HfQgo/SLbZX3P8McGUcnS6R+w1jfq2aTQM cRPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rTZ1a2GM090zG5fdXd9OTyoUTDlqNfjozY/Ssg56NWo=; b=WPMGhbgX0rOkUnYInuxzEsaQmkoz/Q7KjqkqCJyRpgU/8ZfcGPlVBpdDQctLw55CxC mWxwlHbUAqishU/YZOZJ6BeC0zdYhyQpS0mCEStU1Sm/QzriLmHJsALTFRHgSYDvCaEA BCPM89l+zSw+lm2QqqaoHI0wtlNybYXMFd8GHSgcCd3XMOuLJpIh1QvuieyEGKnijZT6 dax/P4DQJRZkyaJr4t+16sTkt6oNKsM0TGdABzDHI3Dj9xa/i5poQN2pc8tF10jPwchm rX6NPLaxwDy3lIV1ayrQxSVRZnJLb9W5VUKgNmlrDtmBUv4+HNOZMCLCiv9+v8oVn+vc r4zQ==
X-Gm-Message-State: AIkVDXK28O9lOZYH4hgRb03pWWzMEas8y/YXjyV3nHGYZMr8HNDWu0ib3//Dxj7ktc4Jsg==
X-Received: by 10.200.56.211 with SMTP id g19mr18718342qtc.177.1484334761375; Fri, 13 Jan 2017 11:12:41 -0800 (PST)
Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com. [209.85.216.179]) by smtp.gmail.com with ESMTPSA id h124sm5005533qke.40.2017.01.13.11.12.40 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 11:12:41 -0800 (PST)
Received: by mail-qt0-f179.google.com with SMTP id l7so56419717qtd.1 for <mmusic@ietf.org>; Fri, 13 Jan 2017 11:12:40 -0800 (PST)
X-Received: by 10.237.50.101 with SMTP id y92mr21540747qtd.179.1484334760752; Fri, 13 Jan 2017 11:12:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.147.79 with HTTP; Fri, 13 Jan 2017 11:12:40 -0800 (PST)
In-Reply-To: <D49E8DE5.15A2E%christer.holmberg@ericsson.com>
References: <D49E8DE5.15A2E%christer.holmberg@ericsson.com>
From: Roman Shpount <roman@telurix.com>
Date: Fri, 13 Jan 2017 14:12:40 -0500
X-Gmail-Original-Message-ID: <CAD5OKxu6x=y4gA90i7Jh0=n3fBsCQcEg2hHAKNsoJBe0hSOpNg@mail.gmail.com>
Message-ID: <CAD5OKxu6x=y4gA90i7Jh0=n3fBsCQcEg2hHAKNsoJBe0hSOpNg@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="001a114d7daa2481d50545fe9e6b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/g6w0kd3cEUg_2zBIiO_CuHDiPOI>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE-SDP: Suggested text to clarify that an ICE transport switch does not require a new offer (in order to match the transport of the c/m- line with the transport of the new candidate)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jan 2017 19:12:48 -0000

This looks good to me.

One related question, what happens if another candidate pair is selected
during the time this updated offer is processed? This can cause offer and
answer contain candidates that do not form the pair and use different
transports.

Regards,

_____________
Roman Shpount

On Fri, Jan 13, 2017 at 6:59 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

>
> Hi,
>
> One of the issues that we were going to discuss in Seoul, but didn’t have
> much time for, was whether we should clarify that a ICE transport switch
> (using a previously exchanged and verified ICE candidate pair) does not
> require a new offer, in order to align the m- line with the new transport.
>
> I got an action point in Seoul to suggest text for draft-ice-sep, and
> below is my initial suggestion:
>
> 4.2.  Subsequent Offer/Answer Exchanges
>
>    Either agent MAY generate a subsequent offer at any time allowed by
>    [RFC3264].  The rules in Section 4.1.5 will cause the controlling
>    agent to send an updated offer at the conclusion of ICE processing
>    when ICE has selected different candidate pairs from the default
>    pairs.  This section defines rules for construction of subsequent
>    offers and answers.
>
>    Should a subsequent offer be rejected, ICE processing continues as if
>    the subsequent offer had never been made.
>
>    <new>
>
>    As described in section 4.1.5, when ICE concludes, a subsequent offer might be required in order to match the transport in the c/m- line of a media stream with the transport of the the selected candidates. Once this has been done, if an endpoint later starts to send media using another candidate, the endpoint does not need to send a subsequent offer (even if the transport in the c/m- line does no longer match the transport of the candidate).
>
>    </new>
>
> Regards,
>
> Christer
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

v2.23.0 | Report a Bug | By Email