TRC not ringing

[sebele67]

Hi!

Sometimes noojee will not ring. the GotoIf($[trc${trc-running} = trc]?7) will be valid.

We have two console online at this moment.
We cannot reproduce easily this, it's very randomly.

my context TRC
exten => trc-inbound, 1, answer
exten => trc-inbound, 2, startmusiconhold()
exten => trc-inbound, 3, wait(7)
exten => trc-inbound, 4, GotoIf($[trc${trc-running} = trc]?7)
exten => trc-inbound, 5, wait(23)
exten => trc-inbound, 6, goto(trc-inbound,2)
exten => trc-inbound, 7, goto(ringroups-standard-3,s,1)


Any issue?

[Brett Sutton]

Can you submit the trc.log file from a time just after the error occurs.

Can you also eloborate on what you mean when you say that NJR doesn't 'ring'.
Does the call appear in the 'Line In' list or does it appear but NJR doesn't play the 'ring' sound?

What is your dial plan doing when NJR doesn't ring. i.e. does it drop through to the ringroups-standard-3 context?

How busy is your asterisk server?
We recently had an issue with a very busy asterisk server which dropped the connection to NJR as we weren't process events quickly enough.
The latest version (2.x and 3.x) has code to resolve this issue.

Does this sound like it could be your issue?

[sebele67]

Hello!

The call does not appear, it goes directly to  "ringroups-standard-3".

Below my CLI log
    -- Executing [t@voicemenu-standard-ouvert:1] Goto("SIP/Strasbourg_rbsheberger-000000f3", "trc|trc-inbound|1") in new stack
    -- Goto (trc,trc-inbound,1)
    -- Executing [trc-inbound@trc:1] Answer("SIP/Strasbourg_rbsheberger-000000f3", "") in new stack
    -- Executing [trc-inbound@trc:2] StartMusicOnHold("SIP/Strasbourg_rbsheberger-000000f3", "") in new stack
    -- Started music on hold, class 'default', on SIP/Strasbourg_rbsheberger-000000f3
    -- Executing [trc-inbound@trc:3] Wait("SIP/Strasbourg_rbsheberger-000000f3", "7") in new stack
[Jan  6 17:02:23] WARNING[28299]: mp3/interface.c:215 decodeMP3: Junk at the beginning of frame 49443303
    -- SIP/Strasbourg_rbsheberger-000000f7 answered SIP/1221-000000f6
    -- Executing [trc-inbound@trc:4] GotoIf("SIP/Strasbourg_rbsheberger-000000f3", "1?7") in new stack
    -- Goto (trc,trc-inbound,7)
    -- Executing [trc-inbound@trc:7] Goto("SIP/Strasbourg_rbsheberger-000000f3", "ringroups-standard-3|s|1") in new stack
    -- Goto (ringroups-standard-3,s,1)


Asterisk is not very busy, between 5 and 8 simultaneous calls. It get max to 15-17 simultaneous calls in a day.
I don't think about tcr.log, I will take it today.

I will check the version, we have the 2.26 with the issu for monitoring.

[Brett Sutton]

Looking at the dial plan its looks like NJR is not responding fast enough.
There are a couple of possible causes/solutions.

1. Asterisk is disconnecting due to the NJR not taking events fast enough.
The latest version of NJR (2.26 or 3.0.2) has code specifically designed to deal with this problem. However if the receptionist PC has high CPU utilisation then the PC may be causing the problem. In this case you need to have a look at what is consuming the CPU.  I would need to see a copy of the trc.log to determine if this is the cause.
Given the reported load on your system this shouldn't be an issue.

2. NJR is not responding fast enough
Similar to the above scenario however asterisk is not disconnecting.  Again you need to check your CPU load on the receptionist PC.  Again we need to see the trc.log file to make conclusive statements.
You can help the situation by increasing the first Wait length in the trc-inbound extension. Try four or 5 seconds.
The down side to increasing this value is if NJR is actually no running then callers will have to wait four or 5 seconds before they will be transferred to your group ring.

The short answer is post your logs and then we can do some diagnosis.

[sebele67]

Hi!

I have new information.

We have two receptionnist, when One go out she activate leave. The second take all calls and vice versa.

Past this fonction work great, yet it go out..

I put you trc.log and the profile

[Brett Sutton]

Sebele67,
I'm having a little trouble understanding your latest post.

Can you please confirm.

1. You are occasionally having a problem where by calls are not ringing on NJR.
2. You where initially not able to reproduce the problem.
3. After some further research you have found that the problem occurs when one of your two receptionist places the NJR into Unattended/Vacant mode.

Is that correct or is your latest post a completely separate issue?

[sebele67]

For answer,

1. Yes, but I think it's related to point 3
2. Yes
3. Yes

[Brett Sutton]

OK, I will set up a test system and see if we can reproduce the problem.

[sebele67]

Hi !

Any news about this?

[Brett Sutton]

not as yet. So far we have not been able to reproduce the problem in the lab.

We are looking at some other methods of identifying what is going on.

[sebele67]

Hi !

I have seen that when one of receptionist close TRC the calls after that will jump out.
The last receptionist will restart their TRC and work it again.

I hop this will help you

[Brett Sutton]

Can you provide some more clarity on the phrase 'jump out'.
What exactly is happening to the call when the receptionist closes Noojee Receptionist?

As I understand the second part of your post; 'If both receptionists such down the console and restart then the can once again answer calls'.

Is this correct?

So does this mean that the problem happens for both receptionist simultaneously?

[sebele67]

jump out mean that the call go to the priority 7 of my dialplan
exten => trc-inbound, 1, answer
exten => trc-inbound, 2, startmusiconhold()
exten => trc-inbound, 3, wait(7)
exten => trc-inbound, 4, GotoIf($[trc${trc-running} = trc]?7)
exten => trc-inbound, 5, wait(23)
exten => trc-inbound, 6, goto(trc-inbound,2)
exten => trc-inbound, 7, goto(ringroups-standard-3,s,1)


For the second part, not the both but the latest receptionist.

I reexplain when the first close TRC, the next incoming calls go to priority 7. The workaround is to restart the second TRC.

When the both TRC running there is no problem.

[Brett Sutton]

OK, just to confirm.

If both consoles are running everything works OK.

If you start both consoles up and then shut just either one of them down then the dialplan jumps to extension 7?

If you start both consoles up and then put either one into unattended mode  then the dialplan jumps to extension 7?

Can you confirm that both console work properly if they are the only console running?
i.e. start one console check it is working ok. Shut the first console down. Start the second console and check that it works ok.

I will try and reproduce the above here, but if you can confirm that this is the scenario that will help ensure we fix the right bug

[sebele67]

I can confirm you that,

if the both run everything is ok.

when I shut one it's jump to extension 7.

When I put either one into unattended mode it's depending who has launch first. If I put the first opening It does not jump, If I put the second it's jump.. I will confirm you this on monday.

If only one console run all it's ok.

thanks for your help to debug this.