| Summary: | ASTERISK-20194: SRTP: after hold action no audio on holded peer. | ||||||||
| Reporter: | Nicolò Mazzon (nmazzon) | Labels: | |||||||
| Date Opened: | 2012-08-06 04:41:46 | Date Closed: | 2012-09-13 16:19:49 | ||||||
| Priority: | Critical | Regression? | Yes | ||||||
| Status: | Closed/Complete | Components: | Resources/res_srtp | ||||||
| Versions: | 1.8.13.1 1.8.14.0 1.8.15.0 | Frequency of Occurrence | Constant | ||||||
| Related Issues: |
| ||||||||
| Environment: | Linux Centos 5.7 | Attachments: | ( 0) config.txt ( 1) dump_srtp.zip.001 ( 2) dump_srtp.zip.002 ( 3) dump_srtp.zip.003 ( 4) file.zip.001 ( 5) file.zip.002 ( 6) file.zip.003 ( 7) file.zip.004 ( 8) file.zip.005 ( 9) full.log (10) full.log (11) full.tmp (12) sip_trace.pcap (13) siptrace.pcap (14) srtp_patches.diff | ||||||
| Description: | On a call with SRTP after peer hold another and unhold, the holded peer does not hear anything, the holder peer continue to hear audio call. This happens after 10-15 minutes of conversation. We verified this every time with version from version 1.8.13. Instead 1.8.12 works ok. We made many tests with different phone models (SNOM, Polycom, Yealink) and issue occured every time. We attach our configuration and log. Log level is verbose = 12 and debug = 12. This is the scenario: ||action||hour|| |2209 call 2210| 10.43| |2210 answer|| |2210 hold|11.00| |2210 unhold|11.01| |2209 no audio|| |2209 hangup up|11.02| | ||||||||
| Comments: | By: Nicolò Mazzon (nmazzon) 2012-08-06 04:42:49.652-0500 system configuration By: Nicolò Mazzon (nmazzon) 2012-08-06 04:44:12.298-0500 full log from asterisk By: Nicolò Mazzon (nmazzon) 2012-08-06 04:48:33.669-0500 sip trace By: Matt Jordan (mjordan) 2012-08-06 08:43:32.969-0500 The SIP pcap doesn't illustrate the scenario you're describing. It shows the initial call set up between Asterisk and a single endpoint, as well as a single re-INVITE. In that re-INVITE, however, the media flow is not restricted, which I would expect if the call was being put on hold. If you can, please reproduce the scenario. Include a DEBUG 5 log, with 'sip set debug on' as well. By: Nicolò Mazzon (nmazzon) 2012-08-08 03:35:49.521-0500 I retrieved the log, sorry if it was incomplete By: Nicolò Mazzon (nmazzon) 2012-08-08 03:36:08.275-0500 new full log By: Nicolò Mazzon (nmazzon) 2012-08-08 03:36:23.150-0500 new file siptrace By: Matt Jordan (mjordan) 2012-08-08 15:44:35.527-0500 The logs here are rather confusing. In the SIP pcap trace, the UA in question sends the same crypto key in the INVITE requests. There is nothing wrong with this - doing so merely causes Asterisk to reload the same policy that it previously had esablished for that SSRC. Immediately after taking the call off of hold, however, the RTP packet unauthenticates fail. This would imply one of two things: 1) The UA is not honoring the key it sent us 2) The UA has changed the SSRC in the RTP stream What I can't see from the pcaps is whether or not the second condition is the case. Can you include a pcap that also includes the RTCP/SRTP packets? That will let me know whether or not the second case is the cause of this. By: Nicolò Mazzon (nmazzon) 2012-08-09 01:48:15.254-0500 I send you the file with the SRTP stream, are in multiple rows because the bug can be reproduced only after 10-15 minutes of talk time. The bug occurs only from version 13 onwards when it was introduced the ability to change key on SIP / SRTP. The bug is easily reproducible with the most popular ip-phone (SNOM, Polycom and Yealink). If you need more information tell me as well. By: Nicolò Mazzon (nmazzon) 2012-08-09 01:54:58.962-0500 SIP/SRTP trace file 1 By: Nicolò Mazzon (nmazzon) 2012-08-09 01:57:25.304-0500 SIP/SRTP trace file 2 By: Nicolò Mazzon (nmazzon) 2012-08-09 01:59:55.139-0500 SIP/SRTP trace file 3 By: Nicolò Mazzon (nmazzon) 2012-08-09 02:00:55.435-0500 SIP/SRTP trace file 4 By: Nicolò Mazzon (nmazzon) 2012-08-09 02:03:16.956-0500 SIP/SRTP trace file 5 By: Matt Jordan (mjordan) 2012-08-09 15:17:50.797-0500 Well, I haven't been able to reproduce this problem using a SNOM 820. Hold / unhold / attended transfers / blind transfers - so far, in all cases, I've been unable to reproduce what your DEBUG log does show. What format are the files you've attached in? I've been unable to open them using archive manager on a Fedora 15 machine. By: Nicolò Mazzon (nmazzon) 2012-08-10 07:54:03.199-0500 the first file was corrupted, I'm reloading it.. By: Nicolò Mazzon (nmazzon) 2012-08-10 08:59:07.250-0500 we remade test and put new log, if can help. 2210 called 2212 after 12 minutes 2210 holded 2212 and then unholded. 2212 did not hear anything. By: Nicolò Mazzon (nmazzon) 2012-08-10 08:59:49.070-0500 full log By: Nicolò Mazzon (nmazzon) 2012-08-10 09:01:02.994-0500 file 1 By: Nicolò Mazzon (nmazzon) 2012-08-10 09:03:35.936-0500 file 2 By: Nicolò Mazzon (nmazzon) 2012-08-10 09:04:45.999-0500 file 3 By: Matt Jordan (mjordan) 2012-08-15 09:39:23.211-0500 Well, it looks like the SNOM phone does not change the SSRC, which is good. Unfortunately, I haven't been able to reproduce the issue using the SNOM 820, despite leaving it on hold for an extended period of time, transferring things after an extended period of time, and generally attempting to confuse the SRTP session. In my last test I left the phone on hold for 30 minutes without reproducing this. What SNOM phone are you testing with, and with what firmware? By: Nicolò Mazzon (nmazzon) 2012-08-20 02:10:56.463-0500 We reproduced bug with many SNOM phone (300,320,370,821,870). Maybe I explained wrong, A calls B, converse for 10-15 minutes, B put on hold, even a little, 5-10 seconds and then A does not hear anything. It 'independent of what is put on hold. By: Matt Jordan (mjordan) 2012-09-04 13:33:30.150-0500 So, I did a lot of testing with a snom 320 and an Aastra phone that I was able to procure. Unfortunately, I still wasn't able to reproduce your issue - I tried having a conversation for 10-15 min, put either UA on hold, took them off hold, etc. - and never had one way audio that duplicated your SIP traces and/or DEBUG logs. That being said, in my testing, I did discover some other issues with SRTP that made it difficult for either the Aastra or the snom 320 to work properly. This included some negotiation issues with the snom 320, where we wouldn't process a request that wasn't SAVP, and where we responded with a policy suite that was different than the one we had applied for the UA. The attached patch includes those changes, as well as another. One of the things that was changed in recent versions was the ability to have Asterisk actually handle the keys changing after a hold or transfer; however, the mechanism employed to do that applied to any re-INVITE, regardless of whether the key changed. The attached patch caches the remote key value and only resets the crypto policy if the key has changed. Taken together, this may - or may not - resolve the problem you're seeing. If you could test it out, however, I'd appreciate it. By: Matt Jordan (mjordan) 2012-09-04 14:17:31.425-0500 One other question: what firmware are you using in your SNOM phones where this behavior can be reproduced? By: Nicolò Mazzon (nmazzon) 2012-09-06 02:09:32.675-0500 We tried your patch and it seems to fix the bug. Now we will apply it to our production system and make other stress tests. 'll let you know the outcome.. Anyhow our SNOM firmware version is 8.4.32, Polycom 4.0.2. By: Matt Jordan (mjordan) 2012-09-10 14:14:32.225-0500 Any feedback from your testing on your production systems? By: Matt Jordan (mjordan) 2012-09-13 16:19:33.272-0500 I'm going to go ahead and close this out, as we committed this patch for 1.8.16.0. If you continue to have any problems, please contact me in #asterisk-bugs or on the asterisk-bugs mailing list and we'll reopen this issue. Thanks! By: Nicolò Mazzon (nmazzon) 2012-09-14 01:15:34.349-0500 The tests went well! Today I was going to give you feedback .. Everything ok, we also tested the phones Yealink. Bye By: Dario Busso (barbabus) 2012-09-25 04:37:52.741-0500 I'm still having some problems with the 10.9.0.rc1: have you committed in this rc this patch?! Regards. Dario By: Matt Jordan (mjordan) 2012-09-25 08:17:15.079-0500 Patches are committed to the various branches, not to release candidates. As the 10.9.0-rc1 was created after this patch was committed, it contains this patch. You can also see this in the release summary for the release candidate. If you are still seeing a problem with SRTP, please open a new issue. Attach DEBUG with 'sip set debug on' logs, your sip.conf, and a pcap illustrating the problem. Please also indicate the model of phones you are using. Even if the symptoms are similar, the actual problem may not be the same. | ||||||||