[asterisk-dev] [Code Review]: Add bridge tests to check transfer capabilites

[opticron]

> On Feb. 8, 2013, 3:48 p.m., jrose wrote:
> > I think this miiiiight need a little work.
> > 
> > Still needs CDR generation. I was under the impression that we figured out that your problem just stemmed from something silly like configs being copied from your /etc/asterisk directory... (which is a problem with the testsuite, but easy enough to work around) or am I just bonkers? I'm getting CDRs from this, but I'm only getting them for one call.  Going by the yaml, it looks like there are four sepearte calls in the bridge-config.
> > 
> > Looking through your CEL expectations though, that makes sense.  You only have one LINKEDID_END in there, which I think would imply that you only wrote up CEL logs for one of the four calls I'd expect.
> > 
> > I received this failure from the CEL log.
> > [Feb 08 15:37:59] WARNING[26102]: TestCase:363 __reactor_timeout: Reactor timeout: '30' seconds
> > [Feb 08 15:38:04] WARNING[26102]: astcsv:64 match: CSV MATCH FAILED, Expected: eventextra: '16,,' Got: eventextra: '16,SIP/bob-00000001,'
> > [Feb 08 15:38:04] WARNING[26102]: astcsv:185 match: Failed to match entry 7
> > 
> > Checking the CEL logs everything appeared in order aside from that one mismatch. I'm not quite sure why the reactor is timing out, but I suspect the call isn't being hung up properly after the transfer, so the bridge module never moves on past the first call.  I don't really know why this would be passing on your end if that's the case though. This seems really weird.

Interesting, this functioned flawlessly several times on my machine before I put it on reviewboard.  After many further runs and some debug log inspection, there appears to be race condition in the DTMF queueing code such that a received DTMF end event (digit 2) is never emitted to Bob under the conditions on my test dev machine.  Fortunately it happens quite consistently on the first call on my machine, but appears to happen sporadically on the other calls as well if the test makes it past the first call.


- opticron


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


On Jan. 23, 2013, 1:15 p.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2268/
> -----------------------------------------------------------
> 
> (Updated Jan. 23, 2013, 1:15 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Test blind and attended transfers from Alice and Bob to ensure that the "T" and "t" options allow the correct parties to perform transfers when used from the Dial application and from BRIDGE_FEATURES.
> 
> 
> This addresses bug SWP-5268.
>     https://issues.asterisk.org/jira/browse/SWP-5268
> 
> 
> Diffs
> -----
> 
>   asterisk/trunk/tests/bridge/tests.yaml 3617 
>   asterisk/trunk/tests/bridge/transfer_capabilities/configs/ast1/extensions.conf PRE-CREATION 
>   asterisk/trunk/tests/bridge/transfer_capabilities/test-config.yaml PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/2268/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> opticron
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130215/15c36fa7/attachment.htm>