[ortc] determining common capabilities

fippo has just created a new issue for 
https://github.com/openpeer/ortc:

== determining common capabilities ==
Trying to fix my remaining items for h264 interop between 
Chrome/Firefox and Edge I ran into an issue with determining the 
intersection of codec parameters and rtcpFeedback.

Some code lives 
[here](https://github.com/webrtc/adapter/blob/master/src/js/edge/edge_shim.js#L193-L231).
 The ORTC demo on Microsofts TestDrive also has a function 
[filterCodecParams](https://ortcdemo.azurewebsites.net/scripts/ortc-peer.js)
 which does a similar thing.

It would be useful to at least have some high-level about matching 
local and remote capabilities.

After I determine that a codec is common (same name, clockrate and 
number of channels), I need to determine what rtcp feedback and 
parameters can be used. 

rtcp-fb is easy, chrome sends this:
* ccm fir
* nack
* nack pli
* goog-remb
* transport-cc

Since Edge only supports nack pli and goog-remb, only those two should
 be in the answer (I am not sure if there is a distinction between 
'capabilities in the answer' and 'common capabilities').
This is also described in [RFC 
4585](https://tools.ietf.org/html/rfc4585#section-4.2):
```
   When used in conjunction with the offer/answer model [8], the 
offerer
   MAY present a set of these AVPF attributes to its peer.  The 
answerer
   MUST remove all attributes it does not understand as well as those 
it
   does not support in general or does not wish to use in this
   particular media session.
```

The parameters are something where I need advice. When Firefox offers,
 the profile-level-id is
* profile-level-id=42e01f

whereas Edge has this capability
* profile-level-id=42C02A

How do I deal with this? A filter operation as I do for rtcp-fb is not
 right.

Same problem for audio (so its not just a matter of h264 profile 
levels), Chrome sends
    a=fmtp:111 minptime=10; useinbandfec=1
which currently gets passed into Edge's RTPSender.send (without 
issues, I assume it ignores them).

Should I rather put the 'left' (local) parameters into the answer and 
the offerer (browser engine) is responsible for figuring out the right
 thing to do?

This smells a lot like the offer-answer rules from [RFC 
3264](https://tools.ietf.org/html/rfc3264#section-6.1):
```
   The interpretation of fmtp parameters in an offer depends on the
   parameters.  In many cases, those parameters describe specific
   configurations of the media format, and should therefore be 
processed
   as the media format value itself would be.  This means that the 
same
   fmtp parameters with the same values MUST be present in the answer 
if
   the media format they describe is present in the answer.  Other 
fmtp
   parameters are more like parameters, for which it is perfectly
   acceptable for each agent to use different values.  In that case, 
the
   answer MAY contain fmtp parameters, and those MAY have the same
   values as those in the offer, or they MAY be different.  SDP
   extensions that define new parameters SHOULD specify the proper
   interpretation in offer/answer.
```
the tl;dr of this is 'it depends' i guess

Please view or discuss this issue at 
https://github.com/openpeer/ortc/issues/569 using your GitHub account

Received on Wednesday, 22 June 2016 16:34:38 UTC