<div dir="ltr">Hello Sirs, Sir Richard,<div>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?</div>
<div><br></div><div>What parameters should we pass in order to be able to speak FF to Chrome? Just the magic +?</div><div><br></div><div>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?</div>
<div><br></div><div>I'm sure I miss something here.</div><div><br></div><div>Thank you for all your effort.</div><div><br></div><div>Best regards,</div><div>Mihai M</div><div><br></div></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Wed, Mar 26, 2014 at 6:33 PM, Richard Fuchs <span dir="ltr"><<a href="mailto:rfuchs@sipwise.com" target="_blank">rfuchs@sipwise.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey,<br>
<br>
Your use case (injecting ICE candidates only) won't work with Firefox<br>
right now, as mediaproxy-ng now speaks DTLS-SRTP and so wants to use its<br>
own DTLS certificate when advertising SRTP. Since FF's certificate won't<br>
match MP-NG's certificate, the DTLS handshake can always only ever work<br>
against one of the two.<br>
<br>
What's missing is something like a "passthrough everything" mode, where<br>
MP-NG becomes agnostic to the protocol being used and simply forwards<br>
raw packets. Again, since this is not our focus of development, this<br>
isn't implemented yet. But we're getting there.<br>
<br>
That being said, I don't know if this is the actual reason for the error<br>
you're seeing, but at least for now, there's not much point in trying.<br>
However, Firefox <> Chrome should work nicely if you force the media<br>
streams through MP-NG.<br>
<br>
It should also be noted that there's still problems with WebRTC in<br>
Firefox. For example it doesn't do ICE role switching correctly when<br>
encountering ice-lite, and in your SDP I see that it's sending separate<br>
ICE candidates for RTCP despite rtcp-mux being used, which is incorrect<br>
in an answer.<br>
<br>
Keep an eye on the repo for updates.<br>
<br>
cheers<br>
<div class=""><br>
<br>
On 03/26/14 11:27, Mihai Marin wrote:<br>
> Hellor Sirs, Sir Richard,<br>
> I saw some updates in the last 2 weeks that were working with Firefox -<br>
> I also did some tests as it was working. Now, I tried to get the latest<br>
> version and I'm getting the following error:<br>
><br>
> mediaproxy-ng[2747]: Got valid command from <a href="http://127.0.0.1:35127" target="_blank">127.0.0.1:35127</a><br>
</div>> <<a href="http://127.0.0.1:35127" target="_blank">http://127.0.0.1:35127</a>>: answer - { "sdp":<br>
<div><div class="h5">> "v=0#015#012o=Mozilla-SIPUA-29.0a2 13431 0 IN IP4 0.0.0.0#015#012s=SIP<br>
> Call#015#012t=0<br>
> 0#015#012a=ice-ufrag:8a9a3649#015#012a=ice-pwd:80b3b796ecdd0addb079fc531c7e0afa#015#012a=fingerprint:sha-256<br>
> A3:D7:1F:F6:60:1D:91:27:64:89:2E:09:CE:42:19:DB:7E:5F:02:06:A3:DA:E0:26:0F:F7:30:4C:1E:65:86:2B#015#012m=audio<br>
> 50990 RTP/SAVPF 109 101#015#012c=IN IP4<br>
> 188.215.94.132#015#012a=rtpmap:109<br>
> opus/48000/2#015#012a=ptime:20#015#012a=rtpmap:101<br>
> telephone-event/8000#015#012a=fmtp:101<br>
> 0-15#015#012a=recvonly#015#012a=setup:active#015#012a=candidate:0 1 UDP<br>
> 2128609535 192.168.0.5 50990 typ host#015#012a=candidate:1 1 UDP<br>
> 1692467199 188.215.94.132 50990 typ srflx raddr 192.168.0.5 rport<br>
> 50990#015#012a=candidate:0 2 UDP 2128609534 192.168.0.5 50991 typ<br>
> host#015#012a=candidate:1 2 UDP 1692467198 188.215.94.132 50991 typ<br>
> srflx raddr 192.168.0.5 rport 50991#015#012a=rtcp-mux#015#012m=video<br>
> 50992 RTP/SAVPF 120#015#012c=IN IP4 188.215.94.132#015#012a=rtpmap:120<br>
> VP8/90000#015#012a=sendrecv#015#012a=rtcp-fb:120<br>
> nack#015#012a=rtcp-fb:120 nack pli#015#012a=rtcp-fb:120 ccm<br>
> fir#015#012a=setup:active#015#012a=candidate:0 1 UDP 2128609535<br>
> 192.168.0.5 50992 typ host#015#012a=candidate:1 1 UDP 1692467199<br>
> 188.215.94.132 50992 typ srflx raddr 192.168.0.5 rport<br>
> 50992#015#012a=candidate:0 2 UDP 2128609534 192.168.0.5 50993 typ<br>
> host#015#012a=candidate:1 2 UDP 1692467198 188.215.94.132 50993 typ<br>
> srflx raddr 192.168.0.5 rport 50993#015#012a=rtcp-mux#015#012", "flags":<br>
> [ "force", "trust-address" ], "replace": [ "origin",<br>
> "session-connection" ], "call-id": "ufdo7gas8lt6jpco60b1",<br>
> "received-from": [ "IP4", "188.215.94.132" ], "from-tag": "nj7tuhg5hj",<br>
> "to-tag": "7lpqrsa1eb", "command": "answer" }<br>
><br>
> mediaproxy-ng[2747]: [ufdo7gas8lt6jpco60b1] Returning to SIP proxy:<br>
> d3:sdp1463:v=0#015#012o=Mozilla-SIPUA-29.0a2 13431 0 IN IP4<br>
> 0.0.0.0#015#012s=SIP Call#015#012t=0<br>
> 0#015#012a=ice-ufrag:8a9a3649#015#012a=ice-pwd:80b3b796ecdd0addb079fc531c7e0afa#015#012m=audio<br>
> 30002 RTP/SAVPF 109 101#015#012c=IN IP4<br>
> 93.187.138.212#015#012a=rtpmap:109<br>
> opus/48000/2#015#012a=ptime:20#015#012a=rtpmap:101<br>
> telephone-event/8000#015#012a=fmtp:101 0-15#015#012a=candidate:0 1 UDP<br>
> 2128609535 192.168.0.5 50990 typ host#015#012a=candidate:1 1 UDP<br>
> 1692467199 188.215.94.132 50990 typ srflx raddr 192.168.0.5 rport<br>
> 50990#015#012a=candidate:0 2 UDP 2128609534 192.168.0.5 50991 typ<br>
> host#015#012a=candidate:1 2 UDP 1692467198 188.215.94.132 50991 typ<br>
> srflx raddr 192.168.0.5 rport<br>
> 50991#015#012a=recvonly#015#012a=rtcp:30002#015#012a=rtcp-mux#015#012a=setup:active#015#012a=fingerprint:sha-1<br>
> CA:7D:5B:F1:C8:1A:05:8E:9B:88:0F:36:9B:C4:7A:60:A3:B5:02:A4#015#012a=candidate:kgDINMdmuvprUMd6<br>
> 1 UDP 2130706432 93.187.138.212 30002 typ host#015#012m=video 30006<br>
> RTP/SAVPF 120#015#012c=IN IP4 93.187.138.212#015#012a=rtpmap:120<br>
> VP8/90000#015#012a=rtcp-fb:120 nack#015#012a=rtcp-fb:120 nack<br>
> pli#015#012a=rtcp-fb:120 ccm fir#015#012a=candidate:0 1 UDP 2128609535<br>
> 192.168.0.5 50992 typ host#015#012a=candidate:1 1 UDP 1692467199<br>
> 188.215.94.132 50992 typ srflx raddr 192.168.0.5 rport<br>
> 50992#015#012a=candidate:0 2 UDP 2128609534 192.168.0.5 50993 typ<br>
> host#015#012a=candidate:1 2 UDP 1692467198 188.215.94.132 50993 typ<br>
> srflx raddr 192.168.0.5 rport<br>
> 50993#015#012a=sendrecv#015#012a=rtcp:30006#015#012a=rtcp-mux#015#012a=setup:active#015#012a=fingerprint:sha-1<br>
> CA:7D:5B:F1:C8:1A:05:8E:9B:88:0F:36:9B:C4:7A:60:A3:B5:02:A4#015#012a=candidate:kgDINMdmuvprUMd6<br>
> 1 UDP 2130706432 93.187.138.212 30006 typ host#015#0126:result2:oke<br>
><br>
><br>
> mediaproxy-ng[2747]: [ufdo7gas8lt6jpco60b1 port 30000] Error parsing RTP<br>
> header: invalid header version<br>
> mediaproxy-ng[2747]: [ufdo7gas8lt6jpco60b1 port 30004] Error parsing RTP<br>
> header: invalid header version<br>
> mediaproxy-ng[2747]: [ufdo7gas8lt6jpco60b1 port 30002] Error parsing RTP<br>
> header: invalid header version<br>
> mediaproxy-ng[2747]: [ufdo7gas8lt6jpco60b1 port 30006] Error parsing RTP<br>
> header: invalid header version<br>
><br>
> I was dreaming one week ago when I saw Firefox working with chrome :)?<br>
> Do you know something about this error?<br>
><br>
> Thank you.<br>
><br>
> Best regards,<br>
> Mihai M<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
> <a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
> <a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
><br>
<br>
<br>_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
<br></blockquote></div><br></div>