Calls landing in a voice mailbox unexpectedly - SV9100

[Frank_And_Beans]

Hello,

We have two SV9100s and only one of them has InMail. We are using CCIS for communication/InMail between them. The sites are our HQ and Remote Office. The issue is a call made to the RO is picked up but the InMail AA at HQ. The caller presses option 1 which is a transfer to virtual extension 260. This VE is a line key on all the phones at the RO. Call Forwarding is not setup on the line. If all the lines at the RO are in use, the call will ring for 30 seconds and then transfer back to HQ, specifically extension 105. I was able to simulate this today multiple times yet me, nor our PBX vendor could determine how or why. He took a backup of the Database and is going to engage NEC but I thought I would post here in case someone has seen this before. Unfortunately for me, extension 105 is the CEO/Owner's phone so I would really like to solve this. Thank you for your time.

Frank

 

[belevedere]

Possible recalling to an attendant specified extension. Check MB 21-17. Make sure 105 is not set as an attendant. Or, go off hook and dial 0 to see where the call goes. The unanswered call will go to back to the extension that transferred it, or if set up, it can recall to the attn. position phone specified in 21-17. Also, make sure any attendant position extensions are not set to call fwd to 105.

 

[JuiceDanger]

The call will Transfer Recall back into Inmail after 30 sec by default. It is considered an internal transfer and triggers the recall timer, inmail will then handle the call with the caller ID 260. If there is a subscriber/routing mailbox it will execute what ever programming is associated with that mailbox. If there is no match it will follow the default routing option, which by default is to go to routing mailbox 1, but might be different on your system.

If you want to prevent the call from hitting the recall timer you can just blow it out to like an hour, if you use the transfer recall feature and need it to stay at 30sec you can use Timer classes to target just the Inmail ports and extend their 30sec recall timer.

 

[Frank_And_Beans]

My apologies. I did not receive notifications that any comments had been made regarding this post. I wanted to provide an update to what the NEC vendor suggested I change to resolve this. They said it should fix the issue but they could not determine how the calls were getting to 105. The MBs that they suggested changing are:

MB 24-02-04: Setting it to 0
MB 34-07-05: Setting it to 64800

I think these two changes are related to what JuiceDanger is referring to.

@Belevedere, 21-17 only lists the main 10 digit phone number for each SIP trunk. No extensions are listed. The IP trunks have no data set at all. We are using CCIS between the sites. When you say, "make sure 105 is not set as an attendant", do you mean in MB 21-17 or is there another location I should be checking as well?

The NEC vendor we have locally is still working with NEC to determine why 105 was getting those calls but since making the changes noted above, it has not happened. If you would like me to check any other MBs, just let me know and I will look over them and provide the data that is set there.

Thank you both and again, my apologies for not responding sooner.

 

[belevedere]

@Belevedere, 21-17 only lists the main 10 digit phone number for each SIP trunk. No extensions are listed. The IP trunks have no data set at all. We are using CCIS between the sites. When you say, "make sure 105 is not set as an attendant", do you mean in MB 21-17 or is there another location I should be checking as well?
Sorry, that should have been 20-17, operator extension assignment.

 

[Frank_And_Beans]

Hi Belevedere, Both PBX settings in MB 20-17 is only one extension, 101. Now it is interesting that 101 is set in the remote site's PBX as the remote site does not have any extensions that start with 1. The remote site is 201-210.

Any other places or thoughts?

Thanks again.