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
----------------------------------------------------------------------