Re: [rtcweb] Consent for fate-sharing connections (Do we need text in draft-ietf-rtcweb-stun-consent-freshness ?)

Bernard Aboba <bernard.aboba@gmail.com> Wed, 26 March 2014 00:17 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B89A1A021E for <rtcweb@ietfa.amsl.com>; Tue, 25 Mar 2014 17:17:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham
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 6MTIY9cRxV8M for <rtcweb@ietfa.amsl.com>; Tue, 25 Mar 2014 17:17:20 -0700 (PDT)
Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B37B71A0010 for <rtcweb@ietf.org>; Tue, 25 Mar 2014 17:17:20 -0700 (PDT)
Received: by mail-yk0-f173.google.com with SMTP id 10so3312992ykt.4 for <rtcweb@ietf.org>; Tue, 25 Mar 2014 17:17:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KkQXfnz9HMDzlpXuuvFG676hJRrncNT5fFRKx1IC9l0=; b=Laz7j/pILxHZRYc/SYWJrTWdebBfiK3lQATXjOMT4SnFeYfWXHJHXgA7A4IESGGatA IfnRawPnJidw2G0TYc3/Ug41vHRcqfY2TQwuLhLSiC2gDfDm3q+DJn9nt+AIEjFGFfmk 6YOZGuaXq/E3Z7GnmCwr+xBbAtQGedtrfSwIIaSSlSLy2UDFTQV7g+cE0rOTDyqGLDqG jpk8sR4ZSxFfty7HxJwZHEkJLw6Gpg5N5hEwSzuiQIdeWHXSdUIOcjo0B+A1NX9meVBo OaSf7vf+U0XvvsTOIAsI1/tZNOmQj6IiTQVfzBzO1M2jP6djDC4U4lhnbXif8GwzZe/v cVIw==
X-Received: by 10.236.84.107 with SMTP id r71mr6727709yhe.108.1395793039361; Tue, 25 Mar 2014 17:17:19 -0700 (PDT)
Received: from [192.168.1.130] (c-76-108-76-219.hsd1.fl.comcast.net. [76.108.76.219]) by mx.google.com with ESMTPSA id q66sm31189092yhj.44.2014.03.25.17.17.17 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Mar 2014 17:17:17 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-74C2D763-65C8-4204-A27B-6865BB98D951"
Mime-Version: 1.0 (1.0)
From: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: iPad Mail (11D167)
In-Reply-To: <CA+9kkMCgFVWi96iqRsee5V3UMBmY0eK=S0mLnde52tUs3Xnddw@mail.gmail.com>
Date: Tue, 25 Mar 2014 20:17:16 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <04A50A41-B9FC-49AE-8AC4-4DD292C66B45@gmail.com>
References: <CF579BF9.85AEA%rmohanr@cisco.com> <CA+9kkMCgFVWi96iqRsee5V3UMBmY0eK=S0mLnde52tUs3Xnddw@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Ye6ZF4bg-ucDX4VCLJOI0HheEjw
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Consent for fate-sharing connections (Do we need text in draft-ietf-rtcweb-stun-consent-freshness ?)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Mar 2014 00:17:22 -0000

Where RTP and RTCP are multiplexed on the same port, they also share the same fate with respect to ICE consent; similarly, when audio/video/data channel are multiplexed, they also share consent fate. Where audio and video use different ports, the fates will not be shared, and it is possible that consent might be given to one and not the other, but it is probably best left up to the application to decide how to react. The one case which might be deserving of a recommendation is where RTP and RTCP aren't multiplexed and consent is given to one of RTP/RTCP but not the other.


> So, it's my understanding that the application may always decide to cease transmission of a media stream even  when it has consent to continue, so I'm not sure what language you are looking for here.  Can you be a bit more direct on which section would need this recommendation and what it might say?
> 
> Ted