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

[Harald Alvestrand <[e-mail]>]

On 08/23/2012 11:38 AM, Christer Holmberg wrote:
> 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.
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!
>
>>> 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"?
See draft-lennox - there may be negotiation going on, if we change the 
boundaries.
I see the normal use of this feature to be a change in q values only.
>
>
>>> 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).
All state changes have to be negotiated in a way that makes sure they 
eventually resolve, no matter what they are. This is not a problem 
specific to resolution negotiation.
>
>>> 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?
> 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.
And I want to be a lot more specific before worrying.
In the interworking case, I see that there can be issues, because 
existing systems have existing procedures - so I accept the theory that 
every-few-seconds offer/answer is a problem there.

In the WebRTC application case, I want to see a specific problem before 
I start worrying.

>
> Regards,
>
> Christer