After upgrade to UCM7 CFA not works with CFNA

Unanswered Question
Sep 23rd, 2010

Hello

After upgrade from UCM 5.x to 7.X the below scenarios

Phone A with CFNA to Phone B

Phone B with CFNA to Phone A

Works fine, but when

Phone A CFA to Phone B

Phone B CFNA to Phone A

The CFA not works and cause loop calls.

In UCM 5 and 6, on our labs, the CFA works, but not in UCM 7.x not.

Can Somebody  help us?

Thanks

Peterson

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
rob.huffman Thu, 09/23/2010 - 11:30

Hi Peterson,

It sounds like you may be hitting this parameter that was first introduced in 7.x

Call Forward All Loop Prevention and Breakout

Here are the notes for Call Forward Loop Detection.

Call Forward All Loop Prevention and Breakout

Cisco Unified Communications Manager prevents Call Forward All activation on the phone when a Call Forward All loop is identified. For example, Cisco Unified Communications Manager identifies a call forward loop when the user presses the CFA softkey on the phone with directory number 1000 and enters 1001 as the CFA destination, and 1001 has forwarded all calls to directory number 1002, which has forwarded all calls to directory number 1003, which has forwarded all calls to 1000. In this case, Cisco Unified Communications Manager identifies that a loop occurs and prevents CFA activation on the phone with directory number 1000.

Call Forward All loops do not impact call processing because Cisco Unified Communications Manager supports CFA loop breakout, which ensures that if a CFA loop is identified, the call goes through the entire forwarding chain, breaks out of the Call Forward All loop, and completes as expected, even if CFNA, CFB, or other forwarding options are configured along with CFA for one of the directory numbers in the forwarding chain. For example, the user for the phone with directory number 1000 forwards all calls to directory number 1001, which has forwarded all calls to directory number 1002, which has forwarded all calls to directory number 1000, thus creating a CFA loop. In addition, directory number 1002 has configured CFNA to directory number 1004. The user at the phone with directory number 1003 calls directory number 1000, which forwards to 1001, which forwards to 1002. Cisco Unified Communications Manager identifies a CFA loop, and the call, which breaks out of the loop, tries to connect to directory number 1002. If the No Answer Ring Duration timer expires before the user for the phone with directory number 1002 answers the call, Cisco Unified Communications Manager forwards the call to directory number 1004.

For a single call, Cisco Unified Communications Manager may identify multiple Call Forward All loops and attempts to connect the call after each loop is identified.

Cisco Unified Communications Manager Administration Configuration Tips

If Call Forward All activation occurs in Cisco Unified Communications Manager Administration or the Cisco Unified Communications Manager User Options, Cisco Unified Communications Manager does not prevent the CFA loop.

***If the same directory number exists in different partitions, for example, directory number 1000 exists in partitions 1 and 2, Cisco Unified Communications Manager allows the CFA activation on the phone.

http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/rel_notes/7_0_2/cucmbe-rel_notes-702.html#wp581544

Hope this helps!

Rob

pgcristovam Thu, 09/23/2010 - 12:07

hi Rob

How you doing?

Maybe.... but on doc.. If user set CFA on ccm user options the loop is not prevent. And if i set on ccmuser the loop the CFA not works too, then:

Phone A CFA to Phone B

Phone B CFNA to Phone A

Phone C calls Phone A (CFA-to-PHoneB), PHone B no answer and CFNA to Phone A, Phone A not answer and CFNA PHone B, Phone B no answer and CFNA Phone A.....in another words, CFA not works.

David Hailey Thu, 09/23/2010 - 12:21

In general, this setup isn't ideal.  However, when you say the Call Forward All does not work - what specifically occurs (outside of the looped calls)?  I would first take a look here:

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a00801b3f4b.shtml

Take a look at the loop avoidance scenario and associated bug.

If you are having issues with CFA not working, then you may want to consider this:

http://www.netcraftsmen.net/resources/blogs/cfa-css-activation-policy-what-it-is-how-it-works-and-why-you-need-to-know.html

Hailey

Please rate helpful posts!

rob.huffman Thu, 09/23/2010 - 12:20

Hey Peterson,

Life is great! I hope for you as well

Is this an actual example

Phone C calls Phone A (CFA-to-PHoneB), PHone B no answer and CFNA to Phone A, Phone A not answer and CFNA PHone B, Phone B no answer and CFNA Phone A.....in another words, CFA not works.

If so, this is the expected behaviour. The call will cycle between A&B in this scenario. What would you like

to have happen?

Cheers!

Rob

pgcristovam Thu, 09/23/2010 - 12:25

Hi Rob

Should be works like UCM5.x and 6.X

Phone A CFA to Phone B

Phone B CFNA to Phone A

Phone C calls Phone A  (CFA-to-PHoneB), PHone B no answer and TRY CFNA to Phone A,  but Phone A don't should be ring, because has CFA configured.

Thanks

rob.huffman Thu, 09/23/2010 - 12:39

Hey Peterson,

I'm pretty sure you are seeing the effects of;

Call Forward All Loop Prevention and Breakout

It's never good to have a call Looping between two DN's....

what's the point?? Are you hoping that eventually someone

shows up and answers the call @ B?

I would always recommend that a Forwarding destination (in this case B)

be available or CFWD all to someone who is available so the caller actually

gets answered somewhere

I don't think there is any getting away from this "new" behavior in CUCM 7.x

Cheers!

Rob

srsivara Thu, 09/23/2010 - 13:13

Hi Peterson / Rob,


I handled the same issue for a customer some time back. Long story short, the Call Loop Prevention and Breakout methods in the later versions of Callmanager was implemented based on a CIA (Change In Architecture). Currently, there is no backward compatibility to use the old method of handling the loop situations.


I have the following enhancement defect opened to address this scenario :


CSCtg27929    CCM Service Parameter to choose CFA Loop Breakout method


CSCsg72098 implemented a Change in Architecture for Call Loop Prevention and Call Loop Breakout scenarios. However, currently, there isn't a Service Parameter implemented to choose the CFA Loop Breakout method.

- CFA Loop Breakout - The Forward Loop breakout will take into account of different kind of forwarding, including CFB, in the loop. So, CallManager is behaving as per design in your scenario. - CFA Loop Prevention - CallManager will check for a CFA loop when CFA is activated. Previous CallManager versions didn't have this functionality. The CFA prevention will only take into account CFA configuration, not other type of forwarding.

---

It would be a good idea to contact your Cisco Account Team and check if they can initiate discussions with the BU regarding this enhancement defect.

Thanks,
Sriram

Actions

This Discussion