Call fowarding on shared line not working as expected

[todd haines]

I am having an issue with call fowarding a shared line to another extension. Extension x3044 is on 4 different phones as a shared line with the same settings on each phone for this line. Currently I have an extension (3044) set to foward to (1123) on Forward No Answer Internal/External in 12 seconds. When I change the No Answer Ring Duration (seconds) to anything above 12 seconds the call flow goes crazy. With 12 seconds configured the call flow is as such....x3044 (3x's)---> x1123---> (3x's) then back to x3044 voicemail if not answered. If I change this to anything above 12 seconds the call flow is this x3044 (3x's) ---> x1123 (3x's)---> x3044 (3x's) --->x1123(4x's) then VM. We run CM 7.1.5.33900-10. Is there anything that could be throwing this call flow that I am missing?

[Joseph Martini]

Are these lines part of a hunt group?  If so the hunt group's call forward settings and ring duration may be kicking in causing unexpected forwarding.

[todd haines]

Joe unfortunately they are not. This line is a shared line only on 4 different phones. No hunts/pickup groups are associated with this extension.

[Bobby Villegas]

Verify that you dont have any of these restrictions currently configured. Check bullet number 3.

Shared Line Restrictions

The following restrictions apply to shared lines:

•Do  not use shared lines for Cisco Unified Communications Manager Attendant  Console pilot points or hunt group members. The phone that acts as the  attendant console supports shared lines.

•Do  not use shared-line appearances on any Cisco Unified IP Phone that  requires autoanswer capability and do not turn on auto answer for a  shared-line appearance.

•Do  not configure shared-line appearances on the primary lines of the  phones; for example, if two phones have a shared-line appearance, only  one of the phones should have the primary line configured as shared (the  other phone should have the secondary line configured as shared).

•Barge, cBarge, and Privacy work with shared lines only.

•Cisco  recommends that you do not configure shared lines for Cisco Unified IP  Phones, H.323 clients, and MGCP POTS phones; likewise, Cisco recommends  that you do not configure shared lines for H.323 clients and MGCP POTS  phones. If you configure the same shared-line appearance for a H.323  client, a MGCP POTS phone, for example, NetMeeting, and a Cisco Unified  IP Phone, you cannot use the hold/resume feature on the H.323 client or  MGCP POTS phone.

•Cisco  recommends that you do not configure shared lines for Cisco Unified IP  Phones 7905, 7912, 7940, and 7960 that are running SIP because these  phones cannot pick up held calls on shared lines nor can they use the  shared-line features Single Button Barge/cBarge, Barge, cBarge, and  Privacy.

•Cisco  Unified IP Phones 7906, 7911, 7941, 7961, 7970, and 7971 that are  running SIP have the capability of supporting multiple lines with the  same directory number in different partitions. However, configuring and  using other phones that are running SIP with multiple lines with the  same directory number is not supported.

•If  the number of shared-line users in the conference is equal to or  greater than the configuration for the Maximum Number of Calls setting  for the device from which you are attempting to barge, the phone  displays the message, Error Past Limit.

[Rob Huffman]

Hi Todd,

I've been looking for possible bugs related to this issue, but I need to

clarify two things;

In your original post you detail;

"With 12 seconds configured the call flow is as such....x3044  (3x's)---> x1123---> (3x's) then back to x3044 voicemail if not  answered."

Is 1123 set to CFNA to voicemail? Or does it CFNA to 3044? The reason I ask is that

not only the number of rings seems to change but the fact that the call ends up back at 3044

at all in the second scenario.

Second question is where are you changing the FNA timer? On 3044, 1123 or the "system" level?

Cheers!

Rob

"Why not help one another on the way" - Bob Marley

[todd haines]

Rob--

x1123 is not set to forward anywhere. x3044 is set to forward to x1123 on Forward No Answer Internal/External. My understanding was that when a call came in on the originating extension and is forwarded to another extension and not answered the call will be deposited back to the originating extensions VM. I am changing the No Answer Ring Duration on the x3044. Both extensions are set to 12 seconds. Here is screenshots of both extensions. The first is x1123 and second being x3044.

[Mohammed al Baqari]

Sounds bug behavour. Do one thing, in service parameters increase forward no answer timer to high value say 500 secs. Then start tuning you no answer timer at device level. Let's see if this work.

The idea is just to avoid system default value.

"Please rate useful posts"

[Rob Huffman]

Hi Todd,

OK

We can see from the first screen shot how calls end up at voicemail after routing

from 3304 to 1123. DN 1123 has the FNA internal/external checkboxes to voicemail

applied. So at least we know the call flow and how it should work and why.

My next question is, was this tested during business hours or off hours? It almost

seems like perhaps a second call came in during the testing. I would remove 3304

from all but one phone for testing. Set the RNA timer to something like 16 and try the

call forward no answer again. This time we should see 4 rings @ 3304 (16 seconds)

then a forward no answer to 1123 then 3 more rings (12 seconds) and then it should

route to the 3304 mailbox due to the checkbox to VM that is set on 1123.

Once you get it working for one 3304 appearance you can add the others back in

one at a time.

Can you try this during an after hours test??

Cheers!

Rob

"Why not help one another on the way" - Bob Marley

[todd haines]

Rob--

I tried as you suggested and I am still being presented with the call flow going haywire when I set the FNA timer to anything above 12 seconds. I did make one change though and put x3044 as line 1 on 1 of the phones to see if this would make a difference. It did not. I tried adding 1 phone at a time back in and test each time afterwards and still have the same issue above 12 seconds. I have done this in an after hours envrionment and so as to minimize excessive calls to these lines. I dont know where else to look or check and this is really strange this is happening.  Now when I do this to my phone and a coworkers using the same call flow I can make the change to 16 seconds with no issues. Our setup is exactly the same...No Hunts or anything. Just a simple call forwarding between two lines. I am starting to think it has to be something with the device pool/CSS these phones reside in but everything checks out.