Hi Richard!

Just have tried an outgoing call to Chrome and Opera and it works fine. Thank you for the clarification regarding ICE! Dump files and rtp logs (Firefox, Chrome) I've sent to your email.

My little investigation brings the following :

- browsers (Firefox, Chrome and Opera) don't use "a=ice-lite" in their SDP;

- Chrome and Opera take the role of ICE-CONTROLLING and provide USE-CANDIDATE for the ICE-Lite peer (mediaproxy) for both "offer" and "answer" cases;

- Firefox takes the role of ICE-CONTROLLING and provide USE-CANDIDATE in case of the "offer" while it takes the role of ICE-CONTROLLED during the "answer"; /means no media from WebRTC UA in the latter case/

Some other remarks.

During the call from Fire I saw a lot of "SRTP output wanted, but no crypto suite was negotiated" messages from rtpengine. However DTLS is finally was established. Is that one more issue of Firefox?

Looking in STUN section of the dump files I wonder why Chrome use more than 10 binding request (USE-CANDIDATE) for each candidate while Mozilla does it just once.

regards, Alexey

2014-05-16 14:53 GMT+04:00 Richard Fuchs rfuchs@sipwise.com:

There's nothing wrong with the SDP bodies that I can see. I recall that Firefox had or still has a problem with ICE role switching when ice-lite is offered. It never completes ICE negotiation (never sends an STUN packet with "use candidate") and so never starts DTLS handshake.

You can confirm that by doing a packet capture including the RTP ports and inspecting the STUN packets. Chrome shouldn't have that problem though, perhaps do another test run with it? You can send those capture files to me if you'd like me to have a look.

On 05/16/14 20:30, Alexey Rybalko wrote:

During the call from Fire I saw a lot of "SRTP output wanted, but no crypto suite was negotiated" messages from rtpengine. However DTLS is finally was established. Is that one more issue of Firefox?

Some DTLS-SRTP endpoints seem to be slow with starting or accepting the DTLS handshake. What I've seen in my tests was that some "active" endpoints have a delay of a few seconds before they start the DTLS handshake, while some "passive" endpoints only start accepting the DTLS handshake after they've received the signalling answer (while the RFC requires them to accept DTLS right away after sending the offer).

Both of these cases somewhat eliminate one of the advantages that DTLS-SRTP has over SDES: it still breaks early media. If your RTP side sends media before the SRTP side has finished the DTLS handshake, you will lose packets and see those messages popping up. But I hope that these issues will disappear as the code matures.

Looking in STUN section of the dump files I wonder why Chrome use more than 10 binding request (USE-CANDIDATE) for each candidate while Mozilla does it just once.

I've noticed that too and I have no idea why it does that. Doesn't seem to be causing any problems though.

cheers

Hi, Alex!

I'm not experienced in Kamailio, but that code works well :) Is there any difference between feeding the function with variable (AVP?) or string literal?

best regards, Alexey

2014-05-16 16:09 GMT+04:00 Alex Balashov abalashov@evaristesys.com:

Hello Alexey,

I am uncertain as to whether rtpengine_offer()/answer() support pseudovariable arguments. But if they do, you'll need to wrap them in a string literal:

rtpengine_offer("$var(rtpp_flags)");

If they don't support PV arguments at all, you may be stuck with having to provide a static argument:

rtpengine_offer("trust-address symmetric replace-origin replace-session-connection ICE=force RTP/SAVPF");

-- Alex