[asterisk-dev] [Code Review] External test for detecting RFC 2833 DTMF digits

Wed Mar 17 10:23:52 CDT 2010

> On 2010-03-16 15:00:17, Russell Bryant wrote:
> > I'm neither a lua or sipp expert, so other reviews would be good here.  I get the general idea of what this test is doing, though, and this test looks extremely awesome.  :-)
> > 
> > Nice work, Mark!
> 
> Russell Bryant wrote:
>     I guess I may have gotten too excited and ahead of myself.  Based on your description, I guess we need to figure out the 488 issue before this goes in.

The 488 thing is really weird, and unfortunately it's a bit of a heisenbug. There was a time when I was getting the 488 response every time I ran my test. However, if I ran an individual sipp scenario against a manually-started Asterisk instance, I'd never see the issue. Now, after tweaking test parameters and executing some svn updates in trunk, I see the 488 maybe once every 20 times I run the test. Strangely, the 488 seems most likely to happen after updating and recompiling Asterisk. After the initial 488, the test will pass every single time.

Logging is a bit sketchy when using asttest, and I'm not 100% sure why that is. When I've tried to check the logs for warnings and errors when I encounter the 488, the messages that appear in the "messages" file are only the messages that appear at startup. The messages that should have been logged during the test do not appear in the log.

I have a hypothesis regarding why the problem occurs, although I'm not sure how viable this is. It may be that I need to insert a longer pause after starting up Asterisk before attempting to run any of my test scenarios. I may be seeing a problem where Asterisk is in a partially-loaded state (e.g. chan_sip is loaded but res_rtp_asterisk is not). After rebuilding Asterisk, startup may take longer due to the unavailability of cached data. I am going to insert a longer pause into my test script and run it a lot, specifically after rebuilding Asterisk. If the 488 problem seems to have gone away, I'll report back here.

- Mark

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/560/#review1685
-----------------------------------------------------------

On 2010-03-16 17:27:37, Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/560/
> -----------------------------------------------------------
> 
> (Updated 2010-03-16 17:27:37)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> The test does what the summary states. For details on the specific tests run, see the attached test-config.yaml file.
> 
> There are three test cases run. In each, SIPp is used to place a call to Asterisk, playback one or multiple pcap files and then send a BYE. The test.lua script is set to run a handler for each VarSet manager event that is received. In the handler, we compare the received DTMF digits to what we expected to receive and fail if there is a discrepancy.
> 
> The pcap files that I used for playing DTMF could not be attached, so I will include a brief description of them here:
> 
> dtmf_2833_*.pcap: These are the RFC2833 DTMF pcap files included in the distribution of SIPp. Strangely, they do not include a '0' DTMF digit.
> dtmf_2833_*_noend.pcap: These are generated from the original DTMF pcap files by chopping off the end frames.
> broken_dtmf.pcap: This is a series of digits that was collected from the reporter of Mantis issue 15811 who was having a problem with duplicate DTMF being detected. The quirk with the DTMF here is that there are out-of-order frames received.
> 
> Note that the second and third tests will not pass without the patch from review 558 applied.
> 
> EDIT: I forgot to thank Matt Nicholson in this review for writing the asttest framework that I used for writing this test. His example tests and sipp scenarios were a big help in getting this written.
> 
> 
> Diffs
> -----
> 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/configs/extensions.conf PRE-CREATION 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/configs/sip.conf PRE-CREATION 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/run-test PRE-CREATION 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/broken_dtmf.pcap UNKNOWN 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/broken_dtmf.xml PRE-CREATION 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/dtmf_2833_1.pcap UNKNOWN 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/dtmf_2833_1_noend.pcap UNKNOWN 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/dtmf_2833_2.pcap UNKNOWN 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/dtmf_2833_2_noend.pcap UNKNOWN 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/dtmf_2833_3.pcap UNKNOWN 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/dtmf_2833_3_noend.pcap UNKNOWN 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/dtmf_2833_4.pcap UNKNOWN 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/dtmf_2833_4_noend.pcap UNKNOWN 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/dtmf_2833_5.pcap UNKNOWN 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/dtmf_2833_6.pcap UNKNOWN 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/dtmf_2833_7.pcap UNKNOWN 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/dtmf_2833_8.pcap UNKNOWN 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/dtmf_2833_9.pcap UNKNOWN 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/dtmf_2833_pound.pcap UNKNOWN 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/dtmf_2833_star.pcap UNKNOWN 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/dtmf_baseline.xml PRE-CREATION 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/dtmf_noend.xml PRE-CREATION 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/sipp/register.xml PRE-CREATION 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/test-config.yaml PRE-CREATION 
>   /asterisk/trunk/tests/rfc2833_dtmf_detect/test.lua PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/560/diff
> 
> 
> Testing
> -------
> 
> I've run the tests and have made sure that DTMF is detected as expected. There are some times when I will run the tests that Asterisk will send a 488 in response to the initial INVITE. I have not yet concluded why it happens, though.
> 
> For the tests, I was using SIPp trunk. Initially, I did this because I was using features that were not present in earlier versions of SIPp. However, I later removed those options from the test but continued using SIPp trunk instead of a released version. I suspect that using SIPp 3.1 would suffice for this test, but I am not certain about that.
> 
> 
> Thanks,
> 
> Mark
> 
>