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

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