[SOLVED] CDR Logging No Answer/Busy twice

Asterisk Asterisk Support
1

I hope someone can help / confirm this is a bug I need to raise.

Asterisk Setup:
[ul]PSTN <–E1–> Asterisk <–E1–> Phone System[/ul]

Versions:
[ul]Asterisk = 1.4.17
Zaptel = 1.4.8
Libpri = 1.4.3[/ul]
*dont really want to upgrade to 1.4.21.1 considering all the recording issues, but may give that a try if all else fails.

Scenario:
[ul]Accepting overlap dial, outbound from Phone System.
Appears that Asterisk finds a free channel Zap/3 (before overlap finished)
New Call comes inbound from PSTN on Zap/3
Overlap finishes and attempts to dial on Zap/3 and fails with Busy
Both calls get hung up.
[/ul]

This is a pretty big problem at one of our very busy sites.

Possible solutions I have thought of are:

[ul]Changing the outbound E1 card to grab the highest available channel rather than the lowest but this isnt perfect as A) it breaks my channel usage graph :smile: and B) Chance of the bug appearing if all the channels become used.
Or I am testing a more restricted dialplan pattern matching in the attempt to be able to turn off overlap dialling. But I’m not hopeful, will update when am able to test.
[/ul]

Thanks for any help / suggestions.

Alex

2

Thinking more about it what I’ve said has to be rubbish.

The Asterisk cant find a free channel before issueing the Dial command else how would it know what tech/span to use.

Setting the Zap card to use the highest available channel doesnt seem to have helped either.

I guess this is a CDR logging issue, tho I’m very confused as the callerid’s are different.

CDR (sorry if this looks awful I’m not allowed to attach files, should be able to copy paste into excel):

“calldate”,“clid”,“src”,“dst”,“dcontext”,“channel”,“dstchannel”,“lastapp”,“lastdata”,“duration”,“billsec”,“disposition”,“amaflags”,“accountcode”,“uniqueid”,“userfield”,“user_id”,“reviewdate”,“score”,“comment”,“grade”,“callid”
“2008-07-22 08:31:15”,“7020”,“7020”,“13201372400000”,“from-inside”,“Zap/45-1”,“Zap/2-1”,“Dial”,“Zap/g1/13201372400000|300|tTo”,“30”,“0”,“NO ANSWER”,“3”,“22072008-083122-13201372400000-OUT^”,“0”,“0000-00-00 00:00:00”,NULL,“0”,"123803"

“2008-07-22 08:31:22”,“07831475000”,“07831475000”,“s”,“from-outside”,“Zap/2-1”,“23”,“0”,“NO ANSWER”,“3”,“0”,“0000-00-00 00:00:00”,NULL,“0”,“123802”

3

Hi

What does the dialplan looklike? I have sites tandaming calls via e1 and asterisk with no issues.

Personaly I wouldnt use overlap dialing but once the channel is reserved with the ISRM-I then no callers would hit it from the pstn.

I would expect two call IDS as they are two calls.

options are see what the pri debug looks like or use as e1 testset and see whats going on

are the channel maps correct ? IE if they have 8 channels 8 are configured on each pipe.

Ian
www.cyber-cottage.co.uk

4

I visited the site this morning and I have stumbled on the issue.

The issue is simply with the CDR logging.

Call comes in on Zap/3-1 caller id 123456.

Call goes out on Zap/3-1 BUT the call is either not answered OR busy.
Two CDR records get created, one correct record (no answer/busy) and then another with the caller id of 123456 extension “s” and a seemingly random duration and billsec of zero.

*repeatedly make outgoing calls and each time the extra record caller id is 123456 until another call comes in on Zap/3-1.

If the call connects then no extra CDR record is created.

Apart from the CDR the calls process correctly. Panic over as appears to just be a CDR issue :smile:

Will see if there is a newer asterisk-addons and try again

5

Hi

Its very hard to say whats happening without CLI output and dialplan.

what you describe is normal for many instances but with nothing to go on its hard to say.

what do the raw cdr records look like as well?

Ian

6

Late last night I upgraded the server to the latest versions of Asterisk 1.4.21.2 / Zaptel 1.4.11 and so far there has been no extra CDR “s” records.

Which is very good as I’m pretty sure there is no good reason for Asterisk logging an extra CDR record for outbound calls that end in “No answer”/ “Busy” with a src of the caller id of the last inbound call on that Zap channel and a dst of “s”.

Hopefully a better explaination in case anyone else sees this issue

Note: ALL BELOW ARE FOR A SINGLE ZAP CHANNEL! You may have other calls mixed in that makes this bug hard to spot.

Call Flow:
time: 1, IN, callerid 1234, Success
time: 2, OUT, callerid 600, No Answer
time: 3, OUT, callerid 600, Busy
time: 4, IN, callerid 5678, Success
time: 5, OUT, callerid 600, No Answer

CDR:
time: 1, IN, src 1234, dst x, Success
time: 2, OUT, src 600, dst x, No Answer
time: 2, IN, src 1234, dst s, No Answer
time: 3, OUT, src 600, dst x, Busy
time: 3, IN, src 1234, dst s, Busy
time: 4, IN, src 5678, dst x, Success
time: 5, OUT, src 600, dst x, No Answer
time: 5, IN, src 5678, dst s, No Answer

Anyways, thanks for the help.

Alex