Re: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer

Roman Shpount <roman@telurix.com> Fri, 13 January 2017 19:08 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 9C7AC129410 for <mmusic@ietfa.amsl.com>; Fri, 13 Jan 2017 11:08:55 -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 2Ds16gIrNQb0 for <mmusic@ietfa.amsl.com>; Fri, 13 Jan 2017 11:08:52 -0800 (PST)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 BDF6E129C3F for <mmusic@ietf.org>; Fri, 13 Jan 2017 11:08:51 -0800 (PST)
Received: by mail-qt0-x22b.google.com with SMTP id k15so56103800qtg.3 for <mmusic@ietf.org>; Fri, 13 Jan 2017 11:08:51 -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=v2Ye2VFIN3AObU1Vzu3oLUtL7OwAT8u49HSecXfz5/E=; b=QSGg1rwIHwNd+o16Kxc/xCJxGlT2r58wkkEJoc0vEphgJjH3D0bz8zdvg4ml4RBs5G Mf3MtT399ASzoZfzOYJ4Mxz1Ev1FNnGUM3FNcigiCavyJdXY80GPm8sdP+0i6A41Opof X71oIRoDPikL5h3jUuxHESooA1+mB6bLntpXoPNOta5fPKlTTBndlwpkmORYn7EXu40J YQWcLEu60/2hgoFays21hKmHJFLuauOZsg08YRJMzQxTtbKHqPj1eiDT1YQTSCWWVWTJ UQ0721el4sTPR4lEE27IVUEiFXg8aTxUIUzzvhDgOTwGORYQtHast/6o0imxhTX600t5 cvVQ==
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=v2Ye2VFIN3AObU1Vzu3oLUtL7OwAT8u49HSecXfz5/E=; b=MdCm3tuWPS6UhZBVEMQ7R7dtpL7YWtpu4FqdFoSgiawqiREl4t8M3oqlcYaQeEef2I swFAqFdY8s23DZRg/6Pm62Lk+hOa6OTKUiNLyIIWZAGeUJJvzflrqIrh+ip30i1T+iPz q0IL2jAxb9v16wlmkqHjUjQZ1D6McCmcnS9JyHX8ASa58O9ochSt8/Vtli027OMf7RKa PiEsvW+0MsTG6DXM5mNT2gVN3nhUIPgfJPEBwvHrD7dZvrvldXUdNhJc3ziv4Id2QCEZ ZvQM2zkzFYK9NWn5cZHlnxEBSOzGvGOAmSc+Yp0ZEN5EymcXpyrgxzv9R7eiKtyCb1Jt /3dA==
X-Gm-Message-State: AIkVDXImqnLOiroB8SRUEf9F8IP6ecGLGFRJWZ9cIOHvwy9ihgd3WRcSChdZIu1lU3gWUw==
X-Received: by 10.200.34.12 with SMTP id o12mr14461085qto.93.1484334530685; Fri, 13 Jan 2017 11:08:50 -0800 (PST)
Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com. [209.85.220.182]) by smtp.gmail.com with ESMTPSA id 21sm9874992qkh.13.2017.01.13.11.08.50 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 11:08:50 -0800 (PST)
Received: by mail-qk0-f182.google.com with SMTP id u25so63810251qki.2 for <mmusic@ietf.org>; Fri, 13 Jan 2017 11:08:50 -0800 (PST)
X-Received: by 10.55.197.148 with SMTP id k20mr18955371qkl.34.1484334529930; Fri, 13 Jan 2017 11:08:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.147.79 with HTTP; Fri, 13 Jan 2017 11:08:49 -0800 (PST)
In-Reply-To: <D49E8E2E.15A34%christer.holmberg@ericsson.com>
References: <D49E8E2E.15A34%christer.holmberg@ericsson.com>
From: Roman Shpount <roman@telurix.com>
Date: Fri, 13 Jan 2017 14:08:49 -0500
X-Gmail-Original-Message-ID: <CAD5OKxtyTaxZWVjYhrLO91SAsVPigPiGHwi5Z1sNhXf1fV6j_w@mail.gmail.com>
Message-ID: <CAD5OKxtyTaxZWVjYhrLO91SAsVPigPiGHwi5Z1sNhXf1fV6j_w@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary=001a1149e640627a750545fe9037
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/vre0NbQIcgDGfYKZnfelFq6kTFY>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer
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:08:55 -0000

As I have mentioned before, I think ALT#1 is a better option: If we propose
mandatory to implement UDP based protocol for each transport family, only
use the mandatory to implement protocol for the default candidate, and the
transport mismatch problem will never occur.

As a bit of background, this issue appeared because of TCP/BFCP, which was
assumed to be the default protocol for BFCP with ICE. Since then, I think
we have decided that TCP/BFCP is not going to be used with ICE. For all the
other protocols that I know (UDP/DTLS/SCTP, UDP/TLS/RTP/SAVPF,
UDP/DTLS/BFCP, RTP/AVP, etc) there is a clear preference that UDP based
protocol should be used for backwards compatibility. I also do not see a
use case which will require that only tcp based candidates would be
included in the offer or the answer. Because of this, I think mandatory to
implement transport is a better approach.

This also have additional benefits of:

1. Providing m= and c= line information which will not cause the ICE
mismatch with older implementations
2. Not supplying any on the path signaling devices with bogus address
information required in ALT#2 answer
3. Improves general chances of negotiation succeeding with end points not
supporting ICE by picking the protocol more likely to succeed (chance of
TCP/RTP/AVP succeeding, for instance, are much lower then RTP/AVP).

Regards,

_____________
Roman Shpount

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

> The subject shall be ICE-SDP: Verify decision made…
>
> From: mmusic <mmusic-bounces@ietf.org> on behalf of Christer Holmberg <
> christer.holmberg@ericsson.com>
> Date: Friday 13 January 2017 at 13:32
> To: "mmusic@ietf.org" <mmusic@ietf.org>
> Subject: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding
> non-supported transport in m- line of answer
>
> Hi,
>
> In Seoul we discussed a number of issues related to ICE-SDP. We made some
> decisions, and I got action points to verify one of those on the list.
>
> The associated slides can be found here:
>
> https://www.ietf.org/proceedings/97/slides/slides-
> 97-mmusic-ice-sip-sdp-00.pdf
>
>
> The issue (slides 4-6) was when an answerer receives an offer with a m-
> line transport that it doesn’t support. The current O/A rules say that the
> transport in the answer must match the transport in the offer.
>
> However, if ICE is used, there may be transports (offered using ICE
> candidates) that the answerer DOES support.
>
> Based on the discussions, there was strong consensus to go for Alt#2,
> which was allowing a transport in the m- line of the answer even if the
> answerer doesn’t support it, as ICE candidates will be used to determine
> the transport.
>
> Does anyone object to Alt#2?
>
> Regards,
>
> Christer
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>