-
Notifications
You must be signed in to change notification settings - Fork 368
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DTLS-SRTP negotiation #44
Comments
We are having the exact same problem, but only on outgoing calls from a websocket. RTPEngine latest with OpenSSL 1.0.1j |
Here is the same. Posting log where no audio was heard for 18 seconds past 200 OK 2014-11-17 10:08:00.884873500 INFO: Generating new DTLS certificate |
After tcpdumping on rtpengine there are two bad news:
Combination of 1&2 amounts to the total delay. To remedy 1, I will try to set m/c line with TURN candidates in reINVITE not relying on rtpengine being able to handle dtls for 'bundled' streams. |
In all cases I've seen so far, this is caused by the clients (browsers) not responding to the DTLS hello packets right away as they should, but rather ignoring them for several seconds. You should be able to see this clearly in Wireshark or the such. I don't think that there's anything rtpengine can do about this, but let me know if you have a suggestion. |
Hi Richard, what about emitting an event when the negotiation is done and the audio is ready to flow? Since we don't have control over what the browser does, we can at least make the user more "comfortable" indicating him when he can start talking. I'm thinking that maybe rtpengine (the service) can notify the commander (rtpengine, the Kamailio module) about what's going on so we can take actions based on the results. Thanks! |
Right now there's no feedback mechanism at all, so this isn't something trivial to implement. Feedback to the controlling service could be a nice feature to have in the future, but requires serious thought to design and implement properly. |
I will try to allocate some time to study the codebase and come up with a solution proposal. I believe this could be a serious issue in production, since the delay can really affect the overall sensation of stability that the service offers. Thank you for your suggestions Richard :) |
what about trying to setup DTLS on regular short intervals instead of exponentially growing interval window? |
OpenSSL handles that part. I don't know of any way to influence this behaviour. |
My guess is that rtpengine taking DTLS-'passive' role may improve the situation. It will leave SSL client role to the browser and in what I have seen with calls going in another direction this works fast. |
can try to verify it by changing a=setup:actpass to a=setup:active in the SDP offer. |
Good point about ICE-lite. Perhaps a solution would be to delay DTLS startup until an ICE "use candidate" packet has been received. Or even better, aim for a full ICE implementation. Even though I'm not certain whether either of these would actually fix the problem, as I'm pretty sure I've seen browsers ignoring the DTLS hello even after they've completed ICE. Also, the RFC suggests that DTLS should be allowed to do its handshake while ICE is still doing connectivity checks. |
Things definitely improved by forcing rtpengine into DTLS passive(server) role. No noticeable delay when browser was on UDP opened network. I will check UDP blocked case scenario later. I did replaced a=setup:actpass in the offer to a=setup:active. |
@szcom Hi Sergey, did you change that by modifying /daemon/sdp.c? I'd be happy to help testing this to speed up the process of getting it into master. |
@Jaykah Hi Jaykah, no i modified SDP before it went to kamailio and then to rtpengine. Looks like it is call.c to patch to prefer 'passive' role when possible:
|
@szcom I have tried changing that, but it did not help. However, changing
to
has made a difference (or so it seems). I am unfamiliar with C, so that was my best guess. |
I see clear improvements for all of my test scenarios where browser being on different type of nets and calling to SIP world.
|
WFM, can we push it to master? |
I'll convert it into an option, as I don't think it's right to unconditionally prefer passive in all cases. Furthermore, a proper fix would be preferable to a workaround like this, such as a full ICE implementation. |
That would do the trick :). Thank you Richard. |
@rfuchs Richard, It prefers passive only when other end signals actpass. And I think the option(really needed?) should be 'on' by default until full ICE implemented or we get this issue repopened. |
The active/passive flags are from rtpengine's POV, so this is correct.
|
@rfuchs Richard how can I make kamailio/rtpproxy-ng to signal DTLS=passive when doing rtpproxy_offer("ie-spc")? |
You're gonna have to switch to the newer |
Sorry, but I did not understand. I am running kamailio+rtpproxy-ng on host A and rtpengine on host B. My understanding that host A should send offer to host B, and this offer must have DTLS=passive. But then rtpproxy-ng does not have a flag that would map to DTLS=passive(according to this http://kamailio.org/docs/modules/4.2.x/modules/rtpproxy-ng.html) I can update rtpengine from master but I am puzzled how to generate DTLS=passive on host A and send it over to host B. |
Newer Kamailio has obsoleted http://kamailio.org/docs/modules/4.3.x/modules/rtpengine.html#rtpengine.f.rtpengine_offer |
I've added a command line switch |
Thank you! |
Both FF and Chrome were updated between yesterday and today, and with DTLS passive negotiation sometimes I get no audio in my WEBRTC calls browser to browser. Switching back to the previous configuration seems to fix the problem. |
It happens in all browser to browser calls subjected to the update. It does not happen with browser to softphone. |
Sometimes, maybe the majority of the time, the DTLS-SRTP negotiation can take 5 seconds or even more, and during this time, no audio can be heard on any side.
Is there a way to accelerate the negotiation, or maybe create an event that gets triggered when a SRTP negotiation event happens? This way, we could have a feedback of the audio status and maybe notify the UAs when they are clear to speak, or in case there was an error.
Any ideas how could this be achieved? I can allocate some time to implement it in case this idea is in fact valid.
Thanks!
The text was updated successfully, but these errors were encountered: