Getting dead air

[Jeremiah8]

We have an IP Office 406 V2 running the 4.0 software. I know this is just GA not Maint. Release, but I was wondering if anyone else was having this problem.

We have 7 analog phone lines. What I'm seeing is that when 6 lines are in use, on calls or queued up, when a 7th person calls in, it rings several times for them then goes to dead air. Usually the caller hangs up.

I have traced it to one of the analog ports. When I run the Monitor program I get the following lines:
(I've removed the caller ID and caller number from the log)

CALL:2007/03/1411:51,00:06:56,005,##########,I,300,,<Lastname>,<First Name>,,,1,,""n/a,0

Here's the long version

164573431mS ERR: TFTP Write:: Too many retries (from 192.168.0.38, 49603) file=nasystem
164573882mS RES: Wed 14/3/2007 11:58:46 FreeMem=42654096(462) CMMsg=7 (7) Buff=100 587 489 1092 2 Links=8437
164576810mS CMCallEvt: 409.12.1 1163 Alog Trunk:409: StateChange: END=A CMCSConnected->CMCSCompleted
164576817mS CMLOGGING: CALL:2007/03/1411:51,00:06:56,005,##########,I,300,,<Lastname>,<First Name>,,,1,,""n/a,0
164576830mS CMCallEvt: 0.9628.0 1163 ACDTep(PDX Tech): StateChange: END=??? CMCSRinging->CMCSDelete
164576831mS CMCallEvt: 0.9628.0 -1 BaseEP: DELETE CMEndpoint fe887e08 TOTAL NOW=1223 CALL_LIST=5
164576832mS CMCallEvt: 409.12.1 -1 Alog Trunk:409: StateChange: END=X CMCSCompleted->CMCSDelete
164576834mS CMCallEvt: 0.9667.0 -1 BaseEP: DELETE CMEndpoint fe88508c TOTAL NOW=1222 CALL_LIST=5
164576841mS CMCallEvt: 0.9653.0 -1 Extn201.0: StateChange: END=X CMCSRinging->CMCSCompleted
164576842mS CMCallEvt: 0.9653.0 -1 Extn201.-1: StateChange: END=X CMCSCompleted->CMCSDelete
164576844mS CMCallEvt: 0.9653.0 -1 BaseEP: DELETE CMEndpoint feb4b2a4 TOTAL NOW=1221 CALL_LIST=5
164576844mS CMCallEvt: END CALL:1163
164576852mS CMCallEvt: 409.12.1 -1 BaseEP: DELETE CMEndpoint fe8c71ac TOTAL NOW=1220 CALL_LIST=5
164583122mS CMCallEvt: 0.9668.0 1165 MHigbie.0: StateChange: END=T CMCSRinging->CMCSConnReq
164583123mS CMCallEvt: 0.9665.0 1165 TargetingEP: RequestEnd 0.9668.0 1165 MHigbie.0
164583124mS CMLOGGING: CALL:2007/03/1411:02,00:54:52,000,,O,,,,,,0,,""n/a,0
164583127mS CMCallEvt: 0.9098.0 1098 ACDTep(PDX Tech:SYNC:2): StateChange: END=??? CMCSIdle->CMCSDelete
164583128mS CMCallEvt: 0.9098.0 -1 BaseEP: DELETE CMEndpoint fe929910 TOTAL NOW=1219 CALL_LIST=4
164583129mS CMCallEvt: 0.9666.0 -1 BaseEP: DELETE CMEndpoint fe889e34 TOTAL NOW=1218 CALL_LIST=4
164583130mS CMCallEvt: END CALL:1098
164583139mS CMCallEvt: 0.9096.0 -1 BaseEP: DELETE CMEndpoint fe95a950 TOTAL NOW=1217 CALL_LIST=4
164583141mS CMCallEvt: 0.9656.0 1165 ACDTep(PDX Tech): StateChange: END=??? CMCSRinging->CMCSDelete
164583143mS CMCallEvt: 0.9656.0 -1 BaseEP: DELETE CMEndpoint fe897634 TOTAL NOW=1216 CALL_LIST=4
164583144mS CMCallEvt: 0.9665.0 -1 BaseEP: DELETE CMEndpoint fe932468 TOTAL NOW=1215 CALL_LIST=4
164583147mS CMCallEvt: 0.9668.0 1165 MHigbie.0: StateChange: END=B CMCSConnReq->CMCSConnected
164583381mS RES: Wed 14/3/2007 11:58:56 FreeMem=42708640(511) CMMsg=7 (7) Buff=100 584 484 1089 2 Links=8461
164583810mS H323Evt: Recv: RegistrationRequest c0a800f8; Endpoints registered: 4; Endpoints in registration: 0
164584964mS PRN: Config Write Wake Up
164585464mS PRN: IO List Size 1
164585464mS PRN: Sending Config out to feb4bcc8 started
164585465mS PRN: Start WriteConfig at fed793c8 savemode 0 writetype 2

 

[gknight1]

how many ports of voicemail do you have? how many people are using voicemail ports when this is happening. I think if someone is in queue then they are using a voicemail port. It sounds like you have your voicemail maxed out.

 

[Jeremiah8]

I have 4 voicemail ports, however I have the system set to sync the calls so it uses less ports.

J.

 

[gknight1]

if you are 4.0 you should be able to use SSA to tell you what is going wrong...if you are maxing out your voicemail ports, trunks are droping, etc.

 

[Jeremiah8]

gknight1,
What exactly is SSA?

J.

 

[gknight1]

System Status Application

It replaces call status in 4.0.

It show everythings from port usage, trunks usage, who is one what phones, etc... its almost like a call status and monitor in one, but it is much easier to read than monitor and it goes a lot more in depth than call status.

 

[Jeremiah8]

gknight1,
Gotcha. I have been watching that app. I only see two alerts:

1. It can't find the license server on 255.255.255.255. I use the serial dongle connected to the back of the unit.

2. It can't connect an outgoing call due to all lines being tied up.

J.

 

[DJRabin]

Have you verified that line 7 is a member of the same line group ID and that the incoming call route is set up the same (or similarly) for all of the lines?

Also, if you're not getting a valid license for VMPro, then your auto attendant or VM would give you dead air after the temporary license ran out (two hours). You can restart VMPro services to see if this might be the issue.

You can check in your configuration, the dongle should show up as "local" on the system tab instead of showing a license server.

 

[Jeremiah8]

DJRabin,
Here are the answers:
1. Line 7 (as with all of these 7 lines) are set to line group ID of 0. I've read that some people have had problems with this, and others didn't.

2. The VMPro is saying that the license is valid. Other people in queue are hearing announcements, etc. Restarting VMPro Services doesn't fix the problem

3. It is showing as local on the tab.

J.

 

[tlpeter]

but what doe ssa say about the voicemail ports ?
are the maxed out (it tells you)


______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[aarenot]

7 Lines
Using queues
4 VM ports


Here are my suggestions.

1) Turn on VM to EM, and set to forward, so that the VMB does not hold the message. This will stop people from using one of the four ports to check their VM.

Or,
2) Add more VM ports.


With the given info., it appears that the VM Ports are busy, and you may need to add more ports. 4 ports is really a minimum number for general usage. When you add queueing, I would almost always suggest additional ports. You subtract the total number of people you constantly have on duty to answer the calls in que, from the total number of lines. Then add the highest possible number of people who may be checking their VM at one time to that number. That is how many VM ports you should have on your system, unless dead air is acceptable to your customer.

 

[Jeremiah8]

tlpeter,
I'm not getting any messages with regards to running out of VM ports. I had initially added the license incorrectly and saw the messages stating that I was out of VM ports, however fixing the license fixed that issue.

aarenot,
I don't think this is an issue with regards to the VM ports. I agree, this does look like it. However this happens when I have 5 people actively on calls and 2 more call in. None of the users are set to use their own VM boxes, so I know that they aren't using VM ports to check VM. Also this only happened since we switched to 4.0.

J.

 

[aarenot]

Re-produce the scenario, when you get dead air on the incoming call, grab a system phone, and dial *17 to see if VM will answer properly. If it does, look at your phone lines, system ground, ICR's, is VMPRO connected via IPO LAN port? Did you run the new firewall batch file released since 3.2?

Also, do you have a fallback destination set in the ICR for the group of lines? Set it, and if the VMPRO can not answer it will go there auto.

 

[Jeremiah8]

aarenot,
I was able to re-produce the issue. Here are the answers:

VM Pro picked up when I dialed *17.
The PC is connected directly to the IPO LAN port.
The phone lines all look correct, this was working on 3.2 but not 4.0. Nothing else was changed other than the update.
I have not run the firewall patch.

I set the fallback in the ICR and the problem still replicated.

Thanks for your help.

J.

 

[aarenot]

just to clarify, when you dialed *17, the system had just given you a dead air on incoming call like two seconds prior?



Next thing to try,

Call the lines one at a time individually, see if any get dead air.

Run the firewall batch file on the VMPRO server.

Also, you said you have the system set to sync to use less VM ports, turn that off, and see if it helps.

 

[Jeremiah8]

aarenot,
I dialed *17 when a co-worker called the main number and had the dead air.

I'll try calling each line one by one.
Where do I find the download for the firewall batch file?

If those don't work I'll go ahead and set it to not sync the calls.

J.

 

[aarenot]

not sure on batch file download.

 

[Jeremiah8]

aarenot,
It is getting the dead air when we call the specific port. It doesn't matter how many calls are going, in this case there were two lines in use.

J.

 

[Jeremiah8]

aarenot,
I was able to get a work around for the problem. I created a new line and moved the analog line to my new test line. I'm now able to call in and not get the dead air. I'm not sure if it is possibly a bad port on the IP office unit. I'll do further testing after hours.

J.

 

[Shine52]

Is this all in regards to line 7? Are you having a problem w/ busy signals? Doesn't sound like the IPO or the carrier is giving a busy signal. I'm a little confused w/ the posts, but you might want to start pursuing that route. It does not seem like a VM issue to me.

Figure it out damn-it!