[RTW] Review of draft-holmberg-rtcweb-ucreqs-00 (Web Real-Time Communication Use-cases and Requirements)

Christer Holmberg christer.holmberg at ericsson.com
Tue Mar 15 09:32:46 CET 2011


Hi,
 
>>>>>> Even if only talking about codecs, we also need to talk how deep into detail we want to go.
>>>>>>
>>>>>> For example, things like: "codec X can only be used when codec Y is not used" etc.
>>>>> Is there a real life example of this situation, or are you just imagining the possibility?
>>>> H.245. Probably you can do it with SDP CapNeg also...
>>> Not whether you can express it - is there a real life situation on a real life device where you are capable of using two codecs, but not at the same time?
>> I think the following are valid real life situations:
>>
>> - Device restrictions (CPU, DSP etc)
>> - Network restrictions (bandwidth etc)
>> - Number of streams
>I think it's possible to construct devices for which this can be a problem, yes.
>That's not what I was asking.
>To be even more specific:
>
>Do you know of ONE device, presently existing in the Real World (that is, outside of labs) that supports TWO specific, different codecs, and is able to use either of them, but is not able to use them at the same time?
>
>If the name needs to be witheld, that's fine, but I would very much like to see if this is a requirement that comes out of experience, or if it is a problem we just imagine could happen.
>
>Network, bandwidth, processing power and so on restrictions are usually a problem even if the same codec is used for all streams, so that is something we have to deal with. 

Yes. It's not only about codecs, but how many streams etc the browser is able to handle.

>I'm specifically trying to figure out if we have a requirement driven by a real life scenario for "you can choose this codec, or you can choose that codec, but you can't choose both".

Unfortunately I don't have such information. Maybe the people that have been working on H.245, and/or the different cap neg extensions, know more?

But, note that the codecs don't need to be for the same media type (audio, video). For example, a device might be able to use audio codec X when video is not used, but if video is also used the device is only able to use audio codec Y.

Also, when we talk about video, it's not only about codecs as such, but different modes, different resolutions etc for specific codecs.

Of course, many cases can probably be solved by offering a list of codecs, and then offer a reduced list when it's know which codecs the peers support.

I would assume that these issues will also be discussed in CLUE.

>My reason for drilling down so hard on this is that a requirement to express set difference complicates a negotiation language by a rather large amount compared to just doing set intersection.
>(The problem is most acute when dealing with ACLs, where adding set difference usually makes it impossible for an administrator to figure out what exactly he's specified for any rule set of some complexity, but it's a problem for any 
>such language.)

Again, the point is that we need to have a clear understanding and agreement on what exactly we want to do, in order to try to avoid "what if" situations later on.

Regards,

Christer





More information about the RTC-Web mailing list