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

[Christer Holmberg <[e-mail]>]

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

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.


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

Sure - for which offer/answer IS a good mechanism, as I assume the boundaries won't change that often.

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

Correct. But, if you can indicate resolution changes without affecting other procedures, that makes the system more flexible.

If you need to re-NEGOTIATE something, then I agree you very likely will need something like offer/answer.

And, if you are talking about a data channel protocol, my issues may not be valid. So, maybe I'm the only one who missunderstood your message in Vancouver, then :)


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

I belive also CLUE may have usage for this mechanism, eventhough I don't think there is any such formal decission made.

Regards,

Christer