cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5042
Views
0
Helpful
5
Replies

Understanding Search Rules -- Source.

olmargarciac
Level 1
Level 1

I have a very very simple scenario just to learn about search rules & transforms and how they work.

I cant seem to get search rules to work with Source Zones to some how limit conversions based on source.

I want to fully understand the benefits of using one or another for simple conversions, etc.

Right now i am only using search rules with no transforms on the VCSc.

Scenario:

EX90         --    8095556631@172.16.246.92 (Registered with VCSc)

VCSc        --    172.16.246.92

VCSe        --    172.16.246.93

VCSe        --    10.0.0.230      (NAT - PublicIP)

FWLocal    --    10.0.0.1

FWInet      --     publicIP

Jabber       --     test.user@example.com (Registered with VCSe)

Jabber       --    *6631@example.com (Findme on VCSe)

EX90 -- VCSc -- VCSe -- FW -- Internet -- Jabber Video.

Everything works great if i dial for example 8095556631 from the Jabber video to the EX90.

The request from the VCSe to VCSc arrives like this: 8095556631@example.com(VCSe) --> 8095556631@172.16.246.92(VCSc).

This works w/o any intervention from search rules on VCSc because am attaching "@172.16.246.92" from the VCSe.

Everything works great if i dial for example *6631 from EX90 to the Jabber Video.

The request from the VCSc to the VCSe arrives like this: *6631@172.16.246.92 (VCSc) --> *6631@example.com.

This is done using search rules with source localZone to destination TraversalZone.

This is not working! if i dial for example 6631(Extension) from the Jabber Video to the EX90.

The request from the VCSe to VCSc arrives like this: 6631@example.com (VCSe) --> 6631@172.16.246.92 (VCSc). (This is what i want to change to 8095556631@172.16.246.92 without using transforms on the VCSc and using search rule with source TraversalZone).

The search Rule:

Name                           Desde VCSe

Priority                         40 (Highest Right Now)

Protocol                       Any

Source                         TraversalZone

Auth                            No

Mode                          Alias Pattern

Pattern                       Regex

Pattern String             (\d{4})(@172.16.246.92)

Patter Behavior           Replace -- 809555\1\2

On Match                   Stop

Target                        LocalZone

Logs:

Detail="Sending H.225 ReleaseComplete Q.931 Cause:Subscriber absent, H.225 Cause:Called party not registered, Additional Info:Destination not found"                              (!@#$ I Understand this one.$#@!)

Module="network.search" Level="INFO": Detail="Considering search rule 'LocalZoneMatch' towards target 'LocalZone' at priority '100' with alias '6631@172.16.246.92'"          (!@#$ I Understand this one.$#@!)

Module="network.search" Level="INFO": Detail="Search rule 'Hacia CUCM' did not match destination alias '6631@172.16.246.92'"                                                            (!@#$ I Understand this one.$#@!)

Module="network.search" Level="INFO": Detail="Search rule 'Hacia VCSe' did not match destination alias '6631@172.16.246.92'"                                                            (!@#$ I Understand this one.$#@!)

Module="network.search" Level="INFO": Detail="Search rule 'Desde VCSe' ignored due to source filtering"                                                                                          (!@#$ I DO NOT Understand this one.$#@!)

Module="network.search" Level="INFO": Detail="Search rule 'Hacia CUCM -- Extension' ignored due to source filtering"                                                                      (!@#$ I Understand this one.$#@!)

Module="network.h323" Level="INFO": Dst-ip="172.16.246.93" Dst-port="15070" Detail="Sending H.225 Proceeding "

Module="network.h323" Level="INFO": Src-ip="172.16.246.93" Src-port="15070"

Detail="Received H.225 Setup H.323v6 Bandwidth:5952kbps DestAlias:6631@172.16.246.92 DestCSAddr:['IPv4''TCP''172.16.246.92:1720'] Vendor:TANDBERG"

I don't understand how selecting Source:TraversalZone as the source of the request is giving me "ignored due to source filtering".

Seems to me that am lacking some basic understanding on how search rules work for incoming requests not generated locally.

Thx in adv.

1 Accepted Solution

Accepted Solutions

The guides were less regards the search then the clean deployment, which also mens the usage of the domain

Lets quote the guide:

The routing configuration in this document searches for destination aliases that have valid SIP URIs (that is, using a valid SIP domain, such as id@domain).

Do please configure and use a domain, your rules might need fixing as well and test again.

I would stick to a-z,0-9, -, . for the user part and the domain of the sip uri!

The reason I would most likely see is that without a propert domain it does not match.

I would also be careful with to many transforms, rewrites and searches as you might see trouble with presence and other things.

Please remember to rate helpful responses and identify

View solution in original post

5 Replies 5

Martin Koch
VIP Alumni
VIP Alumni

Some short thoughts:

* please review this guides:

http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/config_guide/Cisco_VCS_Basic_Configuration_Control_with_Expressway_Deployment_Guide_X7-2.pdf

http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/admin_guide/Cisco_VCS_Administrator_Guide_X7-2.pdf

* which software versions do you use?

* in general and especially if you use sip, please use domains

* how is the endpoint registered? h323(name/number)/sip/both?

* I would not recommend using * or # in addresses as this can bring in problems as well

* if you use NAT upfront the VCS-E there are some caveats, in short you have to have the dual interface option and if you communicate with that interface the external ip has to be used, never the internal one! you find more in the forum about that and other of the listed topics, try to search for them

* is your traveral zone active on sip?

* most deployments findme on the vcsc is more suitable

* check your firewalls as well, especially that there are no l3 features like inspection or helper active

I would recommend to reach out to your Cisco partner or an external consultant to review and

optimize your deployment and give you some introduction.

Please remember to rate helpful responses and identify

Hello Martin,

Thanks for your time and suggestions, here some comments from your thoughts:

  • I have reviewed those guides and i didnt find anything regarding search rules using source nor here in the forum :(.
  • The version of the VCSs is X7.2
  • This is currently a lab scenario that I am using for learning now.
  • EX90 is registered as SIP.
  • I am using * just to keep it easy to remember "someone". So that number 8095551234 on the VCSc is *1234 on VCSe.
  • I have DNI Option and is working properly.
  • Yes. SIP: Active: 172.16.246.93:7001


Where i am having problems is understanding why using a search rule with a source selecting the TraversalZone (VCSc to VCSe) is not working like i expect. Everything but that is working correctly.


The guides were less regards the search then the clean deployment, which also mens the usage of the domain

Lets quote the guide:

The routing configuration in this document searches for destination aliases that have valid SIP URIs (that is, using a valid SIP domain, such as id@domain).

Do please configure and use a domain, your rules might need fixing as well and test again.

I would stick to a-z,0-9, -, . for the user part and the domain of the sip uri!

The reason I would most likely see is that without a propert domain it does not match.

I would also be careful with to many transforms, rewrites and searches as you might see trouble with presence and other things.

Please remember to rate helpful responses and identify

Martin,

Amazinly enough, it was because of the Domain... i just modified it with the domain instead and works perfectly.

But i dont know why... :s

But thanks anyways.

Happy to read that this fixed your issue and thanky you for rating and setting the thread to answered.

If you look a bit around in the forum then you will find some postings about ip dialing.

As its also used regards h323 and e164 dialing some things might be handled differently.

Though I also would say a ip could be a valid sip domain the VCS seems to see it a bit different :-)

Also the usage of :port or ;options can confuse expecially the searches/transforms.

Btw, you also have some variables, so you could use %localdomains% instead of a hardcoded domain name.

Its great to see that you experiment with regex, thats can become quite handy.

Also check out the CPL functionality, that will be of your interest as well :-)

Please remember to rate helpful responses and identify