On 03/26/14 13:42, Mihai Marin wrote:
Hello Sirs, Sir Richard,
To be honest I don't understand why DTLS certificate problem is not
reproducing when overriding ICE candidates (forcing media streams though
MP-NG). In my mind it's should be something similar but without removing
already present ICE candidates (without a "+" parameter - to rtproxy-ng
- I see the same thing but decision (if using mp-ng) moved to client
side). What is the difference between forcing to go through mp-ng (using
+ - removing all previous ICE candidates) and not forcing mp-ng (without
+, leaving ICE candidates, adding himself) and let client decide if
using mp-ng or not?
Because the client expects to see a particular DTLS certificate during
the handshake (matching the fingerprint). Firefox has one cert, MP has
another cert. They have different fingerprints. The client will abort
the call if the DTLS fingerprint doesn't match what it expects.
What parameters should we pass in order to be able to
speak FF to
Chrome? Just the magic +?
Yes, it should work with that, keeping in mind the current limitations
FF has (the ice-lite bug prevents it from establishing a call when FF is
the callee I think... or the other way around, I don't remember exactly).
You remember from my previous e-mails what is in my
mind (I hope a good
thinking:)): when we need profile conversion or any change on the rtp
packets (ex: Jitsi-WS) we remove all previous ICE candidates (server
decision) but when speaking WS-WS and we don't need any change on the
rtp packets we let client decide if using mp-ng or not. Speaking
ws-firefox with ws-chrome do we need to modify rtp packets?
No you don't (assuming they're able to negotiate DTLS over SDES, which
they should). But as I mentioned, this mode of operation isn't supported
yet. Right now, MP always tries to play the role of a DTLS endpoint when
DTLS is in use.
cheers