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

Harald Alvestrand <harald@alvestrand.no> Thu, 23 August 2012 09:00 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 56ADF21F85FC for <rtcweb@ietfa.amsl.com>; Thu, 23 Aug 2012 02:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.329
X-Spam-Level:
X-Spam-Status: No, score=-110.329 tagged_above=-999 required=5 tests=[AWL=0.271, 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 dhb8pNTTLhoG for <rtcweb@ietfa.amsl.com>; Thu, 23 Aug 2012 02:00:42 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7C821F85F7 for <rtcweb@ietf.org>; Thu, 23 Aug 2012 02:00:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 46C4539E0CE for <rtcweb@ietf.org>; Thu, 23 Aug 2012 11:00: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 ho1EDv58-8gc for <rtcweb@ietf.org>; Thu, 23 Aug 2012 11:00:33 +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 158CA39E031 for <rtcweb@ietf.org>; Thu, 23 Aug 2012 11:00:33 +0200 (CEST)
Message-ID: <5035F12F.9000608@alvestrand.no>
Date: Thu, 23 Aug 2012 11:00:31 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EE3@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EE3@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 09:00:43 -0000

On 08/22/2012 10:47 PM, Christer Holmberg wrote:
> Hi,
>
> In Vancouver two proposals for codec were presented, one based on COP and one based on the SDP imageattr attribute. The result from the straw poll was that people preferred to move forward with the SDP based solution.
>
> When Harald presented his poker game example, he mentioned that there could be changes with a few seconds interval.
>
> For my clarification, does that mean that a UA would send SDP offer/answers every few second???
>
> If so, I don't think that would create good results.
I don't quite buy the analysis - details below.

The example given (the "poker game") would almost certainly be a very 
specialized application, with no requirements for interworking (you 
can't dial into a game from a videophone), and would most likely be 
implemented via a central server (if nothing else, to take care that 
nobody's cheating).

For this type of application, where the end systems are already doing 
data exchange that is not representable in SDP (the game itself), I 
think a sensible architecture would be to pass the SDP offer/answer over 
the data channel. This means that traffic latency for passing SDP is on 
the same order as for media.
>
> First, it would cause heavy load on every entity that has to parse the SDP, as they need to parse the whole message body, and then figure out what has changed.
Given that in such a specialized application, the only entity that has 
to parse SDP is the central node - how much CPU time do you think SDP 
parsing will take? (number of CPU-milliseconds?)
>
> Second, due to race conditions rules, SIP transaction rules etc, and *other* usages of SDP offer/answer within the session, there is a high risk that SDP offers (not only those related to codec control) would be rejected.
Why, given that it's a point-to-point exchange? Admitted, glare will 
happen, and will have to be resolved in the usual ways (ROAP gave one 
mechanism that the game protocol can adopt).
> Offer/answer is a rather "heavy" mechanism, and I don't think it's intended to be used in the suggested way.
Well.. the Arpanet was originally intended for connecting teletypes to 
mainframes. It's proved to be useful in a few scenarios it was not 
originally created for.
> Normally you would send one (or a few) offer/answer(s) during call establishment, and between zero and a few during the session.
>
> Or, did I missunderstand something?
A specialized poker game is not intended to be interoperable with a 
videophone?
>
> Regards,
>
> Christer
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb