IETF Logo Mail Archive

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

"Ram Mohan R (rmohanr)" <rmohanr@cisco.com> Wed, 26 March 2014 01:20 UTC

Return-Path: <rmohanr@cisco.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 C57081A0012 for <rtcweb@ietfa.amsl.com>; Tue, 25 Mar 2014 18:20:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.511
X-Spam-Level:
X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 db8XAne6o_WE for <rtcweb@ietfa.amsl.com>; Tue, 25 Mar 2014 18:20:53 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 5534B1A0028 for <rtcweb@ietf.org>; Tue, 25 Mar 2014 18:20:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3498; q=dns/txt; s=iport; t=1395796852; x=1397006452; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dqAY8n1+iNJtkdDljAksq1apQiMG2NNZjHHy+D8n4tw=; b=hMbtWOjRWTYpB2jXNTpqkOgG+GSf/A7otVNFHKAAqluThavZRRSIa0RP r2ZpLmJb3ZnZl0SgJP975Nlc92ulEnPpqXOXpY36f8I0szrt79ewUsHtp bl9aT9EeA65/KhyoZSwm4JuloBm1Zy+kie3NJ+CAlwkrhsxofKr2WRbuz U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AggFAEwqMlOtJXG//2dsb2JhbABZgwY7V4MLuDqGZFEZgQEWdIIlAQEBBAEBATE6CxACAQgRAwECAQQfCQICHwYLHQgCBA4Fh2UDEQ2RG5wPBpp6DYcdEwSBI4svghwHgmmBTwSWYIFtjGiFSoFwgT6CKw
X-IronPort-AV: E=Sophos;i="4.97,732,1389744000"; d="scan'208";a="30369441"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-6.cisco.com with ESMTP; 26 Mar 2014 01:20:52 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2Q1KpKK013263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Mar 2014 01:20:51 GMT
Received: from xmb-aln-x05.cisco.com ([169.254.11.78]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 20:20:51 -0500
From: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
To: Ted Hardie <ted.ietf@gmail.com>
Thread-Topic: [rtcweb] Consent for fate-sharing connections (Do we need text in draft-ietf-rtcweb-stun-consent-freshness ?)
Thread-Index: AQHPSI8P90WltZATOUOmDZUyqJuWB5rzQiMA
Date: Wed, 26 Mar 2014 01:20:51 +0000
Message-ID: <CF5828FE.85BC2%rmohanr@cisco.com>
References: <CF579BF9.85AEA%rmohanr@cisco.com> <CA+9kkMCgFVWi96iqRsee5V3UMBmY0eK=S0mLnde52tUs3Xnddw@mail.gmail.com> <CF5824EF.85B9A%rmohanr@cisco.com>
In-Reply-To: <CF5824EF.85B9A%rmohanr@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.65.39.91]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <12274E00366C9E4D8276D2E69F52BA13@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fcYJDi0znyK0vkqigDYnZnHg83c
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 01:20:58 -0000

Please see inline


>
>
>From:  Ted Hardie <ted.ietf@gmail.com>
>Date:  Tuesday, 25 March 2014 9:55 pm
>To:  Ram Mohan Ravindranath <rmohanr@cisco.com>
>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 ?)
>
>
>On Tue, Mar 25, 2014 at 8:17 AM, Ram Mohan R (rmohanr)
><rmohanr@cisco.com> wrote:
>
>Hi all,
>
>Certain media streams(For example audio, video) may require multiple
>components (RTP, RTCP) each of which has to work for the media stream as a
>whole to work. If consent fails for one of the component then the
>application(JS) may decide to cease transmission of that media stream.
>
>Is there a need to describe some text (RECOMMENDATION) on how fate-sharing
>connections need to be handled when consent fails for one of the
>components in Consent draft ?
>Or should this be left out of this draft ?
>
>
>
>
>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?

Currently there is no section that talks about this. One of the comments
given by Magnus some time back on this draft asks about scope of consent.
We (the authors of draft-ietf-stun-consent-freshness) were discussing
among ourselves on whether there is a need to have any text for
fate-sharing connections. We don¹t see a real need to have any
recommendation in this draft but wanted to bring this topic to mailer to
see if any one else have any different opinion.

As you said it is completely up to the application what to do if consent
fails. There may be many possibilities- For example for a single media
stream when RTP and RTCP are sent over different addresses (no mux used),
then if consent fails for one of the components, an application may choose
to cease that stream. There may be also cases where consent may fail for
audio but pass for video. Again it is up to the application (JavaScript)
to take a decision on what to do.

Since it is application that always decide, I am ok to just leave it and
not have any text in this document

Ram



>
>Ted
>
>
>
> 
>
>Regards,
>Ram
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
>

v2.23.0 | Report a Bug | By Email