AA picking up instead of VM

Unanswered Question
Feb 7th, 2010

Hi guys !

4 years of experience with sipura products here and I still dont beleive how many bugs we encounter on our routine installs...


We have a client that is anxiously waiting for us to get frustrating issues solved with his spa9000 / spa400 system. ( 8 phones are linked to it : all spa942s )

Whenever someone calls and goes trough the spa9000 line1 contact list ( 101, cfwd=aa ), all goes well and extension 101 rings for 15 seconds before passing the call to the AA. But if 101 picks up and tries to transfer the call to another extension and this one is not there, the AA picks up instead of it's private voicemail. This is a major bug ! How can we resolve this ?

We have other issues but these will wait until we fix this main one...

thx in advance !

LoOwEe ( [email protected] )

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
domobec09 Mon, 02/08/2010 - 21:03

I was thinkin', could it be the contact list going back to it's cfwd=aa when call is supposed to reach user voicemail ? The contact list in this case has an extension before the CFWD so this one answers, then transfers to the user but AA picks up when user does not answer, very strange.

anyone ?

jestowe Tue, 02/09/2010 - 18:31

Thank you for visiting the Cisco Community.

I'd like to see your config on this one.  It sounds like you've got a forwarding setup perhaps on the phone itself.  Once the call is answered, it is out of AA's grasp unless it's routed back.  Is the number they're forwarding to setup to be answered by AA?  Let's see your dial plan, AA dial plan, AA script, and forwarding for that phone.

Or you could just send in the entire config file for each device.  See here on saving the config.

Thanks.

Jeff.

domobec09 Wed, 02/10/2010 - 08:52

Hi Jeff !

Here is config of the spa9000 as well as 101 extension (spa942) which is first on the contact list... ( contact list : 101, CFWD=aa )

When this phone answers the inbound call, xfers or bxfers to other extensions redirect callers to the AA instead of the associated extension VM.

Of course, we have checked other extensions countless times and everything is setup correctly ( ex.: Ext102 has VM set on all boxes in the user page and the PHONE page points to VMM. Finally, EXT1 page has the correct vm settings also. Take note that local calls or inbound calls that go trough the AA go to the voicemails correctly so it cannot be a VM setting issue.

thank you very much for your help...

Attachment: 
David Hornstein Sun, 02/14/2010 - 21:59

Hi,

Just spent a few minutes looking at it.

Interesting hunt group you have configured.

0:name="urgence",105,101,102,103,hunt=re;14;1,cfwd=vm1101|9:name="english",103,hunt=re;14;1,cfwd=vm1103

With  SPA9000 Line 1 dialplan of  (<9:9>xx.)  ...interesting.

Why are you using 0 and 9 ( 9 being steering digit for outside line)  for hunt group  numbers, I wonder why ?

Other than that, if you do believe there is a issue with call forwarding to other extensions and getting AA, why not open a call with the Small Business Support center.  Open a case, I'm guessing your spa9000 is still under warranty.

The following link will have contact details for your particular county;


http://www.cisco.com/en/US/support/tsd_cisco_small_business_support_center_contacts.html

regards Dave

domobec09 Tue, 02/16/2010 - 20:39

Hello there Dave !

----------------------

Sorry for the reply delay, I was out of the office for a couple days.

We use these hunt groups all the time on our installs and never had that call redirect problem when contact list pointed to an extension instead of the AA directly. I will be contacting your support hotline tomorrow but do you have any idea on where the problem could be ? It really only happens when  extension 101 picks up the calls and xfer or bxfer them to another extension, AA picks up instead of their respective voicemail. note that everything goes to the correct VM if local extensions call each other or if AA picks up on the contact list call forward ( 101, cfwd=aa )

Any insights where to look at ?

Customer is very anxious to get this option working...

Thank you !

David Hornstein Wed, 02/17/2010 - 00:22

Hi Louis,

With the settings you have it looks like the SPA9000 is setup to proxy the call from x101 to whom ever.  That is fine.

I think you must  go to the next step and  contact the  Small Business Support Center (SBSC). I think the SBSC TAC engineer might love to see the SIP debug from the SPA9000 to see what the spa9000 is doing  when extension 101 is transferring the call to another extension.

To capture a SIP debug from the SPA9000, you will need to ;

Step 1. on the  SYSTEMS tab,  set up a IP address of a debug server.  This debug server is  IP addresses  is that of a PC that is running a syslog server application like kiwisyslog   daemon or solarwinds, but there are many other free ones out there.  Click here for one

Step 2. The modify the SIP DEBUG OPTION , as seen  in the picture below, from it's default  to 'full',

The syslog server on your PC will capture the SIP messages and hopefully save it to a file on that PC.

SBSC  TAC technician can then see what's happening, or pass the trace to his next level of support. Please don't capture too much before or too much after the event as these syslog traces can be very very large.

If you would be so kind and make it easier on everyone, try to indicate at what time exactly on the syslog capture did the transfer occur.

To contact the Small Business Support Center (SBSC) try;

http://www.ciscosystems.com/en/US/support/tsd_cisco_small_business_support_center_contacts.html

I must say, I still don't like you using 0 and 9 as a number for a hunt groups. But having said that, I must admit that this problem  is not blatantly obvious.

But a SIP debug from the SPA9000,   in the right hands can figure this one out.

regards Dave

111.JPG

Actions

This Discussion