Look at how to support SDEP Cap Neg.. It is required by TS 126.114 section 6.2.1a (LTE SIP/RTP requirements) to use a profile other than RTP/AVP, so we must make sure that our API supports it. The big thing about SDPCapNeg is that you can offer more than one possible configuration at the same time. There are three ways we can support this: 1. Modify the MediaDescriptionOffer to include multiple offers at the same time 2. Have the CM do each offer in order until one is accepted by the client 3. Completely move the negotation inside the CM and make the API more simple by only having the client declare all of its capabilities and then have the CM just tell the client about the chosen offer.
The fallback behaviour is well defined by the rfc (ignore the other offers), so we can implement the fallback behaviour for the undrafted Call spec without any extra effort. I'm marking this as later. To do full cap-neg support, the CM could add an optional interface for cap neg which contains the other possible configurations as lists of MediaDescriptionMaps (possibly with some compression with numbered descriptions like how the RFC does it). If the client supports it, then everything is peachy. Otherwise it gets ignored, and we're also good. I'm assuming here that clients are allowed to ignore MD interfaces they don't understand in MDOffers. We should probably specify that.
Is this considered as a blocker for Call1?
No, that's why the whiteboard says "Call-later"
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/104.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.