[SR-Users] mediaproxy-ng, invalid header version

[Richard Fuchs]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140326/d42bff1d/attachment.pgp>