IETF Logo Mail Archive

Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED)

Bo Burman <bo.burman@ericsson.com> Thu, 02 May 2013 08:18 UTC

Return-Path: <bo.burman@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4024521F9943 for <rtcweb@ietfa.amsl.com>; Thu, 2 May 2013 01:18:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGowXViUSgr2 for <rtcweb@ietfa.amsl.com>; Thu, 2 May 2013 01:18:33 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 40ABC21F9938 for <rtcweb@ietf.org>; Thu, 2 May 2013 01:18:32 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f536d000006e05-22-5182215764df
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8C.AA.28165.75122815; Thu, 2 May 2013 10:18:31 +0200 (CEST)
Received: from ESESSMB105.ericsson.se ([169.254.5.138]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Thu, 2 May 2013 10:18:30 +0200
From: Bo Burman <bo.burman@ericsson.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED)
Thread-Index: AQHORmGTaplvTvopXk+1qJQquLiHHZjwgkgAgAAMPwCAAPyd8A==
Date: Thu, 02 May 2013 08:18:29 +0000
Message-ID: <BBE9739C2C302046BD34B42713A1E2A22DE83CAC@ESESSMB105.ericsson.se>
References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <AE1A6B5FD507DC4FB3C5166F3A05A48416281FDB@tk5ex14mbxc272.redmond.corp.microsoft.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <CAErhfrx6xi7rNmc6CZc5iyKiYv+oZbi3sBa5QywB7dUKtms2Aw@mail.gmail.com> <C643F355C8D33C48B983F1C1EA702A450B49EA@ESESSMB301.ericsson.se> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <CALiegfmpZZigigQtaadsXup6VfWgJAF8--TJpbUwSJMmar7fRA@mail.gmail.com> <CAD5OKxv2d2DemnjHQdB8XU8NKfK-Uu913DLPq9JUT4z9kvFfTQ@mail.gmail.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <C5E08FE080ACFD4DAE31E4BDBF944EB1134B0090@xmb-aln-x02.cisco.com> <02d001ce465c$bf00f690$3d02e3b0$@stahl@intertex.se> <8486C8728176924BAF5BDB2F7D7EEDDF49AC5673@ucolhp9b.easf.csd.disa.mil> <51815C78.4010403@jesup.org> <8486C8728176924BAF5BDB2F7D7EEDDF49AC5D19@ucolhp9b.easf.csd.disa.mil>
In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF49AC5D19@ucolhp9b.easf.csd.disa.mil>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.19]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+JvrW64YlOgweMOEYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMevYT5aCduGKub19LA2My/i7GDk5JARMJA7ceMMOYYtJXLi3 nq2LkYtDSOAwo8TvzuVQzmJGif7vdxlBqtgENCTm74CwRQTUJS4/vADUzcEhLJAlsfuWF0Q4 W+L8qc1MELaTxM5ty8AWsAioSPzo/cwMYvMK+Epc/zKDFWL+IQ6JnZM/sYLM4RQIknjzXgqk hlFAVuL+93ssIDazgLjErSfzmSAOFZBYsuc8M4QtKvHy8T9WCFtRov1pAyNEvY7Egt2f2CBs bYllC19D7RWUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGy5yZm5qSXG25iBIb9wS2/dXcw njoncohRmoNFSZw3iasxUEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjxb5ZxUaHl/2NZbS4 PPWAo+m3l5ImoXlMhtPKhbof1e65eI5TiDV38jOHFNsf/1mO7Q4/K9C9268v/bmGZvPvhAe/ 2W2/h0/5qHPhhZKl6uRzot8tA6O27NjNmsLTufSvW1SL65J9U1YZuNy1TxGVaje7t+nLHPfa o46TizaUlOuUKEjo7l6kxFKckWioxVxUnAgA628S+0kCAAA=
Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 02 May 2013 08:18:40 -0000

I agree that delay-limited retransmission can be an appropriate functionality also for media. Definitely for video, but maybe also for audio. I expect that actual loss and delay requirements will depend on how media (WebRTC) is used in the specific application use case, making it hard to set one single delay requirement.

For SRTP traffic, would not RFC 4588 (RTP retransmission) provide a good start, especially since you can set a maximum feasible (re-)transmission delay limit on a per-call and per-media basis in the SDP?

/Bo B

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roy, Radhika R CIV USARMY (US)
> Sent: den 1 maj 2013 21:02
> To: Randell Jesup; rtcweb@ietf.org
> Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED)
> 
> Classification: UNCLASSIFIED
> Caveats: NONE
> 
> Inline [RRR]
> 
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Randell Jesup
> Sent: Wednesday, May 01, 2013 2:19 PM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC
> 4568) and RTCWeb (UNCLASSIFIED)
> 
> On 5/1/2013 4:46 AM, Roy, Radhika R CIV USARMY (US) wrote:
> > I am responding only on a part of this email about retransmissions of
> > audio or video packets.
> >
> > Let us not consider the retransmission of audio or video packets. Let
> > us consider audio or video packets are sent only over UDP. Let MOS/QoS
> > of audio or video are considered in a way that retransmissions do not
> > take
> place.
> >
> > Then the question comes only about "data" traffic retransmissions.
> > Data traffic can tolerate much higher delays than that of audio or
> > video. Data has only QoS (and no MOS).
> 
> It may not have MOS per-se, but unreliable data channels have equivalent issues - think of a first-person realtime game -
> unreliable position/state updates of the user and the world mean that what data is lost (and how much data is delayed
> but received) has a very strong impact on the user's perception of the world.
> 
> [RRR] Yes, we need to have NEW threshold of delays (RTT) for data performance.
> --
> Randell Jesup
> randell-ietf@jesup.org
> 
> 
> 
> 
> Classification: UNCLASSIFIED
> Caveats: NONE

v2.23.0 | Report a Bug | By Email