Re: [rtcweb] SAVPF history (Re: Final plea about SRTP)

Magnus Westerlund <> Tue, 08 May 2012 13:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 09B6721F84AA for <>; Tue, 8 May 2012 06:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.138
X-Spam-Status: No, score=-106.138 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kPisH0nkopDd for <>; Tue, 8 May 2012 06:49:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2462021F8499 for <>; Tue, 8 May 2012 06:49:32 -0700 (PDT)
X-AuditID: c1b4fb30-b7c78ae000006de5-5d-4fa9246bb7dc
Authentication-Results: x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA)
Received: from (Unknown_Domain []) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by (Symantec Mail Security) with SMTP id 79.01.28133.B6429AF4; Tue, 8 May 2012 15:49:32 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Tue, 8 May 2012 15:49:31 +0200
Message-ID: <>
Date: Tue, 08 May 2012 15:49:30 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Roman Shpount <>
References: <> <> <> <BLU169-DS251D322307BC173FD221AE932F0@phx.gbl> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>
Subject: Re: [rtcweb] SAVPF history (Re: Final plea about SRTP)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 May 2012 13:49:34 -0000

On 2012-05-08 15:34, Roman Shpount wrote:

> I would say that something that changes to rfc4585 would be more
> relevant. Regardless of the actual changes in the draft, my point is
> there are very few actual SIP devices that implement SAVPF or AVPF.
> Specifying this as the only profile supported by WebRTC will create yet
> another challenge to legacy interop, since it will require not only
> processing of ICE messages, and DTLS-SRTP re-encoding, but also RTCP
> re-generation.


Here I have to protest that it increases the barrier. First of all the S
in SAVPF is for using SRTP. That is already agreed on in this WG.
Secondly the F stands for the feedback part. That consists of two parts:

1) New Timer Rules

2) Feedback RTCP packets

The second is actually negotiated on a per individual feedback format
basis. So only the first is what really what would be mandated by a
WebRTC requirement of SAVPF. From my perspective to get the RTP/RTCP
functionalities needed to give a good user experience we really need the
timing rules. When it comes to legacy interop a signalling gateway can
actually produce a SAVPF configuration that is fully interopable with an
SAVP end-point.

The configuration required to make this interoperable are: use a=rtcp-fb
to sett trr-int to 3.5 to 4 seconds and ensure that the same or at least
sufficient RTCP bandwidth is configured and that no feedback format are
agreed on being used.

So please don't be afraid of SAVPF.


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: