Long delay btw busy extension is detected and the caller hearing the busy tone

General Help
1

When an outside party calls one of our extensions (DID) that happens to be busy at that moment, than many seconds (sometimes more than 30sec) pass from the time Asterisk declares the extension busy to the moment the caller hears the busy tone.

What is the reason of it and, more important, is there a way for that delay to be shortened?

Thanks for your help.

Find hereafter Asterisk log excerpt.

-- Executing [s-BUSY@macro-exten-vm:1] NoOp("DAHDI/12-1", "Extension is reporting BUSY and not passing to Voicemail") in new stack
-- Executing [s-BUSY@macro-exten-vm:2] GotoIf("DAHDI/12-1", "0?exit|1") in new stack
-- Executing [s-BUSY@macro-exten-vm:3] PlayTones("DAHDI/12-1", "busy") in new stack
-- Executing [s-BUSY@macro-exten-vm:4] Busy("DAHDI/12-1", "20") in new stack
        .
        .

… many seconds of silence to the caller party …
.
.
== Spawn extension (macro-exten-vm, s-BUSY, 4) exited non-zero on ‘DAHDI/12-1’ in macro ‘exten-vm’
== Spawn extension (from-did-direct, 9278, 1) exited non-zero on ‘DAHDI/12-1’
– Hungup ‘DAHDI/12-1’
|
|
V
… Now the caller hears the BUSY tone

2

Looking at the console log it seems to me that the period of silence should have been filled with the busy tone provided by the running of the <PlayTones(“DAHDI/12-1”, “busy”)> command until the TSP switch takes over providing itself the BUSY tone.

So, the question for me is: “What is preventing the busy tone, which apparently is generated, from reaching the caller’s end?”

3

Forgotten to say FreePBX 2.5.2-8

4

A bit more more of info.

If for any reason the extension is unavailable and the Asterisk logic declares it a CONGESTION, then the related tone is played to and heard by the caller.

-- Executing [s-CHANUNAVAIL@macro-exten-vm:1] NoOp("DAHDI/9-1", "IVR_RETVM:  IVR_CONTEXT: ivr-3") in new stack
-- Executing [s-CHANUNAVAIL@macro-exten-vm:2] GotoIf("DAHDI/9-1", "0?exit|1") in new stack
-- Executing [s-CHANUNAVAIL@macro-exten-vm:3] PlayTones("DAHDI/9-1", "congestion") in new stack
-- Executing [s-CHANUNAVAIL@macro-exten-vm:4] Congestion("DAHDI/9-1", "10") in new stack
5

you can read it here :
http://www.elastix.org/index.php/en/component/kunena/29-announcements/104253-elastix-22-call-waiting-problem.html#104401
I guess in Elastix, DAHDI can not send Busy tone on signaling level to telco.

6

Well, I do not agree. If it is able to send the CONGESTION tone using application PlayTones, why shouldn’t be able to send the BUSY tone using the sam application and the same channel/trunk type?

I think that should give the hint to developers to find out the cause of the issue.

The only sad thing is that nobody seems to consider it important enough to have a look at it.

7

FreePBX 2.5 is very old and not supported.

8

Fair enough. Then, if your allusion to 2.5’s age means that it has been fixed in the new version, would it take too much to tell us what the pb was/is?

Not everybody can afford to upgrade at current rate of development.
Some advise where to look at instead may help us find, devise, invent whatever solution and patch we can afford.
Thanks for your understanding.

9

This is probably not even a FreePBX issue so I can’t even address it unless you are on a supported version.

I don’t understand the “afford to upgrade”, it’s free. If you are running DAHDI you have at lease a halfway current version of Asterisk.

I really doubt you have found a bug, more likely some type of signaling issue on the analog side.

10

Actually I just reread the post. More than likely you have call waiting set so the delay is actually the ringing. Maybe you are missing progress inband or a setting that enables telco ringback.

On some telco channels you have to answer the channel and play ringing tone.

You also have the “signal ringing” option on the inbound route that may come into play in this scenario.

11

Thanks for your list of possible mis-configuration to explore, but perhaps you missed the entry where I stated that when in the instance where CONGESTION must be played, then it is heard, while where BUSY tone is required it is not?

Forgive me if I stress the point, but please bear with me since I believe it could be worth it.

From the TSP perspective, and the caller with it, the two situations are absoloutely equivalent: it’s Asterisk that decides (for two different reasons, we agree) that the call can not be completed and it is still Asterisk that decide what to do next.

Now, what make Asterisk accomplish along one coding path what it doesn’t seem to be able to accomplish along the other coding path?

12

I’m writing this in the hope that it can help other people.

At first I tried by setting “callwaiting=no” in chan_dahdi.conf.
That did not really help - with its value set to “yes” an external call hitting an already busy extension would still be bridged through, should the extension become available before timeout, whereas with value set to “no” the external call will get the BUSY tone after timeout expires.
In both cases the caller is met only with silence till timeout expires.

The solution was to check the SIGNAL RINGING box for each of the inbound routes leading to an extension - an external call hitting an already busy extension will get immediately the ringing tone untill the timeout expires and the BUSY tone after that.

In my opinion the comment associated to the SIGNAL RINGING box, as formulated in 2.5, doesn’t seem to include the case discussed herein.

13

So it’s exactly what I said it was. Congestion is a tone that requires RTP where busy can be generated by CPE. Progress inband changes this.

I don’t want to rub your face in it, but you seemed more interested in telling us what we did not know than listening to the solution.

14

I’m sure you’ll agree with me the important thing in all this is always the bettering of the product as well as improving its knowledge amongst the crowd out there.
By the way… again many thanks for your unfatigable dedication to the cause.