26 Mar
2014
26 Mar
'14
11:27 a.m.
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: 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
26 Mar
26 Mar
12:33 p.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
1:42 p.m.
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(a)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:
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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
2:04 p.m.
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
3982
days inactive
3982
days old
3 comments
2 participants
participants (2)
-
Mihai Marin -
Richard Fuchs