On 02/18/14 11:12, Mihai Marin wrote:
Hello Sirs, Thank you, one step forward but still buggy - half buggy :)
Now, it's working just one way. If bob calls alice, alice will receive video but bob won't. If I stop mediaproxy-ng process (without any other modification) and redo the call, everything is just fine.
The invite sdp that alice receives is here http://pastebin.com/BgZZbbEA The sdp from OK that bob receive is here http://pastebin.com/ADGt3D3E
I noticed something strange in those 2 SDPs (just audio candidates, video are the same):
- offer
1.a. stun candidates a=candidate:1855365925 1 udp 1845501695 188.215.94.132 63015 typ srflx raddr 192.168.0.5 rport 63015 generation 0 a=candidate:1855365925 2 udp 1845501695 188.215.94.132 63015 typ srflx raddr 192.168.0.5 rport 63015 generation 0 1.b. turn candidates a=candidate:Om0baCmE7kgKNPvv 1 UDP 2130706432 93.187.138.214 30008 typ host a=candidate:Om0baCmE7kgKNPvv 2 UDP 2130706431 93.187.138.214 30009 typ host
- answer
2.a. stun candidates a=candidate:1855365925 1 udp 1845501695 188.215.94.132 63028 typ srflx raddr 192.168.0.5 rport 63028 generation 0 a=candidate:1855365925 2 udp 1845501694 188.215.94.132 63031 typ srflx raddr 192.168.0.5 rport 63031 generation 0 2.b. turn candidates a=candidate:Om0baCmE7kgKNPvv 1 UDP 2130706432 93.187.138.214 30010 typ host
No bundle in sdp but:
- offer has 1 single port for stun candidates and 2 for turn candidates
- answer has 2 ports for stun candidates and 1 for turn candidates
The kamailio log can be accessed at http://pastebin.com/tVgE3BGt
Do you have any idea why this behavior?
Yes, this is caused by MP-NG demultiplexing RTCP. I haven't thought of this before, as in our case we only use MP-NG with the '+' flag, which would eliminate this issue.
What happens is that MP-NG supports rtcp-mux in that it answers to an rtcp-mux offer and handles it correctly, but it never offers rtcp-mux to anyone, unless that endpoint is already talking rtcp-mux.
So from Alice's offer, MP-NG knows that Alice supports rtcp-mux and gladly accepts the offer in the answer sent to Alice. In this case, the same port is used for RTP and RTCP, which implies that only one ICE candidate is given for that port (only in the answer though -- in the offer, two must be given as a fallback).
However, MP-NG doesn't offer rtcp-mux to Bob, which means that Bob's answer includes separate ICE candidates for RTP and RTCP (due to separate ports). As those ICE candidates are left in place by MP-NG when translating the answer (which will include rtcp-mux), there's now a disagreement between the ICE candidates from Bob (two per candidate due to lack of rtcp-mux) and the ICE candidate inserted by MP-NG (only one due to rtcp-mux).
There's two possible solutions without resorting to the '+' flag... Either make MP-NG offer rtcp-mux to Bob initially (who may or may not accept it -- if he doesn't, nothing is fixed), or make it reject the rtcp-mux offer coming from Alice (which violates the WebRTC spec).
Another thing that MP-NG could do is to remove the RTCP ICE candidates in the answer going to Alice, hoping that Bob knows to demultiplex the RTCP packets coming in on the RTP port, despite rtcp-mux not having been negotiated.
I can't say I like any of these options :)
cheers