in our VCS Expressway event log i am seeing this event, wondering if someone can tell me what it means please
tvcs: Event="Search Loop Detected" Service="SIP" Src-alias-type="SIP" Src-alias="firstname.lastname@example.org" Dst-alias-type="SIP" Dst-alias="sip:email@example.com" Call-serial-number="09607aea-572e-11e1-8d5b-0010f30f66b8" Tag="09607c16-572e-11e1-b1b3-0010f30f66b8
It shows what appears to be a loop in the VCS setup of some sort. Check your search rules and the priorities.
The best document to look at is probably the Basic VCS Control/Expressway configuration document – though this only talks about priorities in the VCS Control / VCS Expressway environment, not priorities to the Directory VCS.
The recommendation is to limit searches as far as possible.
So in practice this means our recommendations for a system where there are regional VCS Controls and Expressways and the regions are joined by a Directory VCS:
The other rules are that:
the corollorary of this is that Directory VCS only ever routes ‘local domain’ calls.
Hope this makes sens.
the search loop is most likely being seen because the search for 'firstname.lastname@example.org' is being sent out the DNS zone and then coming back to the Expressway itself, assuming that the search loop is seen on the VCS for which the SIP DNS SRV records for the 'med.ubc.ca' domain point to.
A dig lookup for the _sips._tcp.med.ubc.ca SRV records show that this points to 'vcs.med.ubc.ca', which I assume is the VCS which this was seen on.
To prevent the Expressway from sending searches out the DNS zone for its own domains (Domains which have their H323 and SIP SRV records pointed to this same Expressway), you should --replace-- your current AnyAlias search rule for your DNS zone with a regex type search rule as follows:
Rule name: AnyAlias except local domains
Priority: The default 150 should be fine unless you have an unconventional search rule setup in which you should use the same priority as your current AnyAlias search rule
Mode: Alias Pattern Match
Pattern type: Regex
Pattern string: (?!.*@%localdomains%$).*
Pattern behaviour: Leave
What this search will do is that it will match any dialed alias as long as it does not end with one of the local SIP domains of this Expressway, meaning that if 'med.ubc.ca' is a local SIP domain on this VCS, the search rule will NOT match anything ending with 'med.ubc.ca' but will match any other non-local SIP domain such as 'email@example.com'.
This is also mentioned in the Cisco TelePresence Video Communication Server Basic Configuration Cisco VCS Control with Cisco VCS Expressway Deployment Guide (X7.0), section 'DNS zone configuration'.
Hope this helps,
Pagan / Andreas,
Folks, have you ever read this guide you're suggesting? I read this guide many times and I think that it is not correct at all when it suggests a example of create search rules to route call between both VCSs.
Look this table and let me know what you think about it:
Guys, following this deployment, no matter which priority my search rules have, if the user registered in any place (internal or external) dial some alias that does not exist, then a loop certainly will occur! Always!
It's like having the "router A" pointing its default route to "router B", and "router B" point its default route to "router A". You got a loop. That's all.
So, what do I do to solve that issue? I don't create a rule "any to any alias" in VCS Expressway, it's not necessary. I know exactly what aliases and E164s my internal endpoints are using, so I create rules that summarize my local endpoints's route.
Please, if I am wrong or didn't realize something, please let me know. I am here to learn with you.
You use the search rule mentioned by Andreas (and which is in the x7.0 documentation) instead of the "AnyAlias" search rule you refer to above.Works for me.
If you create the DNS Zone as Andreas said and also create the search rules suggested by "Cisco TelePresence Video Communication Server Basic Configuration Cisco VCS Control with Cisco VCS Expressway Deployment Guide (X7.0)" to route call between both VCSs, and also define rule's priority as Pagan said, you will still have the possibilty of a loop to occur!
Do the test, do what the deployment guide tells you to do, then go to any user and ask him to dial "99999" for example. You will see a loop in VCS!
Fortunately, VCS has a loop detect feature!
I think you might have misunderstood how searches work on VCS's. When you have a VCS-C and VCS-E with a traversal zone set up between them, it is totally fine and quite normal to have bi-directional AnyAlias search rules across this traversal zone.
This is fine because the VCS will not send a search back to the VCS it received the sarch from initially (unless the destination alias changes as it is received on the VCS, for example via transforms, FindMe or CPL). In other words, if VCS A sends a search for 'firstname.lastname@example.org' to VCS B via an AnyAlias search rule, VCS B will not send a search back to VCS A for the same alias (But might do so if the alias changes from 'email@example.com' to for instance 'firstname.lastname@example.org' via FindMe, CPL or a transform).
On top of this the VCS has the loop detection which normally detects loops such as the one described in the initial post, to prevent looping searches to consume all search resources on the VCS.
Hope this helps in clarifying things a bit,
I understand what you said clearly. That's right, but only in theory...
Build a lab following the deployment which you have suggested. When a user dials a alias that does not exist, a alias that is not a "ramal@domain" or a IP address, for example "99999", then VCS-C forwards the call to VCS-E and VCS-E sends it back to VCS-C and... the event "Loop detected" appears.
As I said, the loop does not occur beacause of the loop detect feature in VCS, that's right! Otherwise, it would occur.
Thank for your reply.
I would be very interested to see diagnostics logs from the VCS's where you are seeing this happening on (With 'Networking' set to DEBUG), because the VCS-E should not send the search back to the VCS-C unless the destination alias has changed or a loop has occured further upstream, so if you are able to reproduce this behaviour in lab, feel free to send me a PM and attach such log files.
I saw it happening in a project the I have made one time. If I have opportunity, I will test this behavior and send the logs to you. But look, what really matters here is: the loop does not occur, VCS cancels the call search after certain numbers of hops. That is nice!
I see this behavior on my VCS.
The VCS doesn't seem to avoid sending the calls back to the Neighbor from which it received the call.