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