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