Re: [rtcweb] Codec control and SDP offer/answer frequency

Harald Alvestrand <harald@alvestrand.no> Thu, 23 August 2012 11:22 UTC

Return-Path: <harald@alvestrand.no>
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 F3C0221F866A for <rtcweb@ietfa.amsl.com>; Thu, 23 Aug 2012 04:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.35
X-Spam-Level:
X-Spam-Status: No, score=-110.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 5ygrEH6w3xmF for <rtcweb@ietfa.amsl.com>; Thu, 23 Aug 2012 04:22:37 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5023F21F863F for <rtcweb@ietf.org>; Thu, 23 Aug 2012 04:22:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CF3B539E03B; Thu, 23 Aug 2012 13:22:34 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPVtL32QQRd8; Thu, 23 Aug 2012 13:22:34 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 034E739E031; Thu, 23 Aug 2012 13:22:33 +0200 (CEST)
Message-ID: <50361279.3040204@alvestrand.no>
Date: Thu, 23 Aug 2012 13:22:33 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EE3@ESESSCMS0356.eemea.ericsson.se>, <5035F12F.9000608@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EF9@ESESSCMS0356.eemea.ericsson.se> <503608A5.6090304@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A73@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A73@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Codec control and SDP offer/answer frequency
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, 23 Aug 2012 11:22:38 -0000

Clipping to a single issue....

On 08/23/2012 01:05 PM, Christer Holmberg wrote:
> Also, you would need to describe how the data channel protocol relates to negotiating being done on the signalling plane.
>> The format of the signalling channel is defined to be outside the scope of the specification, so it's perfectly legitimate to use the data channel for that purpose - application decision!
> Sure, applications can do whatever they want.
>
> But, I think it would be good to have a standardized mechanisms which works for any application. AFAIK, that was the whole purpose of the discussion in Vancouver.
>
Since we've settled on using SDP at the UA/Application interface, 
representing the data in SDP is a valid way of describing that interface 
- thus indeed making it available for use by any application written to 
that interface.

The particular worry you raised was how fast applications can do 
offer/answers - which is dependent on how their signalling channel is 
implemented, and how many intermediate nodes have to process the data.

That's what I'm thinking will be different in the Pokerstars example 
than in a SIP-telephone-gateway example.