Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

calls going to mailbox of originating extension, not end extension

Status
Not open for further replies.
tweege

tweege

Programmer
May 24, 2004
447
US
having a problem with calls ending up in the wrong mailbox on MM 5.2, SIP integration.

if a call comes into extension 1111, and is transferred to ext 2222, it does not always go to the mailbox for ext 2222. if 1111 has a mailbox calls will sometimes go back to it. if 1111 does not have a mailbox, callers will hear the generic voicemail greeting asking them to enter the ext they want or press * for the directory. this happens on plain extension numbers, as well as numbers that may be vdn's or hunt groups.

vendor has tried several diff things, but none have worked yet. anyone else have this issue?
 
Sort by date Sort by votes
On the VMSC, Telephone User Interface, General tab -- do you have checked the Enable Automated Attendant?
 
Upvote 0 Downvote
yep, it is checked. this problem is not specific to auto attendants though. i can call an extension with vm, have them xfer me to another ext with vm, and the orignal exts vm picks up.

thanks, tim
 
Upvote 0 Downvote
Ok, just verifying that this is checked. If it was not checked that means internal to MM all calls would route to the mailbox and not ring a phone.

When you trace in the Operation History Viewer the call that is being mis-directed what do you see?

When the calls are transfer from 1111 to 2222 is that by manual (person is actually pressing a digit, MM pilot number, voicemail button, etc) or is it being done by an application (Caller app)?

Are these actual mailboxes with different extensions or are you using the MM to route to other extensions without mailboxes? If non-mailbox extension only, how is the Subscriber & Caller Tab of the VMSC, Telephone User Interface setup?
 
Upvote 0 Downvote
here is a section from the history viewer:
06/14/11 12:44:07, "TUI", 21203, "Information", 87392, "S8800MAS1", "Incoming call due to a ring no answer condition for extension 7337.", 4, , ""
06/14/11 12:44:07, "TUI", 21279, "Information", 87391, "S8800MAS1", "DTMF was received. Key pressed was ' X'.", 7, 4704, ""
06/14/11 12:44:07, "PBX Integration", 21409, "Information", 0, "S8800MAS1", "Integration data: Extension . Called extension 7337. Calling extension 4797843197. Call divert 2.", 0, , ""
06/14/11 12:44:07, "TUI", 21279, "Information", 87391, "S8800MAS1", "DTMF was received. Key pressed was ' X'.", 7, 4704, ""
06/14/11 12:44:07, "TUI", 21279, "Information", 87391, "S8800MAS1", "DTMF was received. Key pressed was ' X'.", 7, 4704, ""
06/14/11 12:44:07, "TUI", 21279, "Information", 87391, "S8800MAS1", "DTMF was received. Key pressed was ' X'.", 7, 4704, ""
06/14/11 12:44:07, "TUI", 21217, "Information", 87392, "S8800MAS1", "Caller has requested to leave a message for mailbox 7337 after a ring no answer condition.", 4, 7337, ""
06/14/11 12:44:07, "Call Management", 21012, "Information", 0, "S8800MAS1", "Cleared DTMF buffer.", 4, , ""
06/14/11 12:44:07, "TUI", 21279, "Information", 87391, "S8800MAS1", "DTMF was received. Key pressed was ' X'.", 7, 4704, ""
06/14/11 12:44:07, "Call Management", 21027, "Information", 87392, "S8800MAS1", "Incoming call detected.", 4, , ""
06/14/11 12:44:07, "Call Management", 21010, "Information", 0, "S8800MAS1", "Incoming ring.", 4, , ""
06/14/11 12:44:07, "Call Management", 21030, "Information", 87392, "S8800MAS1", "Call routed.", 4, , ""
06/14/11 12:44:07, "PBX Integration", 21409, "Information", 0, "S8800MAS1", "Integration data: Extension . Called extension 7337. Calling extension 4797843197. Call divert 2.", 0, , ""
06/14/11 12:44:08, "Call Management", 21025, "Information", 87391, "S8800MAS1", "HandOffCall() was requested.", 0, , ""

the entries in questions are with ext 7337. an outside call was palced to it, and then transfered to ext 2264. the vm for 7337 answered after tjhe call went to cover. 2264 is not anywhere in the history.

calls are manually blind transferred.

thanks,tim
 
Upvote 0 Downvote
I am not a PBX guy much any more but this is a pure case of PBX sending the original called party to VM. I am sure it is a feature set somewhere but where i do not know.

This was a big deal years ago and if i called 1234 and it was forwarded to 4567 it would be answered by 4567 VM and the caller was confused.

Thus the change. I have looked but i am getting old and i can't seem to find the setting but i am sure it is in the PBX somewhere.

i will keep looking


Ken Means

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)
 
Upvote 0 Downvote
that is what it sounds like to me. however, the avaya cm engineer says that is not the case...says cm is sending the correct ext info to mm. even though the mm doesnt show that to be the case.

we have tried setting exts up in the private and public-unknown numbering tables, with no luck. have been a few other parameter changes (system-feature coverage-forwarding) with no luck either.

they are going to load the latest patches in the cm and mm tues evening in an effort to fix it. i have my doubts.....

thanks, tim
 
Upvote 0 Downvote
What was the results of this problem? Did the latest patches on the CM & MM fix it?
 
Upvote 0 Downvote
actually, the patches only made things worse. after that the auto attendants would not, and still wont, transfer out of the mm. all options go straight to vm or the opening greeting.

the original problem ended up getting solved by one of the first things we tried. only problem was, avayas psn was incorrect. the psn stated to go the the avaya support directory and run a script that made a change to the registry. it stated no reboot was needed since this info was read as needed. i ran the script, nothing changed, so i put it back to the original. 3 weeks later, we decide to run the script, but reboot this time. after the reboot calls went to proper mailbox. told avaya to update their psn.

now, i still have the prob where auto attds will not transfer out of mm. i ended up writing vectors for all but a couple of the attendants, so they would be up and running. got an email from the avaya tech stating since we had a workaround they were closing the case! are you kidding me, lol! i told him that was unacceptable and he got reamed from our bp as well. we'll see where this goes now.

so far, not impressed with the mm platform, nor the support from the bp, as it took them weeks to even get this to avaya. also is the first time i have had a problem getting something resolved when avaya has been involved directly.
 
Upvote 0 Downvote
I am sure this can be fixed but without access to the system not sure how anyone can help at this point other than to tell you to escalate on the Avaya side. This would mean getting your Avaya rep (not BP) involved and make sure they understand that they are not to put this back on the BP.

When you say the AA is not working can you give me some more details please.





Ken Means

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)
 
Upvote 0 Downvote
when any option on the auto attendant is selected, the calls either goes straight to the corresponding extensions voicemail, or to the opening greeting if the extension does not have vm.

op hist viewer shows the call being sent back to mm because of a rna situation.

here is a trace of a station trying to be transferred to by an attendant:

08:17:36 SIP<INVITE sip:5684@sparks.hma.com:5061;transport=tls SIP/
08:17:36 SIP<2.0
08:17:36 Call-ID: b173ac7bec274fb5
08:17:36 SIP>SIP/2.0 422 Session Interval Too Small
08:17:36 Call-ID: b173ac7bec274fb5
08:17:36 SIP<ACK sip:5684@sparks.hma.com:5061;transport=tls SIP/2.0
08:17:36 Call-ID: b173ac7bec274fb5
08:17:36 SIP>SIP/2.0 100 Trying
08:17:36 Call-ID: b173ac7bec274fb5
08:17:36 SIP>SIP/2.0 404 user not found (Adjunct origination)
08:17:36 Call-ID: b173ac7bec274fb5
08:17:36 SIP<ACK sip:5684@sparks.hma.com:5061;transport=tls SIP/2.0
08:17:36 Call-ID: b173ac7bec274fb5
08:17:43 TRACE COMPLETE station 5684 cid 0x1590
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

einnor1040
  • Locked
  • Question
Associated Extension Report
Replies
3
Views
465
KenMeans
KenMeans
mikeydidit
  • Locked
  • Question
Going over to Unity
Replies
5
Views
148
KenMeans
KenMeans
silentvibes
  • Locked
  • Question
Avaya Softconsole ver 1.5.4 starts to load then crashes on windows 10
Replies
1
Views
503
kyle555
kyle555
rejackson
  • Locked
  • Question
list subscribers with pbx extension
Replies
9
Views
184
rejackson
rejackson
jaja2468
  • Locked
  • Question
Menu mailbox
Replies
3
Views
133
KenMeans
KenMeans

Part and Inventory Search

Sponsor

Back
Top