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

Wed Mar 26 18:42:13 CET 2014

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 <rfuchs at 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 at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140326/6910dcff/attachment.html>