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. We might not need that detail of information when we only query for capabilities, because later when we actually try to reserve codecs we will find out whether the browser support a specific combination or not. But, we need to have a clear and common understanding about what we want when we talk about "query supported codecs" - and other capabilities. To answer Harald's "What capabilities" question: just take a look at a typical SDP message (or the equivalent in Jingle) :) Regards, Christer ________________________________ From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Harald Alvestrand Sent: 13. maaliskuuta 2011 21:23 To: Bernard Aboba Cc: rtc-web@alvestrand.no; jonathan.rosenberg@skype.net Subject: Re: [RTW] Review of draft-holmberg-rtcweb-ucreqs-00 (Web Real-Time Communication Use-cases and Requirements) On 03/13/11 19:44, Bernard Aboba wrote: I agree with this in general. However, I'd suggest that the API needs to provide more information on browser capabilities than just the supported codecs, if the goal is to permit detailed negotiations such as Jingle or SDP offer/answer. What capabilities are you thinking of? The obvious one I think about is that the negotiation/setup needs to contain info about supportable resolutions - on a 240x400 phone screen, I have no reason to ask for 1024x768.