Is VCS loop detection not working on X7?

epicolo · ‎09-03-2012

Hi all,

i read all discussions related to this, including this one: https://supportforums.cisco.com/message/3561483

But, i think i founded a BUG (or i´m missing something on config).

Scenario bellow:

VCS E <-> VCS C environment, observed on X7.1 and upgraded to X7.2 without success.

SIP device (Jabber 4.4 or E20 TE4.1) registered on VCS E.

H323 device (E20 or MCU) registered on VCS E

both with Optimal call routing + interworking + looping detection + poison mode On on Traversal Zone

SIP registered with jabber@sipdomain.com

H323 device registered with 9999

SIP device dial an e164 number: 9999

The SIP INVITE arrives on VCS E with domain at the end as expected: 9999@sipdomain.com

VCS search locally by SIP and H323 using this alias and don´t found: 9999@sipdomain.com

Then it maches another rule to search on traversal zone by SIP and H.323: 9999@sipdomain.com

On VCS C, it has a transform to strip the domain.

Then it searches for 9999 locally by SIP and H323 and don´t found

Then it searches back by H323 only on the traversal zone back again: 9999 (OK, because the destination was transformed)

On VCS E, this LRQ arrives to search at destination 9999 and it found the destination.

With loop detection feature, this couldn´t happen! The Call TAG is the same for both attempts and in my point of view, the VCS E must mach this as a Loop, and not complete the call.

The result is:

The call is doubled on VCS E and traverse the FW, using another license on VCS C.

At VCS E:

One SIP <-> H323 call from SIP device source to traversal zone (VCS C), and

One H323<-> H323 call from traversal zone to H323 destination 9999.

At VCS C:

One H323<-> H323 call from traversal zone to traversal zone.

# At VCS E - Fisrt attempt - source

Tag: "1021277e-f3a2-11e1-acb6-0010f319a2cc"

Route:

Hop 1:

Zone: "Source"

Hop 2:

Link: "SubZone002ToTraversalSZ"

Hop 3:

Zone: "TraversalSubZone"

Hop 4:

Link: "Zone008ToTraversalSZ"

Hop 5:

Zone: "Traversal Zone to VCS Control"

# At VCS C:

Tag: "1021277e-f3a2-11e1-acb6-0010f319a2cc"

Route:

Hop 1:

Zone: "Traversal Zone to VCSE"

Hop 2:

Link: "Zone001ToTraversalSZ"

Hop 3:

Zone: "TraversalSubZone"

Hop 4:

Link: "Zone001ToTraversalSZ"

Hop 5:

Zone: "Traversal Zone to VCSE"

#On VCS E, call back form VCS C

Tag: "1021277e-f3a2-11e1-acb6-0010f319a2cc"

Route:

Hop 1:

Zone: "Traversal Zone to VCS Control"

Hop 2:

Link: "Zone008ToTraversalSZ"

Hop 3:

Zone: "TraversalSubZone"

Hop 4:

Link: "SubZone006ToTraversalSZ"

Hop 5:

Zone: "Destination"

#Two calls on VCS E, with VCS C on path

2012-08-31 21:41:56 2012-08-31 21:44:21 2 minutes 25 seconds jabber@sipdomain.com 9999 Traversal H323 <-> H323 Normal, unspecified This system

2012-08-31 21:41:55 2012-08-31 21:44:21 2 minutes 26 seconds sip:jabber@sipdomain.com sip:9999@sipdomain.com Traversal SIP <-> H323 200 OK This system

Thanks

Alok Jaiswal · ‎09-03-2012

Hi Elter,

Since the VCS has a transformed and change the detination and that's the reason you see a search going back to VCS-E.

If you disable the transform then i am sure the behavior would change and then you will see Loop detected,

Thanks

Alok

epicolo · ‎09-03-2012

As far as i know, the loop detection was based on Call TAG... at least this was the official information that i had, that this call tag was inserted to be able to use the loop detection feature and avoid to process the same call again. This is on training material.

I think that this behaviour that you mencion is related to send or not to send the call back to the zone that the call came from, and not the ability of a VCS to identify that a call was already processed and avoid the loop.

If my memory is right, this behaviour was not on X5.2 (i cannot test right now)

Please, could you double check your information and confirm this?

If your information is correct, i need to interact with training developers to include this on CAG.

Thanks

Alok Jaiswal · ‎09-03-2012

Hi Elter,

this is what you see in the admin guide..

Call loop detection mode

====================

Your dial plan or that of networks to which you are neighbored may be configured in such a way that there are

potential signaling loops. An example of this is a structured dial plan, where all systems are neighbored

together in a mesh. In such a configuration, if the hop counts are set too high, a single search request may be

sent repeatedly around the network until the hop count reaches 0, consuming resources unnecessarily.

The VCS can be configured to detect search loops within your network and terminate such searches through

the Call loop detection mode setting, thus saving network resources. The options for this setting are:

n On: the VCS will fail any branch of a search that contains a loop, recording it as a level 2 "loop detected"

event. Two searches are considered to be a loop if they meet all of the following criteria:

- have same call tag

- are for the same destination alias

- use the same protocol

- originate from the same zone

i hope it clarifies..!!!

Thanks

Alok

epicolo · ‎09-03-2012

OK Alok, i didn´t realized that it is an "meet all" in the sentence on X7 Admin Guide (this wasn´t on older versions)

To be more confused, check this text on the same X7 Admin Guide:

The Call Tag also helps identify loops in your network - it is used as part of the automatic call loop detection

feature, and you can also search the Event Log for all events relating to a single call tag. Loops occur when a query is sent to a neighbor zone and passes through one or more systems before being routed back to the original VCS. In this situation the outgoing and incoming query will have different Call Serial Numbers and may even be for different destination aliases (depending on whether any transforms were applied). However, the call will still have the same Call Tag.

A concern:

If a call with different protocol it is not considered the same call, and so it is not a loop, if we leave interworking On, there always will be a looped call on VCS C <-> VCS E enviroment with any alias on both sides... except if we search locally before (as instructed on manuals). I´ll do more tests latter.

Thanks

Martin Koch · ‎09-03-2012

In general you should design your dialplan that loops should not happen in the first place.

some unsorted thoughts:

The loop detection is a nice thing to prevent zeroing your call licenses (as this could happen if a real loop occurs)

or other issues related to looping calls.

You can also disable or limit the interworking (to only registered devices) on specific vcs.

Always be careful with search rules and transforms.

you can limit searches as well with regex (like exclude own domain towards the dns zone)

you have the capability to limit search rules to specific zones, especially now with X7.2 where

you can also define the source zone of a search or protocol.

Please remember to rate helpful responses and identify

epicolo · ‎09-04-2012

Hi Martin, thanks for your tips. I´m aware of them.

I´m not just trying to solve this customer problem (i alread did before to post here), what i´m trying to do is to let it more clear, to prevent others and to confirm the behaviour to teach correctly. If the behaviour generates to many trouble, we send a Feature Request to Cisco.

For example, the guides instructs to use any alias to traversal on both sides, this obviously will cause a loop, specially if a migration mode is in use (to strip a domain for SIP to reach e164 and to add a domain to legacy e164 reach URI). The loop don´t happen only because the VCS will find the destination locally before to try on traversal zone.

With this new interface that let users to make rules based on source, destination and protocol, we can expect that customers will do a lot of mistakes with dial plan (new interface beacause most of it was already available with CPLs).

*The test was made in lab environment, based on the customer problem.

regards