| Summary: | ASTERISK-22961: [patch] DTLS-SRTP not working with SHA-256 | ||||||
| Reporter: | Jay Jideliov (jideliov) | Labels: | |||||
| Date Opened: | 2013-12-10 16:39:08.000-0600 | Date Closed: | 2014-06-30 14:51:44 | ||||
| Priority: | Major | Regression? | |||||
| Status: | Closed/Complete | Components: | Channels/chan_sip/SRTP Channels/chan_sip/WebSocket | ||||
| Versions: | 11.6.0 11.7.0 11.9.0 12.0.0-beta2 | Frequency of Occurrence | |||||
| Related Issues: |
| ||||||
| Environment: | Attachments: | ( 0) 11.7_patched.zip ( 1) asterisk_dtls.patch ( 2) asterisk-11.10.0-dtls.patch ( 3) asterisk-11.9.0-dtls.diff ( 4) backtrace.txt ( 5) backtrace_1.txt ( 6) chan_sip.c ( 7) dtls_retransmission.patch ( 8) ice_session.c ( 9) jssip_no_ring.txt (10) Patch_11.9.zip (11) res_rtp_asterisk.c (12) res_rtp_asterisk.c (13) srtp_dtls.patch (14) srtp_dtls.patch (15) srtp_dtls.patch (16) wireshark.txt | |||||
| Description: | Recently it became possible to use websocket on asterisk without a proxy previously necessary to make calls from the web browser. Although partial support has been added, full browser cross-operability has not been achieved yet. However, it seems to be a relatively easy task.
Tested on Chrome+SIPML5+Asterisk 11, the connection can be established and works fine. However, due to the fact that Firefox sends SHA-256 packets which are not supported by asterisk, hence the support for this browser is limited by this issue. Step 1: Adding certificates to support DTLS dtlsenable = yes dtlsverify = no dtlscertfile=/etc/asterisk/keys/softphone.pem dtlsprivatekey=/etc/asterisk/keys/key.pem dtlscafile=/etc/asterisk/keys/key.pem Step 2: Making a call [Nov 25 15:05:50] WARNING[5628][C-0000005c]: chan_sip.c:11034 process_sdp_a_dtls: Unsupported fingerprint hash type 'sha-2' received on dialog '38f43a1f-15cd-ad69-c2b3-72c21b9de5fd' | ||||||
| Comments: | By: Rusty Newton (rnewton) 2013-12-10 19:45:25.187-0600 According to the dev list conversation, it looks like Lorenzo may have a patch for this. Do you want to see if he will submit the patch under license onto the issue tracker? http://lists.digium.com/pipermail/asterisk-dev/2013-December/063972.html By: Lorenzo Miniero (lminiero) 2013-12-11 04:22:26.409-0600 I'll prepare a patch shortly and submit it here. At a first glance, the problem here seems to be that the code that parses the fingerprint attribute in chan_sip.c, which assumes sha-1. My patch also checks for "sha-2" (which are the first 5 characters of sha-256) and also generates sha-256 when forging SDP. This meant that in res_rtp_asterisk.c I had to change the hashing algorhitm from SHA-1 to SHA-256, of course. There are other things my patch changed/fixed, but this was the most immediate one, and the others may have been taken care of in the code base in the meanwhile (I worked on Asterisk 11.1.2). By: Lorenzo Miniero (lminiero) 2013-12-11 05:17:37.649-0600 Hi again, I prepared a quick patch (for Asterisk 11.1.2) that should work. I verified it has everything DTLS related from my code, and that it compiles file, but I didn't have time to test it yet, sorry... As you can see, the patch is quite ugly right now, but considering that code works for me now I'll describe what it does so that this may help solving the issue for good: * There's a small hack in PJNATH, specifically in ice_session.c. Firefox at the time (a few months ago) replied with a 401 everytime it got a connectivity check for a session that wasn't ready yet. PJNATH failed immediately when receiving a 401 and everything stopped there. I changed the PJNATH behaviour to NOT fail when getting a 401 and retrying again indefinitely (I should have placed a timeout there, I know :-) ), until everything was set up correctly in Firefox as well. Anyway, this has apparently been fixed in Firefox in the meanwhile, so this may not be needed anymore. * In res_rtp_asterisk.c there are a LOT of hacks. The main one is that I "cloned" the DTLS code related to RTP to have it used for RTCP as well. In fact, Asterisk does not support rtcp-mux, which means RTP and RTCP are on different "channels". This requires a separate DTLS handshake for both of them, something that in Asterisk originally didn't happen, causing the call to fail immediately (no DTLS handshake for RTCP happening). I placed code to do so, but beware that this currently does NOT get SRTCP to actually work: in fact, while there is a correct DTLS handshake for RTCP, the SRTP session for SRTCP cannot be setup, as RTP and RTCP currently share the same crypto context in Asterisk. This separate handshake requires their contexts to be separated, something that would require a deeper change in Asterisk than the hacks I placed now. Anyway, this proved sufficient in getting the call to work, at least. * I then had to make sure the proper sequence of steps was followed, that is 1. ICE complete, 2. DTLS handshake, 3. media. In the Asterisk code I had this was not respected, and so you could see media being sent before, for instance, the DTLS handshake was completed, thus possibly confusing the browser on the other side. To do so I added some flags to the RTP/RTCP sessions, and a callback that is part of the PJNATH API to know when ICE is done. * I changed the hashing mechanism from SHA-1 to SHA-256, which is what both Firefox and Chrome are negotiating right now. I also added a verification callback that does nothing but return a success: this is needed to have the DTLS handshake work when verification is requested, as this forces the peer to send its certificate, which can then be validated by manually checking the fingerprint (all certificates are self signed which means a formal verification would inevitably fail). * Then, I added a LOT of debug on the console that described what the code is doing. I did so in order to understand what was happening, especially when things didn't work for me. This debug is controllable by means of a new cli command called "dtls set debug". * Finally, for what concerns the code in chan_sip.c, it is mostly aimed at fixing a couple of behaviours that were in the way for Firefox. First of all, I made sure SHA-256 could be parsed, and that it was generated when creating SDP (as that's what I did use in res_rtp_asterisk.c). Then, I moved all DTLS initialization *after* the RTCP setup, since as explained DTLS needed to be set up for RTCP as well. Then, I placed some really ugly code to force DTLS with some default parameters everytime a 'fingerprint' attribute was found in SDP: in fact, Asterisk now needs DTLS to be enabled in the configuration, but this then mandates DTLS for ALL calls, which is something I didn't want. So I disabled DTLS in the configuration and only enabled it programmatically when needed (which worked for me since, as I explained in my report at the time, I only received calls and never originated any). I may be forgetting something but I guess that's all. If there's any explaination or clarification you need about my code feel free to ask. Lorenzo By: Rusty Newton (rnewton) 2013-12-11 17:47:00.506-0600 Thanks Lorenzo - Perhaps that will help Jay and others for the moment. I've opened up the issue, now the patch will need to undergo review and testing by other developers, with the aim of this eventually getting into Trunk/Asterisk 13. If you or Jay are willing to go ahead with testing and tweaking this for Trunk then that speeds things along. Thanks again for the contribution! By: Matt Jordan (mjordan) 2013-12-13 12:50:29.785-0600 Just some thoughts on aspects of this patch. In general, I think having it targeted for Asterisk trunk makes a lot of sense, and would be a great addition for Asterisk 13. {quote} There's a small hack in PJNATH, specifically in ice_session.c. Firefox at the time (a few months ago) replied with a 401 everytime it got a connectivity check for a session that wasn't ready yet. PJNATH failed immediately when receiving a 401 and everything stopped there. I changed the PJNATH behaviour to NOT fail when getting a 401 and retrying again indefinitely (I should have placed a timeout there, I know ), until everything was set up correctly in Firefox as well. Anyway, this has apparently been fixed in Firefox in the meanwhile, so this may not be needed anymore. {quote} Since PJSIP (including PJNATH) has been pulled out of Asterisk in 12+, it's obviously preferable not to have to change code in those libraries. If it's not needed, it'd be nice to leave out. Alternatively, we could make a pull request against PJSIP, and see what Teluu thinks - but I'd treat that as something completely separate. {quote} In res_rtp_asterisk.c there are a LOT of hacks. The main one is that I "cloned" the DTLS code related to RTP to have it used for RTCP as well. In fact, Asterisk does not support rtcp-mux, which means RTP and RTCP are on different "channels". This requires a separate DTLS handshake for both of them, something that in Asterisk originally didn't happen, causing the call to fail immediately (no DTLS handshake for RTCP happening). I placed code to do so, but beware that this currently does NOT get SRTCP to actually work: in fact, while there is a correct DTLS handshake for RTCP, the SRTP session for SRTCP cannot be setup, as RTP and RTCP currently share the same crypto context in Asterisk. This separate handshake requires their contexts to be separated, something that would require a deeper change in Asterisk than the hacks I placed now. Anyway, this proved sufficient in getting the call to work, at least. {quote} Yeah... RTCP in res_rtp_asterisk. :-( For a long time I've wanted to restructure the object in there (and did a small amount of that in 12); that's especially true with Olle's RTCP work in pinefrog. Looking at this patch, it's even more true. I think at this point, it makes more sense than ever to break res_rtp_asterisk up into some bite sized chunks. Probably one to deal with RTCP, and another to deal with DTLS. Something to think about. {quote} I then had to make sure the proper sequence of steps was followed, that is 1. ICE complete, 2. DTLS handshake, 3. media. In the Asterisk code I had this was not respected, and so you could see media being sent before, for instance, the DTLS handshake was completed, thus possibly confusing the browser on the other side. To do so I added some flags to the RTP/RTCP sessions, and a callback that is part of the PJNATH API to know when ICE is done. {quote} Arguably, this is a bug. If you could extract this portion out of the SHA-256 work, I think we could treat it as such for Asterisk 11. {quote} I changed the hashing mechanism from SHA-1 to SHA-256, which is what both Firefox and Chrome are negotiating right now. I also added a verification callback that does nothing but return a success: this is needed to have the DTLS handshake work when verification is requested, as this forces the peer to send its certificate, which can then be validated by manually checking the fingerprint (all certificates are self signed which means a formal verification would inevitably fail). Then, I added a LOT of debug on the console that described what the code is doing. I did so in order to understand what was happening, especially when things didn't work for me. This debug is controllable by means of a new cli command called "dtls set debug". {quote} Debug is always good. DTLS is hard to debug when things go wrong. {quote} Finally, for what concerns the code in chan_sip.c, it is mostly aimed at fixing a couple of behaviours that were in the way for Firefox. First of all, I made sure SHA-256 could be parsed, and that it was generated when creating SDP (as that's what I did use in res_rtp_asterisk.c). Then, I moved all DTLS initialization after the RTCP setup, since as explained DTLS needed to be set up for RTCP as well. Then, I placed some really ugly code to force DTLS with some default parameters everytime a 'fingerprint' attribute was found in SDP: in fact, Asterisk now needs DTLS to be enabled in the configuration, but this then mandates DTLS for ALL calls, which is something I didn't want. So I disabled DTLS in the configuration and only enabled it programmatically when needed (which worked for me since, as I explained in my report at the time, I only received calls and never originated any). {quote} Hm. I'm not sure I understand why the second part of this is necessary, i.e., always enabling DTLS. Was it just so that you didn't have to worry about configuring DTLS in sip.conf? By: Jay Jideliov (jideliov) 2013-12-13 15:18:23.685-0600 Tried to manually apply the patch to 11.6.0, adjusting everything line by line. It might be the version (although I doubt it), but I am getting the following errors during the Make operation: [CC] res_rtp_asterisk.c -> res_rtp_asterisk.o res_rtp_asterisk.c: In function dtls_srtp_setup: res_rtp_asterisk.c:1689:5: error: struct ast_rtp has no member named dtlsdone rtp->dtlsdone = 1; ^ res_rtp_asterisk.c: In function rtp_sendto: res_rtp_asterisk.c:1942:21: error: struct ast_rtp has no member named dtlsdone if(rtp->ssl && !rtp->dtlsdone) { ^ res_rtp_asterisk.c: In function ast_rtp_new: res_rtp_asterisk.c:2225:5: error: struct ast_rtp has no member named instance rtp->instance = instance; ^ res_rtp_asterisk.c: In function ast_rtp_activate: res_rtp_asterisk.c:4651:9: error: struct ast_rtp has no member named ice if(!rtp->ice || rtp->icedone) { ^ res_rtp_asterisk.c:4651:21: error: struct ast_rtp has no member named icedone if(!rtp->ice || rtp->icedone) { ^ make[1]: *** [res_rtp_asterisk.o] Error 1 I checked the 11.1.2 - and did not find those variables either. By: Jay Jideliov (jideliov) 2013-12-13 15:22:48.999-0600 After adding the following lines, make worked: struct ast_rtp { char instance; unsigned int dtlsdone; unsigned int ice; unsigned int icedone; By: Lorenzo Miniero (lminiero) 2013-12-13 15:54:38.393-0600 If you look at the patch, those are some of the flags I added with respect to point 3, that is the ICE/DTLS/media sequence. If they didn't appear in your patched res_rtp_asterisk.c my guess is they are part of a hook that failed (considering the dfferent version), so make sure there isn't anything else missing either. By: Lorenzo Miniero (lminiero) 2013-12-13 16:11:17.536-0600 Hi Matt, I'd be really glad to contribute to make DTLS support better for Asterisk, whether for Asterisk 13 or current versions as well. To address your points: * If PJNATH isn't used anymore, then I agree there's definitely no need to patch it. Besides, as I mentioned this was fixed in Firefox in the meanwhile, as it was most probably a fault on their side. In fact, other libraries (e.g., libnice) tend to behave the same way, so PJNATH wasn't doing anything wrong I guess. * Your approach to the separation of RTCP features sounds reasonable, and would definitely help in getting DTLS to work in the non-muxing case. On a related note, is support for rtcp-mux planned in Asterisk instead? Muxing RTP and RTCP would remove the need for two different DTLS handshakes in the first place. * The sequence bits are mostly related to some flags I added (icedone, dtlsdone, etc.), and I also added a callback that is invoked by PJNATH when ICE is done. I then used those flags to make sure media packets wouldn't be sent if DTLS wasn't completed yet, and in turn the DTLS handshake wouldn't be started before ICE was complete as well. This of course if DTLS was enabled: without DTLS, it would be "no media before ICE". The code for that should be easily extractable from the overall patch: I'll try and prepare one earler next week. Should I post it here or somewhere else? * About the "DTLS always enabled", what I noticed is that, when DTLS is enabled in the configuration, it is negotiated by default for all outgoing calls (unless disabled for some specific peers). If I recall correctly (but I may be wrong here, I'll have to check), it also made insecure (RTP/AVP) calls fail because no secure context was provided. Considering I was interested in both type of calls, I used that ugly hack to quickly enable DTLS (using some predefined values and not the config, right) only for incoming calls that negotiated it. It's definitely not the right way to fix the issue, if any, but it worked for me. By: Jay Jideliov (jideliov) 2013-12-13 16:23:45.627-0600 So we have finally installed the patch and turned on dtls. Now, although SHA-256 seems to be working now, testing with SIPML5 we get: WARNING[27765][C-00000007]: chan_sip.c:25315 handle_request_invite: a=fingerprint found, creating DTLS configuration Here's the debug output: <--- SIP read from WS:24.90.195.17:57012 ---> INVITE sip:888@1.1.1.1 SIP/2.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bKeTFcucDeFngTObDDW7LKL1h8cRx2l3RN;rport From: "1060"<sip:1060@1.1.1.1>;tag=H18f7p8mdtQ50lkznEEP To: <sip:888@1.1.1.1> Contact: "1060"<sip:1060@df7jal23ls0d.invalid;rtcweb-breaker=yes;click2call=no;transport=ws>;impi=1060;ha1=afc80e86167f09f8148165f43bcc786a;+g.oma.sip-im;+sip.ice;language="en,fr" Call-ID: 89d77abf-b59a-6344-e55a-3f7585801cc6 CSeq: 1112 INVITE Content-Type: application/sdp Content-Length: 1067 Route: <sip:1.1.1.1:5060;lr;sipml5-outbound;transport=udp> Max-Forwards: 70 Authorization: Digest username="1060",realm="asterisk",nonce="6660fc44",uri="sip:888@1.1.1.1",response="6c4047ba82e30c3ae856832ace89df1a",algorithm=MD5 User-Agent: IM-client/OMA1.0 sipML5-v1.2013.08.10B Organization: Doubango Telecom v=0 o=Mozilla-SIPUA-27.0a2 3702 1 IN IP4 0.0.0.0 s=Doubango Telecom - firefox t=0 0 a=ice-ufrag:7e02141e a=ice-pwd:10bc76edf15551ec91ac2ab2014919a2 a=fingerprint:sha-256 66:26:99:72:9E:21:BF:18:20:D2:9D:CC:A7:C9:A6:98:FE:D9:64:70:72:47:08:CF:CB:82:4F:74:6A:5D:7F:05 m=audio 60857 UDP/TLS/RTP/SAVPF 109 0 8 101 c=IN IP4 24.90.195.17 a=rtpmap:109 opus/48000/2 a=ptime:20 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=setup:actpass a=candidate:0 1 UDP 2128609535 192.168.0.21 60857 typ host a=candidate:1 1 UDP 1692467199 24.90.195.17 60857 typ srflx raddr 192.168.0.21 rport 60857 a=candidate:5 1 UDP 2128543999 192.168.220.1 60858 typ host a=candidate:10 1 UDP 2128478463 192.168.102.1 60859 typ host a=candidate:0 2 UDP 2128609534 192.168.0.21 60860 typ host a=candidate:1 2 UDP 1692467198 24.90.195.17 60860 typ srflx raddr 192.168.0.21 rport 60860 a=candidate:5 2 UDP 2128543998 192.168.220.1 60861 typ host a=candidate:10 2 UDP 2128478462 192.168.102.1 60862 typ host a=rtcp-mux <-------------> --- (14 headers 26 lines) --- Using INVITE request as basis request - 89d77abf-b59a-6344-e55a-3f7585801cc6 Found peer '1060' for '1060' from 24.90.195.17:57012 == Using SIP RTP CoS mark 5 Found RTP audio format 109 Found RTP audio format 0 Found RTP audio format 8 Found RTP audio format 101 Found unknown media description format opus for ID 109 Found audio description format PCMU for ID 0 Found audio description format PCMA for ID 8 Found audio description format telephone-event for ID 101 [Dec 13 17:15:39] WARNING[27572][C-00000006]: chan_sip.c:10468 process_sdp: Rejecting secure audio stream without encryption details: audio 60857 UDP/TLS/RTP/SAVPF 109 0 8 101 By: Jay Jideliov (jideliov) 2013-12-13 16:28:02.515-0600 Attached are the files adjusted for 11.6.0 By: NITESH BANSAL (nbansal) 2013-12-16 08:22:05.000-0600 Hi Matt, You pointed out that there is a bug related to sequence of steps related to DTLS handshake, i did not really understand what bug are you talking about here. If you could provide some more insight, it would be really helpful for me, i am trying to write a patch for Asterisk 11.4. Lorenzo's explanation "I then had to make sure the proper sequence of steps was followed, that is 1. ICE complete, 2. DTLS handshake, 3. media. In the Asterisk code I had this was not respected, and so you could see media being sent before, for instance, the DTLS handshake was completed, thus possibly confusing the browser on the other side. To do so I added some flags to the RTP/RTCP sessions, and a callback that is part of the PJNATH API to know when ICE is done." Your comment on it "Arguably, this is a bug. If you could extract this portion out of the SHA-256 work, I think we could treat it as such for Asterisk 11." Regards, Nitesh Bansal By: Lorenzo Miniero (lminiero) 2013-12-19 09:13:42.831-0600 Jay, the error you're getting is not in my 11.1.2, and in fact I noticed that it is in 11.6.0 chan_sip.c instead. Anyway, the problem is that Asterisk thinks no crypto stuff related to media lines has been negotiated, despite the fact the fingerprint is there. This is caused by an incomplete check the channel does: in particular, for each media line a process_crypto method is called and, if it is successful, it sets a variable (processed_crypto) to TRUE. The problem here is that that process_crypto method only looks for the SDES crypto attributes, ignoring the fingerprint one that is used for DTLS. {noformat}Note to Matt: this is definitely another bug that I think needs to be addressed, since as it is now I really don't think DTLS is supposed to ever work. Is this something you see for Asterisk 13 or for current releases as well?{noformat} Jay, since fixing this would need a bit of code mangling (for which unfortunately I have no time at the moment), an easy way to circumvent this right now just for testing if the rest of the patch works fine is manually setting that variable to true before the check that causes the error (that is, where the "Ensure crypto lines are provided where necessary" comment is). This way Asterisk will go on with the SDP processing and should setup the media, ICE, DTLS and so on. By: NITESH BANSAL (nbansal) 2013-12-19 09:34:45.035-0600 Hi Lorenzo, Could you please clarify on the question i raised to Matt in a comment above. I'll paste my question again: ------ Hi Matt, You pointed out that there is a bug related to sequence of steps related to DTLS handshake, i did not really understand what bug are you talking about here. If you could provide some more insight, it would be really helpful for me, i am trying to write a patch for Asterisk 11.4. Lorenzo's explanation "I then had to make sure the proper sequence of steps was followed, that is 1. ICE complete, 2. DTLS handshake, 3. media. In the Asterisk code I had this was not respected, and so you could see media being sent before, for instance, the DTLS handshake was completed, thus possibly confusing the browser on the other side. To do so I added some flags to the RTP/RTCP sessions, and a callback that is part of the PJNATH API to know when ICE is done." Your comment on it "Arguably, this is a bug. If you could extract this portion out of the SHA-256 work, I think we could treat it as such for Asterisk 11." ---- I would like to know why is it a bug? Regards, Nitesh Bansal By: Lorenzo Miniero (lminiero) 2013-12-19 09:44:30.689-0600 Nitesh, the problem is quite simple. If ICE has not been completed, everything you send (or think you're sending) in the meanwhile gets lost, as there is no "channel" with the peer. This includes, when DTLS is used, handshake packets you send. Should no retransmission be handled, if you loose that first DTLS handshake DTLS is never set up, leaving you hanging. The issue is less problematic when you send RTP before the DTLS handshake has been completed, as browsers already have code in place to understand what they just received (DTLS, RTP or RTCP). Nevertheless, it's still good practice to only send RTP/RTCP when the underlying DTLS stuff has been done, as otherwise you're sending unencrypted stuff around (RTC/RTCP before the SRTP setup) that will be discarded anyway. By: NITESH BANSAL (nbansal) 2014-01-07 07:38:37.402-0600 Hello, I have used Lorenzo's code to make a patch for Asterisk 11.4 and now i can use my Asterisk to accept WebRTC calls from both chrome and firefox. The major differences between my patch and Lorenzo's patch are: 1. It is a bit cleaner (no comments mentioning meetecho and better indentation i hope) 2. I am relying on the config file to enable DTLS, it isn't enabled by default. 3. This patch provides support for both SHA-1 and SHA-256 and can be later extended to include support for SHA-512 also. I would request you to have a look and see if it can be included in Asterisk 11. P.S: There is one hack which i made in my javascript code to make Asterisk happy "I had to replace RTP/SAVPF in SDP with UDP/TLS/RTP/SAVPF". After this hack, i was able to talk to both Chrome and Firefox using DTLS. Regards, Nitesh By: Jay Jideliov (jideliov) 2014-01-07 10:11:39.891-0600 Nitesh, Thank you for the updated patch. Two questions: 1) You have mentioned a JS hack to replace RTP/SAVPF in SDP with UDP/TLS/RTP/SAVPF. Can you please share it here? It will be greatly appreciated since I am also trying to get it to work. 2) Have you tested it with 11.6/11.7? Since 11.4 is quite outdated, I think it would be more beneficial to test it on some of the more recent versions of Asterisk to try to get this patch rolled out in the next release. That being said, me and my team would gladly participate in the testing once the appropriate patch is provided. Thanks. By: Jay Jideliov (jideliov) 2014-01-07 17:21:35.057-0600 I have applied the patch to the 11.7 files. Hopefully this will speed up the process of getting the release done. It was not generated via the SVN (could not access the SVN itself), so I am attaching the files in their respective directories. By: NITESH BANSAL (nbansal) 2014-01-08 04:39:02.852-0600 Hi Jay, I have written the patch only for Asterisk 11.4, i did not get the chance to try it with other Asterisk versions. Regarding the JS hack, well i am using JSSIP library to build my webrtc app. But it should be very straight forward for you to do this. Search for the function createOffer() in your JS code, there is a callback function passed to it for successful completion. You could use that callback function to access the SDP and overwrite it. SDP is accessible in RTCPeerConnection.localDescription.sdp Regards, Nitesh Bansal By: NITESH BANSAL (nbansal) 2014-01-10 09:32:59.291-0600 Hello, I am attaching the revised version of my patch. there was a bug in the old patch, asterisk was not compilable on the machines with an older version of openssl which was not supportig SRTP-DTLS. Nitesh By: Tzafrir Cohen (tzafrir) 2014-01-25 02:23:22.041-0600 This big patch scares me. Can any of you try to break it to smaller patches? By: Daniel Pocock (daniel.pocock) 2014-02-07 04:59:58.129-0600 I've put this patch into a package available through the Debian experimental catalog: http://packages.debian.org/experimental/asterisk The version containing this patch is 1:11.7.0~dfsg-1+e1 and it is built from the branch dtls-srtp-patch in the Debian Git Anybody wanting to build that branch can do git clone git://anonscm.debian.org/pkg-voip/asterisk.git cd asterisk git checkout dtls-srtp-patch dpkg-buildpackage -rfakeroot -i.git -j13 By: Daniel Pocock (daniel.pocock) 2014-02-07 05:01:59.043-0600 My first observation about this is that if encryption=yes, then dtlsenable seems to default to yes as well now To be more specific, if Chrome sends an SDP with both SDES and DTLS-SRTP, Asterisk will only want to do DTLS-SRTP unless I explicitly set "dtlsenable=no" By: Jay Jideliov (jideliov) 2014-02-24 16:50:29.837-0600 Nitesh, Was the JS hack you've implemented a solution to the incoming call issue? What I currently get is a failure to get local SDP on incoming calls (and the call fails). Since we are using DTLS (not SDES), the key exchange as far as I understand is done via a=fingerprint, not a=crypto. So from Chrome to Asterisk it is behaving as expected, but it sends the wrong packets from Asterisk to the receiving side a=fingerprint:sha-256 40:30:A2:FD:C4:C8:CF:44:FB:7F:3C:4A:34:B2:08:25:CC:27:C7:78:16:8B:3D:34:5B:31:A5:28:3A:16:A0:FF I have seen the issue of incoming calls in a number of topics and issues, so am trying to get to the bottom of it at last. Here is what I have in SIPML5: {code:title=SRTP|borderStyle=solid} // HACK: Nightly 20.0a1 uses RTP/SAVPF for DTLS-SRTP which is not correct. More info at https://bugzilla.mozilla.org/show_bug.cgi?id=827932. if(tmedia_session_jsep01.mozThis){ if(o_hdr_M.s_proto == "RTP/SAVPF"){ o_hdr_M.s_proto = "UDP/TLS/RTP/SAVPF"; } } ....................... // HACK: Nightly 20.0a1 uses RTP/SAVPF for DTLS-SRTP which is not correct. More info at https://bugzilla.mozilla.org/show_bug.cgi?id=827932 if(tmedia_session_jsep01.mozThis && o_hdr_M.s_proto.indexOf("UDP/TLS/RTP/SAVP") != -1){ o_hdr_M.s_proto = "RTP/SAVPF"; } } } return 0; } {code} Thanks. By: NITESH BANSAL (nbansal) 2014-02-25 07:42:10.601-0600 Hi Jay, You are right, my JS hack was for calls originating from web browser towards asterisk. Regards, Nitesh Bansal By: Jay Jideliov (jideliov) 2014-02-25 12:19:22.618-0600 Nitesh, 1) Is there a reason why you chose to address this on the JS side vs. by modifying this patch? 2) It would be also very helpful if you could post your modified JSSIP files for testing/analyzing behavior on incoming calls, since that issue was somehow (but not fully) addressed in SIPML as well (without a resolution), so finding how this can be incorporated into Asterisk should now be a priority. 3)Have you experienced any issues when making calls (with DTLS-SRTP) behind NAT? This is another issue I have encountered - although the sound is working fine in a no-NAT setup, there is no sound flowing between the parties when one of them is behind NAT. However, when DTLS-SRTP is not involved, same calls work fine both with and without NAT involved. By: NITESH BANSAL (nbansal) 2014-02-26 03:04:34.494-0600 Hi Jay, Here are the answers to your questions: 1. I fixed it in JS Side, because asterisk is correct in its behaviour. For DTLS-SRTP, media profile should be UDP/TLS/RTP/SAVP(F). 2. I just made 1 line change in JS-SIP,i'll paste the code snippet here: {code} --- jssip-0.3.0.js +++ jssip-0.3.0.js @@ -3313,7 +3313,10 @@ setLocalDescription: function(sessionDescription, onFailure) { this.peerConnection.setLocalDescription( sessionDescription, - null, + function(e) + { + console.log(LOG_PREFIX +"Set the local description"); + }, function(e) { console.error(LOG_PREFIX +'unable to set local description'); console.error(e); @@ -4403,7 +4406,8 @@ if (self.isCanceled || self.status === C.STATUS_TERMINATED) { return; } - + /*Replace RTP/SAVPF by UDP/TLS/RTP/SAVPF to propose DTLS */ + offer = offer.replace(/\s+RTP\/SAVPF\s+/gm, " UDP/TLS/RTP/SAVPF "); self.request.body = offer; self.status = C.STATUS_INVITE_SENT; request_sender.send(); {code} 3. Yes i am also facing one way audio issues with DTLS-SRTP, but the issue isn't because of DTLS-SRTP, it seems that real issue is ICE negotiation. I have made couple of fixes, but there are some more issues. You can refer to the JIRA ASTERISK-23337 By: NITESH BANSAL (nbansal) 2014-03-11 05:36:28.272-0500 Hello everyone, With regards to DTLS support, i noticed that there was no mechanism for DTLS retransmission in Asterisk. So i have written a patch for this, i request you to review this patch and if possible test the DTLS retransmission. By: Matt Jordan (mjordan) 2014-03-11 08:39:00.260-0500 Nitesh - when you feel like the patch is ready, feel free to put it up for review on review board. By: NITESH BANSAL (nbansal) 2014-03-12 05:31:14.757-0500 Hi Matt, I have tested this piece of code, it triggers the DTLS retransmissions. I didn't upload it on the review board because as per my understanding, asterisk isn't yet ready for DTLS-SRTP. As you can see from previous comments on this JIRA, lot of patching has been done to get it support DTLS. But if you believe that this patch can be still integrated into asterisk code base at this stage, i'll be happy to push it on review board. Regards, Nitesh By: Jay Jideliov (jideliov) 2014-03-18 14:19:45.971-0500 Matt, What are your thoughts on adding the DTLS patch to the upcoming 11.9 since it has been tested and is working as expected? Patches by Nitesh, Jonathan, and Moises are providing a quite reliable WSS implementation when combined with the subject of this ticket, and thus it might be a good idea to massively roll out this implementation for further contributions, enhancements, and testing. By: jag (jaflong) 2014-03-31 10:03:59.082-0500 I want to get this working on the lastest asterisk version. I am using 12.1.1 and I have manually applied this patch srtp_dtls.patch [ 49083 ] 10/Jan/14 9:32 AM However it comes up with an error. I am not sure what is required to fix. {noformat} res_pjsip_sdp_rtp.c: In function ‘add_crypto_to_stream’: res_pjsip_sdp_rtp.c:822: warning: passing argument 2 of ‘dtls->get_fingerprint’ makes pointer from integer without a cast res_pjsip_sdp_rtp.c:822: note: expected ‘const struct ast_rtp_dtls_cfg *’ but argument is of type ‘int’ res_pjsip_sdp_rtp.c:822: error: too few arguments to function ‘dtls->get_fingerprint’ make[1]: *** [res_pjsip_sdp_rtp.o] Error 1 make: *** [res] Error 2 if ((crypto_attribute = dtls->get_fingerprint(session_media->rtp, AST_RTP_DTLS_HASH_SHA1))) { RAII_VAR(struct ast_str *, fingerprint, ast_str_create(64), ast_free); if (!fingerprint) { return -1; } ast_str_set(&fingerprint, 0, "SHA-1 %s", crypto_attribute); attr = pjmedia_sdp_attr_create(pool, "fingerprint", pj_cstr(&stmp, ast_str_buffer(fingerprint))); media->attr[media->attr_count++] = attr; } {noformat} By: jag (jaflong) 2014-04-01 06:40:24.753-0500 Hi Nitest, Can I ask would this work with Asterisk 12 - latest. I get the impression that more pjsip functions are utilised in version 12. The first issue I need to resolve is why dtls config does not get enabled. Can you clarify your point 2 how you do this 2. I am relying on the config file to enable DTLS, it isn't enabled by default. thanks By: JoshE (n8ideas) 2014-04-01 08:47:36.002-0500 A slightly related question to the above, but is the expectation that we need to enable DTLS support via these options on a per peer only basis? Is it possible to do this in the [general] section of sip.conf? Any downside to developing a configuration there? By: jag (jaflong) 2014-04-01 09:38:02.624-0500 Asterisk 12 {noformat} chan_sip.c: In function ‘add_dtls_to_sdp’: chan_sip.c:12900: warning: passing argument 2 of ‘dtls->get_fingerprint’ makes pointer from integer without a cast chan_sip.c:12900: note: expected ‘const struct ast_rtp_dtls_cfg *’ but argument is of type ‘int’ chan_sip.c:12900: error: too few arguments to function ‘dtls->get_fingerprint’ make[1]: *** [chan_sip.o] Error 1 {noformat} I did the following to get to compile changed chan_sip.c from {noformat} if ((fingerprint = dtls->get_fingerprint(instance, AST_RTP_DTLS_HASH_SHA1))) { ast_str_append(a_buf, 0, "a=fingerprint:SHA-1 %s\r\n", fingerprint); } {noformat} to {noformat} if ((fingerprint = dtls->get_fingerprint(instance, &dialog->dtls_cfg, AST_RTP_DTLS_HASH_SHA256))) { ast_str_append(a_buf, 0, "a=fingerprint:SHA-256 %s\r\n", fingerprint); } else if ((fingerprint = dtls->get_fingerprint(instance, &dialog->dtls_cfg, AST_RTP_DTLS_HASH_SHA1))) { ast_str_append(a_buf, 0, "a=fingerprint:SHA-1 %s\r\n", fingerprint); } {noformat} By: Jay Jideliov (jideliov) 2014-04-03 21:54:04.401-0500 So, we have started experimenting with jssip as well, trying to get the overall Chrome-FF solution right. However, when going through wss, nothing happens on the receiving side (patches applied, as well as Nitesh's suggested JsSIP hack). I have attached a SIP debug that shows the issue, along with the Wireshark dump from the receiving side (notice that no INVITE is received). We have tried the same server config with SIPML (and there we get the usual 603 error on incoming calls, so everything is as expected there and the server config is fine). By: jag (jaflong) 2014-04-08 07:58:20.564-0500 I am using Asterisk 12.2.0-rc1, I updated with this patch file srtp_dtls.patch 07/Jan/14 7:38 AM from bug isssue ASTERISK-22961 https://issues.asterisk.org/jira/browse/ASTERISK-22961?jql=text%20~%20%22dtls%22 Rtp traffic seems to be sent and received, Asterisk debug log shows Sent RTP packet to 10.1.xxx.xxx:41143 (via ICE) (type 08, seq 021868, ts 221760, len 4294967284) Got RTP packet from 10.1.xxx.xxx:41143 (type 08, seq 001383, ts 1917269534, len 000160) Sent RTP packet to 10.1.xxx.xxx41143 (via ICE) (type 08, seq 021869, ts 221920, len 4294967284) Got RTP packet from 10.1.xxx.xxx:41143 (type 08, seq 001384, ts 1917269694, len 000160) Sent RTP packet to 10.1.xxx.xxx:41143 (via ICE) (type 08, seq 021870, ts 222080, len 4294967284) Got RTP packet from 10.1.xxx.xxx:41143 (type 08, seq 001385, ts 1917269854, len 000160) However the len is reported as "len 4294967284" which seems to be wrong No audio is heard on the browser. Please note this on a tls connection not wss. This is the sent sdp. =0 o=root 350315728 350315728 IN IP4 10.31.xxx.xxx s=Asterisk PBX 12.2.0-rc1 c=IN IP4 10.31.xxx.xxx t=0 0 m=audio 24316 UDP/TLS/RTP/SAVPF 8 0 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=maxptime:150 a=ice-ufrag:1c5c5d52130f06fd70e1e23f0d6323f2 a=ice-pwd:12611b8146599a9019d59b4b649a7970 a=candidate:Ha1f026f 1 UDP 2130706431 10.31.xxx.xxx 24316 typ host a=candidate:Ha1f026f 2 UDP 2130706430 10.31.xxx.xxx 24317 typ host a=connection:new a=setup:active a=fingerprint:SHA-256 13:BB:CF:88:C4:75:9B:F0:DA:36:0A:6D:5D:37:C9:26:6B:3C:82:3E:F6:92:AE:A7:AE:CF:FF:78:F5:86:D9:E8 a=sendrecv By: JoshE (n8ideas) 2014-04-11 11:33:09.612-0500 I have also been using this patch against Asterisk 11, and am seeing the attached crash. Anyone else experiencing this? Edit: forgive the rather non-aptly named backtrace (1).txt. But that's the crash in RTCP I'm seeing. By: jag (jaflong) 2014-04-23 03:57:17.678-0500 Hi Just a reminder Do you think any progress would be possible on the wrong, larger size rtp packets issue I reported. I believe this is the last hurdle in getting the webtrc working on the latests asterisk. Regards By: JoshE (n8ideas) 2014-04-27 21:01:41.340-0500 I just got a chance to look at this again. I see the same RTP packet size you did @jag, but that's a red herring. The issue here now appears to be ICE candidate negotiation on Asterisk. I am seeing Chrome stuck in the following: ICEConnectionStateChecking And a PCAP on the WebRTC client shows a loop of ICE Binding requests and responses. The net of it is that Chrome isn't ever sending RTP, because it isn't in the proper state. I applied As another note, I am testing with dev/beta Chrome 36/35, which no longer have fallback support by default for SDES, so DTLS-SRTP is going to be needed soon. This required another SIP patch to pass the crypto flag properly when the SDP only contains the m=audio 38517 RTP/SAVPF line. Josh By: Andrea Suisani (s1ckpig) 2014-05-09 10:46:52.936-0500 Sorry for being slight OT, but does anybody tested this env with realtime defined sip peers? I'm trying to reproduce the initial issue ("process_sdp_a_dtls: Unsupported fingerprint hash type 'sha-2' received on dialog") using asterisk 11.7.0 (vanilla and patched) and realtime sip peers, but I'm not able to. In such case asterisk produces a sdp with "m=audio 17326 RTP/SAVPF 0 8 101" but without the "a=fingerprint...", somwwhat it seems that the srtp doesn't kick in. whereas asterisk 11.9.0 (unpatched) with the same conf as 11.7.0 set both "m=audio" and "a=fingerprint" properly. thanks in advance. By: Jeremy Lainé (sharky) 2014-05-14 12:30:49.542-0500 As of Chrome 35, DTLS-SRTP is used by default and SDES is disabled, so Chrome & Firefox have effectively converged on this point. As a result, neither works out of the box with asterisk. Any progress on this issue? By: David Strejc (david.strejc) 2014-05-19 04:56:11.197-0500 Dear all, is there any progress with this sha-2 issue? I've tried patch for 11.7 but with no success. And I don't want to stay behind 12 branch of asterisk. I've also looked at trunk repository and it seems that there is no planned implementation of sha-2 support for WebRTC. Is there any chance or is there any patched version of asterisk available, so that I can go with WebRTC and Asterisk? Many thanks for anythink. David Strejc By: SirLouen (sirlouen) 2014-05-23 16:41:12.488-0500 Today Chrome finally did the last update to 35... the end of SDES... any workarounds that actually fullfil a proper communication already out there? What I've read so far are solutions based on 11.7... I cant even find 11.7 for download :( Sad day today my systems based on webrtc + 11.6-cert + chrome died By: Chetan Goti (chetangoti) 2014-05-24 05:50:56.287-0500 Our system died same as SirLouen. Please suggest any work around if any. We are running asterisk 11.6.0, but can upgrade to any. btw, I have tried this patch for 11.7.0 but its not working. Cannot connect to WSS. Thanks, Chetan. By: Thomas Guebels (tguescaux) 2014-05-24 08:55:31.453-0500 For me the dtls-srtp patch works great on asterisk 11, for outbound calls in Firefox 28 or Chrome 35. I just had to make a small change to allow inbound calls, from asterisk to the browsers: no a=fingerprint line was sent in the SDP of the INVITE from asterisk. However, since Firefox 29 it seems DTLS is broken again: {noformat} -- [RTCP] Received a DTLS message -- [RTCP] >> >> writing 15 bytes on read_BIO (to have it read later) -- [RTCP] >> >> >> actually wrote 15 bytes (should NOT retry) -- dtls_info_callback: read, where=16388, ret=554 -- >> 3RFINA, F, BC -- [RTCP] >> >> read -1 bytes from SSL -- [RTP] >> Still waiting for the DTLS handshake to complete, discarding packet (172) -- [RTP] Received a DTLS message -- [RTP] >> >> writing 15 bytes on read_BIO (to have it read later) -- [RTP] >> >> >> actually wrote 15 bytes (should NOT retry) -- dtls_info_callback: read, where=16388, ret=554 -- >> 3RFINA, F, BC -- [RTP] >> >> read -1 bytes from SSL res_rtp_asterisk.c: DTLS failure occurred on RTP instance '0xa3da5d4', terminating {noformat} By: SirLouen (sirlouen) 2014-05-24 08:59:27.951-0500 Thomas Guebels, which version are you using? I tried 11.7.0 and 11.9.0 with the patch https://issues.asterisk.org/jira/secure/attachment/49083/srtp_dtls.patch Both give some chunk errors (3 erros) By: Chetan Goti (chetangoti) 2014-05-24 09:05:49.862-0500 I also completed patching 11.9.0 and it still does not work. Is there any specific things to generate SSL certificates? [May 24 13:48:01] WARNING[4010][C-00000001]: chan_sip.c:10520 process_sdp: Processed DTLS [FALSE] [May 24 13:48:01] WARNING[4010][C-00000001]: chan_sip.c:10522 process_sdp: Rejecting secure audio stream without encryption details: audio 64922 UDP/TLS/RTP/SAVPF 111 103 104 0 8 106 105 13 126 By: Agustí Ubalde (aubalde) 2014-05-26 06:27:54.051-0500 Is possible to apply this patch to version 11.9.0 (https://issues.asterisk.org/jira/secure/attachment/49083/srtp_dtls.patch)? By: Chetan Goti (chetangoti) 2014-05-26 07:56:08.202-0500 Agusti, I manually applied patch on 11.9.0 and it did not work. By: JoshE (n8ideas) 2014-05-27 18:26:21.012-0500 So there are a few misconceptions here. First, the original patch *does* apply against Asterisk 11.6-11.9. To patch cleanly, it requires that you have the Opus patches already applied to Asterisk. Obviously, this can't be done for a production merge of the code, but it does work if you're trying to build off your own source tree. IIRC, there may have been one manual adjustment to the patch, but it was extremely minor. In addition, if you're using sipml5, you are definitely going to have to patch it in a few places, due mostly to issues with Chrome and Firefox on interpretation of the standards. Thomas is also correct that an a=fingerprint modification is required for incoming SDP to the browser, as well as the "actpass" setting for DTLS. Once I got this all in, everything worked normally for me. However: there are a number of big stability issues with this patch when used at scale. Seeing very frequent crashes in res_rtp_asterisk.c. By: NITESH BANSAL (nbansal) 2014-05-28 03:22:18.198-0500 Hello everybody, Lately I did not have much time to work with WebRTC. But there were some enhancements to this patch, I have used this patch with Asterisk 11.4 (i haven't tried any other version, but i believe it should be easy to adapt this patch to any 11.x asterisk versions) and it has been in production for over a month now and there wasn't a single crash. But I am using this patch just to support inbound calls i.e from browser to asterisk. There were couple of other webRTC patches also, which should be interesting, ASTERISK-23649, ASTERISK-22911, ASTERISK-23213. Hope it helps. Nitesh Bansal By: Igor Skomorokh (ISkomorokh) 2014-05-28 07:34:10.836-0500 Hi all, Are those patches going to be incorporated in next (11.10) release? When Chrome updated to version 35 - all my WebRTC projects went down (no matter what I use - sipml5 or jssip; dtls-srtp is setup). According to https://groups.google.com/forum/#!topic/doubango/iQ_8rgpbm0k there is a way out (set up webrtc2sip server) but I don't find it attractive. Thanks! By: Lorenzo Miniero (lminiero) 2014-05-28 08:12:37.340-0500 Just to add what Nitesh said, I've also been using the patches successfully for months, but like him I'm only using it to receive calls. Outgoing calls (or calls originated by Asterisk) may require some care. Anyway, for those terrified about Chrome M35: SDES has not been removed, it's just not the default anymore. You can still make use of it by passing a constraint to disable DTLS (DtlsSrtpKeyAgreement:false). By: JoshE (n8ideas) 2014-05-28 08:33:22.005-0500 The backtrace I attached to this ticket as backtrace (1).txt shows the crash scenario I observed, and I observed it frequently enough to believe it's probably real, at least for the traffic pattern on this particular box. The setup I have is a mixture of inbound and outbound WebRTC and standard SIP/UDP and SIP/TCP calls on a box. Call leg count is typically 100 or more. Not sure what you all were doing with volume or if the mixture of traffic on the box is different, but it seems to occur for me with this patch set included. By: Thomas Guebels (tguescaux) 2014-05-28 08:35:12.524-0500 Hi Lorenzo, Does it also work with Firefox 29 in your setup ? It seems something changed in the DTLS negotiation compared to 28. For calls from asterisk to the browser, I removed the check {{rtp->remote_fingerprint_type != fingerprint_type}} in {{ast_rtp_dtls_get_fingerprint}} as the remote fingerprint type is not yet set at this point. This in turn allows asterisk to add an {{a=fingerprint}} line to the outgoing SDP. By: SirLouen (sirlouen) 2014-05-28 11:59:23.179-0500 @NITESH BANSAL, I applied patch to a clean 11.4.0 and found 1 error, any suggestions? patching file res/res_rtp_asterisk.c Hunk #1 succeeded at 123 (offset -2 lines). Hunk #2 succeeded at 264 (offset -4 lines). Hunk #3 succeeded at 289 (offset -4 lines). Hunk #4 FAILED at 362. I see in the code /* VP8: sequence number for the RTCP FIR FCI */ Are you applying a patch before? Meetecho's Opus/VP8 or something like this? EDIT: Ok, applying patch ASTERISK-21981 EDIT2: After applying the patch: ---> INVITE <--- INVITE 401 ---> ACK ----> INVITE <---- INVITE 488 [May 28 13:15:15] WARNING[22982][C-00000002]: chan_sip.c:10445 process_sdp: Processed DTLS [FALSE] [May 28 13:15:15] WARNING[22982][C-00000002]: chan_sip.c:10447 process_sdp: Rejecting secure audio stream without encryption details: audio 53955 UDP/TLS/RTP/SAVPF 111 103 104 0 8 106 105 13 126 <--- Reliably Transmitting (no NAT) to my_ip:5060 ---> SIP/2.0 488 Not acceptable here EDIT3: Ok Found the problem. I was putting the DTLS sip.conf configurations in the [general] tab instead of the concrete peer. Now New error: [May 28 15:20:42] ERROR[23967][C-00000000]: res_rtp_asterisk.c:800 ast_rtp_dtls_set_configuration: Specified private key file '/etc/asterisk/keys/asterisk.pem' for RTP instance '0x7f3ccc020718' could not be used [May 28 15:20:42] ERROR[23967][C-00000000]: chan_sip.c:5851 dialog_initialize_dtls_srtp: Attempted to set an invalid DTLS-SRTP configuration on RTP instance '0x7f3ccc020718' I used the ast_tls_cert script to generate the certs as explained here https://wiki.asterisk.org/wiki/display/AST/Secure+Calling+Tutorial EDIT4: Ok, minimal configuration just worked for me: dtlsenable = yes dtlsverify = no dtlscertfile=/etc/asterisk/keys/asterisk.pem dtlscafile=/etc/asterisk/keys/ca.crt I confirm with this, outbound calls working. EDIT 5: Working also in Firefox v29 By: Juan Ramirez (ichramm) 2014-05-28 15:48:25.240-0500 @Nitesh There's a problem with the patch you've uploaded, take a look a the following text I've extracted from the file: {noformat} if (ast_test_flag(&dialog->flags[1], SIP_PAGE2_TEXTSUPPORT)) { @@ -5977,14 +5974,15 @@ ice->stop(dialog->trtp); } - if (dialog_initialize_dtls_srtp(dialog, dialog->trtp, &dialog->tsrtp)) { - return -1; - } - /* Do not timeout text as its not constant*/ ast_rtp_instance_set_keepalive(dialog->trtp, dialog->rtpkeepalive); ast_rtp_instance_set_prop(dialog->trtp, AST_RTP_PROPERTY_RTCP, 1); + + /*SRTP_DTLS */ + if (dialog_initialize_dtls_srtp(dialog, dialog->vrtp, &dialog->vsrtp)) { + return -1; + } } {noformat} It is initializing the *video* RTP instead of the *text* rtp Regards Juan By: Jay Jideliov (jideliov) 2014-05-28 17:45:27.622-0500 I suggest we create a DTLS branch of 11.9 with a working configuration to make it easier to debug, enhance, and make it a good candidate for the next revision. I have attached an archive with files patched for 11.9 for those who want to get running faster. As per previous comments, the JS-side modification is still necessary, although this should not be the case soon (I have notified the WebRTC team about the timeline of the matter a month ago, and they will be pushing the change soon) - https://code.google.com/p/webrtc/issues/detail?id=2796 This thread is getting more and more popular by the day, so hopefully the patch makes it into the next release. By: Juan Ramirez (ichramm) 2014-05-29 09:22:13.034-0500 @Jay, Have in mind the the {{chan_sip.c}} you've attached has the same problem as @Nitesh's patch Regards By: Andrea Suisani (s1ckpig) 2014-05-29 10:41:39.505-0500 as Lorenzo said here: https://issues.asterisk.org/jira/browse/ASTERISK-22961?focusedCommentId=218535&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-218535 I can confirm that using {'mandatory': {'DtlsSrtpKeyAgreement': 'false'}} as a constraint while creating a rtc peer connection solves the issue putting SDES back in charge. This means that you can use vanilla asterisk with chrome v35 as long as you care to disable SRTP-DTLS at js level. By: Juan Ramirez (ichramm) 2014-05-29 12:20:59.418-0500 Just uploaded a patch for 11.9 based on files from @Jay's files. I fixed the error in chan_sip.c and corrected some spacing issues. Regards By: Agustí Ubalde (aubalde) 2014-05-30 06:33:32.639-0500 @Jay, I tried to compile Asterisk 11.9 applying the patch but I get the following error in the console: ======================================================================== chan_sip.c: In function ‘process_sdp_a_dtls’: chan_sip.c:11072: error: ‘AST_RTP_DTLS_HASH_SHA256’ undeclared (first use in this function) chan_sip.c:11072: error: (Each undeclared identifier is reported only once chan_sip.c:11072: error: for each function it appears in.) chan_sip.c: In function ‘process_crypto’: chan_sip.c:33310: warning: unused variable ‘dtls’ chan_sip.c: In function ‘load_module’: chan_sip.c:34758: error: ‘dtls’ undeclared (first use in this function) chan_sip.c:34758: error: ‘rtp’ undeclared (first use in this function) chan_sip.c:34760: error: ‘p’ undeclared (first use in this function) make[1]: *** [chan_sip.o] Error 1 make: *** [channels] Error 2 ======================================================================== Any idea? Best, Agustí By: Agustí Ubalde (aubalde) 2014-05-30 07:25:07.695-0500 Hi, I have finally been able to compile Asterisk 11.9.0 patch with @Juan Ramirez, but when trying to make a call from an internal Asterisk PBX to WebRTC extension registered with sipml5 I get several errors in the console. It not works. =================================================================================================== -- Registered SIP '40002' at X.X:X:X:53160 == Using SIP RTP CoS mark 5 == Using SIP RTP CoS mark 5 [May 30 13:59:12] WARNING[21402][C-00000001]: chan_sip.c:10523 process_sdp: Processed DTLS [FALSE] -- Executing [40002@public:1] Dial("SIP/Y.Y.Y.Y-00000002", "SIP/40002") in new stack == Using SIP RTP CoS mark 5 == Using SIP RTP CoS mark 5 [May 30 13:59:12] ERROR[21484][C-00000001]: netsock2.c:269 ast_sockaddr_resolve: getaddrinfo("df7jal23ls0d.invalid", "(null)", ...): Name or service not known [May 30 13:59:12] WARNING[21484][C-00000001]: chan_sip.c:15972 __set_address_from_contact: Invalid host name in Contact: (can't resolve in DNS) : 'df7jal23ls0d.invalid' [May 30 13:59:12] ERROR[21484][C-00000001]: netsock2.c:98 ast_sockaddr_stringify_fmt: getnameinfo(): ai_family not supported -- Called SIP/40002 -- SIP/40002-00000003 is ringing -- No one is available to answer at this time (1:0/0/0) -- Executing [40002@public:2] Hangup("SIP/Y.Y.Y.Y-00000002", "") in new stack == Spawn extension (public, 40002, 2) exited non-zero on 'SIP/Y.Y.Y.Y-00000002' =================================================================================================== Error in Google Chrome console: =================================================================================================== Failed to set remote offer sdp: Called with SDP without DTLS fingerprint. SIPml-api.js?svn=179:1080 tsk_utils_log_error SIPml-api.js?svn=179:1080 tmedia_session_jsep01.onSetRemoteDescriptionError SIPml-api.js?svn=179:2740 (anonymous function) =================================================================================================== With the release of Asterisk 11.7.0 works properly, at least with Google Chrome. Regards, By: Juan Ramirez (ichramm) 2014-05-30 08:40:13.665-0500 @Agustí Calls from Asterisk to WebRTC do not work for me either. As far as I now, the SHA fingerprint is not being added to the SDP. From the code in res_rtp_asterisk.c (function {{ast_rtp_dtls_set_configuration}}), it seems that the variables {{dtlscertfile}}, {{dtlsprivatekey}} and {{dtlscafile}} must be set properly (maybe it's just {{dtlscertfile}}, but I haven't tested yet). {noformat} if (!ast_strlen_zero(dtls_cfg->certfile)) { ... {noformat} I created a self-signed certificate but SSL rejected it so I guess I made a mistake somewhere. This afternoon I'm going to test some other options: I'll try to make asterisk use his own certificate (like in a global setting) when making outbound calls, and don't know much about DTLS but the least I can do is to try. Regard, Juan By: Juan Ramirez (ichramm) 2014-06-02 18:51:50.262-0500 Ok, the attached patch should fix the problem with the WebRTC peers not being able to receive calls. This patch contains all the modifications of the previous one, and it's based on Asterisk 11.10. I modified the function {{ast_rtp_dtls_get_fingerprint}} in order to return the local one when the remote fingerprint is not set already. Note that, besides {{dtlscertfile}} and {{dtlsprivatekey}} (which must both point to the corresponding files), *{{dtlssetup = actpass}}* must be set in the peer in order to prevent sipml5 from rejecting the call. By: Agustí Ubalde (aubalde) 2014-06-03 03:39:55.005-0500 Hi @Juan, I'm trying to apply the last patch to the Asterisk 11.10 but I've some errors compiling Asterisk source: chan_sip.c: In function ‘add_rpid’: chan_sip.c:12572: error: ‘anonymous_string’ undeclared (first use in this function) chan_sip.c:12572: error: (Each undeclared identifier is reported only once chan_sip.c:12572: error: for each function it appears in.) chan_sip.c: In function ‘process_crypto’: chan_sip.c:33322: warning: unused variable ‘dtls’ make[1]: *** [chan_sip.o] Error 1 make: *** [channels] Error 2 Best, By: Lorenzo Miniero (lminiero) 2014-06-03 04:22:34.635-0500 Hi, I'm attaching a further patch (called asterisk-11.9.0-dtls.diff, listed above) along to those which have been submitted these latest few days. Andrea Suisani and I have worked on it within the framework of a collaboration among us, and this patch mostly includes the original DTLS fixes by Nitesh and me, plus the tsrtp issue someone mentioned before and some extras that were needed in order to get it working with outbound calls (or, in a few cases, working at all). Specifically, as jag also already pointed out, we had to fix the ast_rtp_dtls_get_fingerprint method, as it would return NULL in case of outgoing calls. We also had to fix a problem in parsing DTLS, which not always resulted in a crypto context to be detected, thus occasionally leading to call failure. To make things easier and avoid JavaScript mangling, we replaced UDP/TLS/RTP/SAVPF with the RTP/SAVPF browsers expect: controversial choice, but it helped us move along. The patch also includes the ASTERISK-23026 fix (https://issues.asterisk.org/jira/browse/ASTERISK-23026) as we noticed that from time to time (often, actually), there would be no audio in DTLS-SRTP calls. We found out the problem to be with ICE, actually, and specifically in a conflict between Asterisk and browsers on CONTROLLING/CONTROLLED roles. That patch forces a specific behaviour and so has not been completely accepted in that discussion, but it fixed the problem for us and so we thought we'd integrate it as well. That said, this patch is obviously not meant to be considered for integration within the Asterisk main code as it is, but rather as a testbed for people to play with. Feedback on whether or not it works for people would definitely help find a concrete solution to the Asterisk DTLS issues. We have been trying this in the field (and in some production environments as well) and it seems to work fine, although we experienced some occasional force closes within the DTLS code that we wanted to investigate: more testing from people interested in the functionality would definitely help making this investigation easier. Hope this helps! By: Andrea Suisani (s1ckpig) 2014-06-03 05:11:57.788-0500 Hi all, I've just added a back-trace related to the segfault Lorenzo was referring to [^backtrace.txt] . The production environment: asterisk 11.9.0 + Lorenzo last patch ([^asterisk-11.9.0-dtls.diff]), SO Debian 6.0, libssl 1.0.1g compiled from source. We need to compile libssl from source code b/c Debian 6.0 come with lib 0.9.8o and it seems it doesn't support DTLS properly. As Lorenzo already mentioned It seems that the crash happens inside libssl. It would be nice if the patch will be tested on a system that come with an up-to-date libssl version (ubuntu >= 12.04 should suffice or debian > 6) to see if it works properly without segfaulting. Andrea By: Juan Ramirez (ichramm) 2014-06-03 14:55:54.220-0500 @Agustí: The patch removes the variable {{anonymous_string}}, maybe the patch failed somewhere, I believe removing the usage here should be enough, look: {noformat} struct ast_party_id connected_id; - const char *anonymous_string = "\"Anonymous\" <sip:anonymous@anonymous.invalid>"; ... ... - /* trust_id_outbound = legacy - behave in a non RFC-3325 compliant manner and send anonymized data when - * when handling private data. */ - if ((lid_pres & AST_PRES_RESTRICTION) == AST_PRES_ALLOWED) { - ast_str_set(&tmp, -1, "\"%s\" <sip:%s@%s>", lid_name, lid_num, fromdomain); - } else { - ast_str_set(&tmp, -1, "%s", anonymous_string); - } - } - add_header(req, "P-Asserted-Identity", ast_str_buffer(tmp)); - } else { {noformat} @Andrea: @Lorenzo and @Andrea: Thank you very much for your efforts, I was having the no audio issue from time to time but couldn't figure out what was going on.. Can you isolate the changes you made in order to fix the ICE negotiation problem? I took a peek in the other issue and found only this: {noformat} @@ -1861,7 +2439,7 @@ passwd = pj_str(rtp->local_passwd); /* Create an ICE session for ICE negotiation */ - if (pj_ice_sess_create(&stun_config, NULL, PJ_ICE_SESS_ROLE_UNKNOWN, 2, + if (pj_ice_sess_create(&stun_config, NULL, PJ_ICE_SESS_ROLE_CONTROLLING, 2, &ast_rtp_ice_sess_cb, &ufrag, &passwd, &rtp->ice) == PJ_SUCCESS) { /* Make this available for the callbacks */ rtp->ice->user_data = rtp; @@ -1973,7 +2551,14 @@ {noformat} Is that enough? BTW, answering @Andrea's question, I'm using openssl 1.0.1.g and had no segfaults so far (only tested a few calls anyway) Juan By: Ximena Velasco Melo (xvelasco) 2014-06-03 18:54:42.315-0500 Hi All, I'm currently using Asterisk 12.0.0 and I have manually applied the patches: Patch_11.9_JayNitesh_corrected.patch and Patch_11.10-Fixed-DTLS-issues.patch. However, as Jag commented before, it comes up with an error and I still don't know what is required to fix it: res_pjsip_sdp_rtp.c: In function ‘add_crypto_to_stream’: res_pjsip_sdp_rtp.c:821: warning: passing argument 2 of ‘dtls->get_fingerprint’ makes pointer from integer without a cast res_pjsip_sdp_rtp.c:821: note: expected ‘const struct ast_rtp_dtls_cfg *’ but argument is of type ‘int’ res_pjsip_sdp_rtp.c:821: error: too few arguments to function ‘dtls->get_fingerprint’ make[1]: *** [res_pjsip_sdp_rtp.o] Error 1 make: *** [res] Error 2 Many thanks for your help. By: Andrea Suisani (s1ckpig) 2014-06-04 02:10:54.758-0500 @Juan I you're right, the change needed to fix the audio problem is the one you've isolated. You can find further info related to that change here: ASTERISK-23026 and https://issues.asterisk.org/jira/browse/ASTERISK-23026. Regarding the segfault: I'm not able to reproduce it on my test env, it happens only when running in production 6 to 10 concurrent sip peers that place calls for 3 to 4 hours. Anyway what is your operating system? Andrea By: Agustí Ubalde (aubalde) 2014-06-04 05:42:37.568-0500 Hi @Juan, All is OK using Chrome v.32.0.1700.102, but it doesn't work with Chrome v.35. Is it rigth? ======================================================================== Failed to set remote offer sdp: Called with SDP without DTLS fingerprint. SIPml-api.js?svn=179:1080 tsk_utils_log_error SIPml-api.js?svn=179:1080 tmedia_session_jsep01.onSetRemoteDescriptionError SIPml-api.js?svn=179:2740 (anonymous function) ======================================================================== Best, By: Ximena Velasco Melo (xvelasco) 2014-06-04 12:15:23.714-0500 Hi All, I'm currently using Asterisk 12.0.0, and I found that the patches changed the following line on include/asterisk/rtp_engine.h: - const char *(*get_fingerprint)(struct ast_rtp_instance *instance, enum ast_rtp_dtls_hash hash); + const char *(*get_fingerprint)(struct ast_rtp_instance *instance, const struct ast_rtp_dtls_cfg *dtls_cfg, enum ast_rtp_dtls_hash hash); This change is generating an error when compiling res/res_pjsip_sdp_rtp.c: if ((crypto_attribute = dtls->get_fingerprint(session_media->rtp, AST_RTP_DTLS_HASH_SHA1))) { RAII_VAR(struct ast_str *, fingerprint, ast_str_create(64), ast_free); if (!fingerprint) { return -1; } ast_str_set(&fingerprint, 0, "SHA-1 %s", crypto_attribute); attr = pjmedia_sdp_attr_create(pool, "fingerprint", pj_cstr(&stmp, ast_str_buffer(fingerprint))); media->attr[media->attr_count++] = attr; } Error: res_pjsip_sdp_rtp.c: In function ‘add_crypto_to_stream’: res_pjsip_sdp_rtp.c:821: warning: passing argument 2 of ‘dtls->get_fingerprint’ makes pointer from integer without a cast res_pjsip_sdp_rtp.c:821: note: expected ‘const struct ast_rtp_dtls_cfg *’ but argument is of type ‘int’ res_pjsip_sdp_rtp.c:821: error: too few arguments to function ‘dtls->get_fingerprint’ make[1]: *** [res_pjsip_sdp_rtp.o] Error 1 make: *** [res] Error 2 Does anybody have the same error? Is there a workaround regarding to this issue? Many Thanks for your help. By: Juan Ramirez (ichramm) 2014-06-04 13:09:54.777-0500 @Agustí The patch modified the function {{ast_rtp_dtls_get_fingerprint}}, which now returns the local fingerprint when making outbound calls. The local fingerprint is initialized only if the peer is properly configured, the fingerprint is not created if there's no certificate associated with the peer being called. Here is how I configured my WebRTC peer in order to be able to send and receive calls: {noformat} [3000] type=peer secret=1234 host=dynamic context=webrtc_test encryption=yes transport=udp,ws,wss icesupport=yes avpf=yes dtlsenable=yes dtlsverify=no dtlscertfile=/home/ichramm/devel/packages/asterisk/current/ssl_certificate/certs/crt.ca.pem dtlsprivatekey=/home/ichramm/devel/packages/asterisk/current/ssl_certificate/private/key.ca.pem dtlssetup=actpass {noformat} . . . Can you confirm the following code is present in {{res_rtp_asterisk.c}}? {noformat} if (rtp->remote_fingerprint_type == AST_RTP_DTLS_HASH_NONE) { // no remote fingerprint yet, it means we are ones starting communication return rtp->local_fingerprint; } {noformat} There's also a log in Asterisk, which is present if the fingerprint couldn't be obtained: {{No fingerprint was added to SDP, this may not work}} Note: The new patch uploaded by @Lorenzo adds a new check there, which forces the user to request a SHA-256 fingerprint, this is the default so there will be no problem with it. . . . @Ximena: Have you tried to pass {{session->endpoint->media.rtp.dtls_cfg}} as parameter? I'm not sure if it's going to work 'cause a lot has changed in Asterisk 12.. but it worth a try! . . . @Andrea: I've been testing only in my personal computer, which runs Archlinux, but it's intended to be installed in debian 6. By: Juan Ramirez (ichramm) 2014-06-04 17:52:53.136-0500 @Lorenzo I think there's another bug in the patch: {noformat} // res_rtp_asterisk.c ... while ((value = strsep(&tmp, ":")) && (pos != (EVP_MAX_MD_SIZE - 1))) { sscanf(value, "%02x", (unsigned int*)&rtp->remote_fingerprint[pos++]); } + ast_log(LOG_ERROR,"remote fingerprint (RTP) set\n"); + + /* SRTP_DTLS: do the same with RTCP */ + while ((value = strsep(&tmp, ":")) && (pos != (EVP_MAX_MD_SIZE - 1))) { + sscanf(value, "%02x", (unsigned int*)&rtp->rtcp->remote_fingerprint[pos++]); + } + ast_log(LOG_ERROR,"remote fingerprint (RTCP) set\n"); {noformat} The second loop has no effect because {{tmp}} already points at the end of the string (unless there are two fingerprints in the same buffer which I don't think is the case. I replaced the second loop with {{memcpy(rtp->rtcp->remote_fingerprint, rtp->remote_fingerprint, sizeof(rtp->remote_fingerprint));}}. Regards Juan By: Agustí Ubalde (aubalde) 2014-06-05 04:52:59.711-0500 Hi @Juan, I created self-signed certificates and I have configured to the peers. The problem is that an error that the key file can not be used appears in the asterisk console: ===================================================================================== Specified private key file '/ etc / asterisk / keys / asterisk.pem' for RTP instance '0 x7f547002f218 'could not be used ===================================================================================== I need to install a certificate in the browser? Best, By: Juan Ramirez (ichramm) 2014-06-05 08:51:01.595-0500 @Agustí, The same happened to me! I had to change the way I was creating the certificate, see here for details: https://gist.github.com/ichramm/d458e3296cb33f096761 And no, you don't have to install the certificate. Juan By: Agustí Ubalde (aubalde) 2014-06-06 04:37:18.165-0500 @Juan, I've configured the certificate as detailed on . But it doesn't work either version "32" or version "35" of Google Chrome. This is the error showed on the Google Chrome console: ======================================================= Failed to parse SessionDescription. Failed to parse audio codecs correctly. ======================================================= With SIP tracer enabled, this is the error showed on Asterisk console: ======================================================= -- Got SIP response 603 "Declined" back ... ======================================================= Any idea? Thanks, By: Alexander gassiev (corax) 2014-06-06 10:13:21.894-0500 Hi all We use Asterisk 11.9 and patched it for using with DTLS But when calling we have such error: WARNING[7767][C-0000000a]: res_rtp_asterisk.c:1861 dtls_srtp_setup: Could not set policies when setting up DTLS-SRTP on '0x7f8230059d90' [Jun 6 14:09:01] WARNING[7767][C-0000000a]: res_rtp_asterisk.c:4193 ast_rtp_read: RTP Read error: Unspecified. Hanging up. http.conf: tlsenable=yes tlsbindaddr=0.0.0.0:8089 user in sip.conf: [101] context=default trustrpid=yes sendrpid=no qualify=yes qualifyfreq=600 type=friend regexten=101 context=out secret=XXXXXXXXXX encryption=yes defaultuser=101 fromuser=101 host=dynamic avpf=yes transport=udp,ws,wss icesupport=yes directmedia=no disallow=all allow=ulaw dtlsenable=yes dtlsverify=no dtlsrekey=60 dtlscertfile=/var/lib/asterisk/keys/asterisk.pem dtlsprivatekey=/var/lib/asterisk/keys/asterisk.pem dtlscipher=ALL dtlscapath=/var/lib/asterisk/keys/ dtlssetup = actpass Can anyone tell me how to fix this? May be problem is in keys? If yes, how should I generate keys properly for Asterisk+DTLS? By: Juan Ramirez (ichramm) 2014-06-13 16:47:02.046-0500 Attaching working patch for Asterisk 11.10.0 By: Agustí Ubalde (aubalde) 2014-06-16 03:56:57.653-0500 @Juan, Is possible to work applying the last patxh without tls certificates in Google Chrome? Thanks, By: Agustí Ubalde (aubalde) 2014-06-16 04:12:26.627-0500 @Juan, I'm getting some errors compiling attached patch to the version 11.10.0. =========================================================== res_rtp_asterisk.c: In function ‘dtls_srtp_setup’: res_rtp_asterisk.c:1895: error: ‘struct ast_rtp’ has no member named ‘dtlsdone’ res_rtp_asterisk.c: In function ‘rtp_sendto’: res_rtp_asterisk.c:2143: error: ‘struct ast_rtp’ has no member named ‘dtlsdone’ res_rtp_asterisk.c: In function ‘ast_rtp_new’: res_rtp_asterisk.c:2516: error: ‘struct ast_rtp’ has no member named ‘instance’ res_rtp_asterisk.c: In function ‘ast_rtp_activate’: res_rtp_asterisk.c:4936: error: ‘struct ast_rtp’ has no member named ‘ice’ res_rtp_asterisk.c:4936: error: ‘struct ast_rtp’ has no member named ‘icedone’ make[1]: *** [res_rtp_asterisk.o] Error 1 make: *** [res] Error 2 =========================================================== Thanks, By: vsemak (vsemak) 2014-06-19 05:02:59.863-0500 Juan Ramirez patch for 11.10.0 works for us perfectly. Thank You. By: Agustí Ubalde (aubalde) 2014-06-19 08:39:03.501-0500 @vsemak, Hi, have you applied the patch to the official version 11.10.0? Thanks, By: Yuriy Gorlichenko (ovoshlook) 2014-06-19 12:01:49.054-0500 @Juan Ramirez Strange think: Patch successfully installed at ubuntu 14.04 but at centos 6.5 I see the same errors as Agustí Ubalde posted at the previ;6ous post. By: Juan Ramirez (ichramm) 2014-06-19 12:19:25.130-0500 @Yuriy @Agustí found out that there was a problem with uuid, passing {{-with-uuid}} to {{configure}} seemed to work for him, but not for me when compiling in debian squeeze. I finally hacked into the Makefile and commented out the line causing of the error: {{vi res/Makefile +92}} You'll see the following code: {noformat} ifeq ($(subst 1:0,1,$(UUID)), 1) res_rtp_asterisk.o: $(PJ_LIB_FILES) res_rtp_asterisk.o: _ASTCFLAGS+=-DUSE_PJPROJECT res_rtp_asterisk.o: _ASTCFLAGS+=$(PJ_CFLAGS) res_rtp_asterisk.so: _ASTLDFLAGS+=$(PJ_LDFLAGS) res_rtp_asterisk.so: LIBS+=$(PJ_LDLIBS) endif {noformat} Just remove or comment out the if: {noformat} #ifeq ($(subst 1:0,1,$(UUID)), 1) res_rtp_asterisk.o: $(PJ_LIB_FILES) res_rtp_asterisk.o: _ASTCFLAGS+=-DUSE_PJPROJECT res_rtp_asterisk.o: _ASTCFLAGS+=$(PJ_CFLAGS) res_rtp_asterisk.so: _ASTLDFLAGS+=$(PJ_LDFLAGS) res_rtp_asterisk.so: LIBS+=$(PJ_LDLIBS) #endif {noformat} Note: Compilation fails because the code is not correctly guarded by the macro {{USE_PJPROJECT}}, this is wrong, but I preffer it that way because is the only way (for now) to ensure whether WebRTC is available or not. By: Yuriy Gorlichenko (ovoshlook) 2014-06-19 23:43:05.225-0500 @Juan Ramirez Thanks. Asterisk compiled, but I still have an error about Unsupported fingerprint hash type 'sha-2'. I may only to say rhat when I did "make" I see WARNING at res_rtp_asterisk.c (or res_srtp_asterisk.c - can not remember) - unused variable "dtls". when I installed it at ubuntu I can.t remember this WARNING. I Patched from dir asterisk-11.10.0 with command "patch -p1 < patch.name" P.S. Somebody tested PJSIP with webrtc? Does it have same errors with webrtc realisation? By: JoshE (n8ideas) 2014-06-20 11:18:26.448-0500 A couple things that are still broken with the code, which I have ported to 11.10.2 with only minor adjustments to the patch. Placing a call on hold fails, with the following: -- dtls_info_callback: read, where=16388, ret=256 -- >> SSLOK , W, CN [2014-06-19 17:48:11] ERROR[32519][C-00000070]: res_rtp_asterisk.c:1991 __rtp_recvfrom: DTLS failure occurred on RTP instance '0x7f00d8168368', terminating Additionally, there is a crash path. It occurs when faxdetect is set to yes globally and you make an outbound call of any sort that reaches a fax machine. The crash is here: #0 0x00007f269c7ca417 in dtls_srtp_check_pending (instance=0x7f26f007fb68, rtp=0x7f26f0016b10) at res_rtp_asterisk.c:1718 1718 pending = BIO_ctrl_pending(rtp->rtcp->write_bio); #0 0x00007f269c7ca417 in dtls_srtp_check_pending (instance=0x7f26f007fb68, rtp=0x7f26f0016b10) at res_rtp_asterisk.c:1718 pending = 0 __PRETTY_FUNCTION__ = "dtls_srtp_check_pending" #1 0x00007f269c7caf17 in __rtp_recvfrom (instance=0x7f26f007fb68, buf=0x7f26f0016cc8, size=8192, flags=0, sa=0x7f26953cfbc0, rtcp=0) at res_rtp_asterisk.c:1923 len = 172 rtp = 0x7f26f0016b10 srtp = 0x0 in = 0x7f26f0016cc8 "\200" __PRETTY_FUNCTION__ = "__rtp_recvfrom" Workaround temporarily, at least, is to put a check for rtp->rtcp == 0 in dtls_srtp_check_pending. Hope that helps a little bit. By: Andrea Suisani (s1ckpig) 2014-06-23 07:44:19.995-0500 For what is worth it seems that a member of digium's staff ("file") is working on this problem, you can check his work here: http://svnview.digium.com/svn/asterisk/team/file/sha256-a-harsh-reality/ hopefully soon we will have DTLS-SRTP/SHA-256 support integrated into asterisk 11.X By: Rusty Newton (rnewton) 2014-06-23 10:28:34.682-0500 {quote} For what is worth it seems that a member of digium's staff ("file") is working on this problem, you can check his work here: {quote} "file" = Joshua Colp (the current assignee of the issue) :) By: Agustí Ubalde (aubalde) 2014-06-24 14:46:57.007-0500 @Juan, Thank you very much! Finally I've compiled and it works with the last version of Google Chrome using self-signed certificate in the Asterisk 11 server. Any problem with Firefox? I have not got any way to work with this browser. Best, Agustí By: Andrea Suisani (s1ckpig) 2014-06-25 08:13:34.561-0500 {quote} "file" = Joshua Colp (the current assignee of the issue) {quote} thanks for the clarification Rusty. By: Joshua C. Colp (jcolp) 2014-06-26 10:39:19.494-0500 This is correct, I have been working on a branch to cover not just SHA-256 support but all the other things that have crept up. It is going up for code review at https://reviewboard.asterisk.org/r/3679/ and after going through review will be incorporated into the Asterisk 11 branch, and ultimately the next release. I've tested the code against Chrome, Yandex Browser, Opera, Maxthon, and Firefox. I was able to achieve two way audio for inbound and outbound calls with all of them. In the case of Chrome based browsers I was also able to hold/unhold using sipml5. For Firefox this is not currently working and I will be sending an email to the sipml5 mailing list to discuss the best course of action going forward for it. If you would like to test it yourself you are more than welcome. The easiest way is to check out the branch itself using subversion with the following command: svn co http://svn.asterisk.org/svn/asterisk/team/file/sha256-a-harsh-reality Once done go into the sha256-a-harsh-reality directory and compile Asterisk like you normally would. Please post feedback on this issue. I know that at least one person has already checked it out and confirmed that it has fixed many problems for them. Cheers, By: Andrea Suisani (s1ckpig) 2014-06-27 02:11:23.075-0500 Joshua many thanks for your work. Are you planning to test your branch against JsSIP also? If yes use their git devel branch rather than master cause the former is near to be released and contains the necessary infrastructure for hold/unhold. Having said that as soon as I've time I'll give your code a try and I'll report back here. Andrea By: Jeremy Lainé (sharky) 2014-06-27 02:25:21.677-0500 I have tried Joshua's patch against JsSIP for basic call operations and it works fine both with Firefox and Chrome. I have not however tested hold / unhold. By: Virmantas Variakojis (virmis) 2014-06-27 07:21:05.124-0500 Hold/Resume works fine, but if making 5-6 Hold/Resume sound disappears. Wireshark dump shows that Google Chrome side sends DTLS Alert Content Type (21). The situation was managed to repeat few times making 3-4 Hold/Resume, and then Hold call for 2-3 minutes and then Resuming call. OS: Ubuntu Trusty 14.04 openssl: 1.0.1f-1ubuntu2.4 asterisk version: Asterisk SVN-file-sha256-a-harsh-reality-URL:-r417424-/branches/11 sipml5 version 224 By: Joshua C. Colp (jcolp) 2014-06-27 07:31:20.481-0500 According to Doubango they are going to be redoing hold/unhold to use the normal SIP mechanism instead of what they are using now. By: Yuriy Gorlichenko (ovoshlook) 2014-06-30 06:33:50.155-0500 I have one more trouble with this patch. It happens when I do call from webphone (sipml5 or jssip) to some endpoint (softphone). 8 times of 10 Ihave no audio. at rtp log I see only traffic from softphone to asterisk, and to softphone from asterisk. At the start of session I see that one rtp packet sends fron webphone (via ICE), then i see Probation passed - setting RTP source address to <ip where I logged on from webphone>:<port> And then I see only rtp from and to softphone. As I say - It happens not always. Sometimes I have 2 ways rtp packets. (random Lucky???) ICE enabled and stun configured at rtp.conf By: Joshua C. Colp (jcolp) 2014-06-30 08:46:40.268-0500 I would suggest opening a new issue for that. As it is this issue has gotten quite overloaded and despite your problem I'm still going to go ahead and commit the changes in the near future as it has improved things for many people. On the new issue I would suggest providing the console output with rtp debug, as well as a wireshark capture so the STUN traffic can be observed. By: Andrea Suisani (s1ckpig) 2014-07-01 02:01:45.825-0500 Hi Joshua, you've just marked the issue as fixed, does this meant that sha256-a-harsh-reality branch has been merged into asterisk 11? By: capouch (capouch) 2014-07-01 02:09:22.419-0500 It was merged into trunk, as per the code review linked above, beginning with revision 417697. I have built and tested it, and it works just fine. By: Andrea Suisani (s1ckpig) 2014-07-01 02:25:36.412-0500 thanks capouch. the fact is that I wasn't able to find the commit in the 11 branch because revision number was different (DTLS-SRTP SHA-256 support has been added on rev 417676 in the 11 branch) By: Matt Jordan (mjordan) 2014-07-01 06:21:32.537-0500 All bug fixes are always merged into the oldest supported branch that has that bug. In this case, that is Asterisk 11. The 'source' tab in JIRA shows the specific commits for each branch, including team branches. If you scroll the bottom, you'll find the exact commit for Asterisk 11. By: Andrea Suisani (s1ckpig) 2014-07-01 06:53:03.964-0500 Thanks for the info Matt. I didn't know about that. By: Agustí Ubalde (aubalde) 2014-07-01 10:01:50.884-0500 Hi @Matt, I've compiled the branch source (http://svn.asterisk.org/svn/asterisk/branches/11) from the last revision 417704 and it doesn't work. I've had the same errors than before the last patch. Best, By: Joshua C. Colp (jcolp) 2014-07-01 10:08:58.442-0500 This issue is now closed. If you currently have an issue please open a new issue with the Asterisk version, a wireshark capture of an attempt, rtp debug, browser version, sip debug, and a description of what is going on. | ||||||