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

Christer Holmberg <> Thu, 23 August 2012 09:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5517121F853E for <>; Thu, 23 Aug 2012 02:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.17
X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f+sfWvSPVIEl for <>; Thu, 23 Aug 2012 02:38:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4A52621F854D for <>; Thu, 23 Aug 2012 02:38:25 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-21-5035fa1088c8
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id D7.E4.17130.01AF5305; Thu, 23 Aug 2012 11:38:25 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Thu, 23 Aug 2012 11:38:24 +0200
From: Christer Holmberg <>
To: Harald Alvestrand <>, "" <>
Date: Thu, 23 Aug 2012 11:38:23 +0200
Thread-Topic: [rtcweb] Codec control and SDP offer/answer frequency
Thread-Index: Ac2BDck8/H1UFR4HT1KzzKN0xkPZdgAAvwf1
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvra7gL9MAgz/v2C2O9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGX0rJcoOClTMfPVcpYGxudiXYycHBICJhIL 9u9ggbDFJC7cW8/WxcjFISRwilFiSu95RghnDqPEy32fmboYOTjYBCwkuv9pgzSICARL9D5/ zwhiswioSvx+/hNskLCAk8Sy5/3MEDXOEvfObmUEaRURMJK42ZUEEuYVCJfomDuZCcQWEqiQ +P/5CRuIzSmgK/GnqwmslRHonu+n1oDVMAuIS9x6Mp8J4k4BiSV7zjND2KISLx//Y4WoF5W4 076eEaJeR2LB7k9sELa2xLKFr5kh9gpKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxiFcxMz c9LLzfVSizKTi4vz8/SKUzcxAuPj4JbfBjsYN90XO8QozcGiJM6rp7rfX0ggPbEkNTs1tSC1 KL6oNCe1+BAjEwenVAOj99E/jx5/ZkhsjQlU3PExMVZDsMVGVM/j/WmRZEfJ6e16J11Dr9Zz vH1XGBspVRDiuvoO44JThQ3Sl5xlHgntllHa3dR14/ndjnmiXIt00k5875n9dM/0gJWPds4M +dOuelFT4IpnQ89hw11bVxv3if4xsul7wBk9xbKM7bfUdbPSL4H2mxYosRRnJBpqMRcVJwIA bpYVUF0CAAA=
Subject: Re: [rtcweb] Codec control and SDP offer/answer frequency
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: Thu, 23 Aug 2012 09:38:27 -0000

Hi Harald,

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

Offer/answer over the data channel???

Slide 3 of your presentation talks about the signalling channel.

Now, if you want to define a datachannel protocol that uses SDP syntax, fine, but please don't call it offer/answer :)

Also, you would need to describe how the data channel protocol relates to negotiating being done on the signalling plane.

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

I don't have numbers, but I can tell you that it is a relatively heavy process. And, it's not only about the parsing, but also about the processing of the parsed result.

In addition, are you actually negotiating anything, or are you simply "indicating"?

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

Sure, there are procedures how to handle it. My point is that it may cause bad user experience - espeically if more critical offers are rejected (e.g. offers where you are adding new streams, doing un-hold etc).

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

Let's not get stucked on the poker game use-case then.

In general, if we think there will be use-cases which would trigger frequent offer/answers, I think it's the wrong approach.