Re: [AVTCORE] Mandatory nature of RTCP
Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 10 May 2011 09:02 UTC
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFF8E094F for <avt@ietfa.amsl.com>; Tue, 10 May 2011 02:02:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.556
X-Spam-Level:
X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvllrdzYhlkZ for <avt@ietfa.amsl.com>; Tue, 10 May 2011 02:02:01 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2AED4E0960 for <avt@ietf.org>; Tue, 10 May 2011 02:02:00 -0700 (PDT)
X-AuditID: c1b4fb39-b7cc5ae000006f6d-1f-4dc8ff07f359
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EB.3B.28525.70FF8CD4; Tue, 10 May 2011 11:01:59 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 10 May 2011 11:01:56 +0200
Message-ID: <4DC8FF04.3090408@ericsson.com>
Date: Tue, 10 May 2011 11:01:56 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
References: <A444A0F8084434499206E78C106220CA089BB30490@MCHP058A.global-ad.net> <5F7BCCF5541B7444830A2288ABBEBC9620B9D67862@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <4DC7DE29.80602@ericsson.com> <4DC7E8E5.7080609@cisco.com>
In-Reply-To: <4DC7E8E5.7080609@cisco.com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "avt@ietf.org" <avt@ietf.org>, "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>
Subject: Re: [AVTCORE] Mandatory nature of RTCP
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 May 2011 09:02:03 -0000
On 2011-05-09 15:15, Paul Kyzivat wrote: > Magnus, > > IMO the first question in this area that comes up for siprec is: > > 1) must we be able to record the RTP of a call when that RTP > doesn't have RTCP? > > I think the answer is clearly yes. > There seems to be enough wiggle room in 3550 that we can't > argue that the call is invalid and we don't need to record it. > (And in general we should try to record calls even if they > *are* invalid.) Agree that you will need to be able to record it. > > The next question that comes up is: > > 2) when recording a call with a media stream that doesn't have > RTCP, must the siprec SRC synthesize RTCP in order that it will be > available to the receiver? Or can we leave it to the siprec SRS > to deal with it? Looking at the architecture pictures in Section 3.1 in http://tools.ietf.org/html/draft-ietf-siprec-architecture-02 I get the impression that the RTP session between the SRC and the SRS appears to be a separate RTP session from the one that is being recorded. In those case I think it is important that the SRC monitors the media flow to the SRS to ensure that it is being delivered successfully and with sufficient quality without causing any persistent congestion. Thus I think a requirement on using RTCP between the SRC and SRS appears necessary. In that context you will have to answer the question what to do if the SRC sees persistent congestion on the path to the SRS. Can it do some media manipulation to reduce bit-rate, for example by repacketizing audion into multiple frames per packet to reduce packet overhead. At the minimal it may have to stop sending the recording stream if there are insufficient resources. > > I think we need AVTxxx input into siprec on such issues. > Decisions on these things can potentially have significant architectural > impact on the way recording is done. > We should do our best to provide feedback on such questions. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- [AVTCORE] Mandatory nature of RTCP Elwell, John
- Re: [AVTCORE] Mandatory nature of RTCP Schwarz, Albrecht (Albrecht)
- Re: [AVTCORE] Mandatory nature of RTCP Magnus Westerlund
- Re: [AVTCORE] Mandatory nature of RTCP Schwarz, Albrecht (Albrecht)
- Re: [AVTCORE] Mandatory nature of RTCP Paul Kyzivat
- Re: [AVTCORE] Mandatory nature of RTCP Elwell, John
- Re: [AVTCORE] Mandatory nature of RTCP Magnus Westerlund
- Re: [AVTCORE] Mandatory nature of RTCP Paul Kyzivat