Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
10854
Views
15
Helpful
25
Replies

VCS Search Rules and Polycom

Go to solution
Rod.Blackie
Level 1
Level 1

‎02-02-2012 02:26 AM - edited ‎03-17-2019 10:46 PM

Hi Netpro's

I have an interesting problem. Since upgrading from v4 to v7 I can't dial polycom systmes that have the format IP##Alias (90.12.132.12##9016)

I have a search rule on my VCSE that looks like this (rule name=polycom test ! source=any ! mode=alias pattern match ! pattern type=regex ! pattern string=(^.*)##(.*) ! pattern behaviour=leave ! on match=continue ! target=trav-zone

When I use the locate tool the IP##Alias is routed correctly - brilliant no problems....

However when I use the same search rule on my VCS it doesn't route out via the traversal zone. Instead the local zone picks it up and the call can't be placed from my local endpoints.

I can place IP calls ok, I can place alias@IP calls ok - just not IP##alias calls...

Below is the print out from the failed locate look up on the VCS and I've attached my search rules - can anyone shed some light for me please?

  • Search (16)
    • State: Completed
    • Found: True
    • Type: H323 (LRQ)
    • CallRouted: True
    • CallSerial Number: ab2dc1bc-4d87-11e1-ae81-0010f31a4464
    • Tag: ab2dc298-4d87-11e1-a06f-0010f31a4464
    • StartTime: 2012-02-02 10:21:28
    • Duration: 0.48
    • Source (1)
      • Authenticated: False
      • Aliases (1)
        • Alias (1)
          • Type: H323Id
          • Origin: Unknown
          • Value: xcom-locate
      • Zone (1)
        • Name: LocalZone
        • Type: Local
    • Destination (1)
      • Alias (1)
        • Type: H323Id
        • Origin: Unknown
        • Value: 90.80.109.47##9016
    • SubSearch (1)
      • Type: Transforms
      • Action: Not Transformed
      • ResultAlias (1)
        • Type: H323Id
        • Origin: Unknown
        • Value: 90.80.109.47##9016
      • SubSearch (1)
        • Type: Admin Policy
        • Action: Proxy
        • ResultAlias (1)
          • Type: H323Id
          • Origin: Unknown
          • Value: 90.80.109.47##9016
        • SubSearch (1)
          • Type: FindMe
          • Action: Proxy
          • ResultAlias (1)
            • Type: H323Id
            • Origin: Unknown
            • Value: 90.80.109.47##9016
          • SubSearch (1)
            • Type: Search Rules
            • SearchRule (1)
              • Name: traversal-ALIAS
              • Zone (1)
                • Name: Nuvia-trav-zone
                • Type: TraversalClient
                • Protocol: H323
                • Found: False
                • Reason: Destination not found
                • Gatekeeper (1)
                  • Address: 86.12.153.205:6001
                  • Alias (1)
                    • Type: H323Id
                    • Origin: Unknown
                    • Value: 90.80.109.47##9016
            • SearchRule (2)
              • Name: Polycom Test
              • Zone (1)
                • Name: Nuvia-trav-zone
                • Type: TraversalClient
                • Protocol: H323
                • Found: False
                • Reason: Destination not found
                • Gatekeeper (1)
                  • Address: 86.12.153.205:6001
                  • Alias (1)
                    • Type: H323Id
                    • Origin: Unknown
                    • Value: 90.80.109.47##9016
            • SearchRule (3)
              • Name: default-01
              • Zone (1)
                • Name: LocalZone
                • Type: Local
                • Protocol: H323
                • Found: True
                • Gatekeeper (1)
                  • Address: 10.118.6.22:0
                  • Alias (1)
                    • Type: H323Id
                    • Origin: Unknown
                    • Value: 90.80.109.47##9016
1 person had this problem
Labels:
Preview file
23 KB
0 Helpful
3 Accepted Solutions

Accepted Solutions

Go to solution
Paulo Souza
VIP Alumni
VIP Alumni
In response to Rod.Blackie

‎02-02-2012 07:44 AM

Rod,

You you have a gateway in fard end, you can do this:

Create a Neighbor Zone towards the remote gateway "90.80.109.47".

Then you create a search rule and point it to that new Neighbor Zone.

I think that, by doing this, you will be able to route the call correctly. But Don't forget to change the translation that you actually have in VCS-C, which Andreas suggested.

Regards,

Paulo Souza

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

View solution in original post

Go to solution
awinter2
Level 7
Level 7
In response to Rod.Blackie

‎02-02-2012 07:59 AM

Rod,

using the "90.80.109.47##9016" syntax for dialing an H323 device is not a standards-based way of doing things, this is Polycom's approach to extension dialling which the VCS does not understand without modifying the alias to an 'Extension@IP' format.

Assuming that the 90.80.109.47 device receives the H225 SETUP message from the VCS-E, what does it do with the SETUP message? Is there a way which you can configure this far end device to strip off the '@90.80.109.47' portion of the dialled number and route the call to the 9016 extension?

Regards

Andreas

View solution in original post

Go to solution
Paulo Souza
VIP Alumni
VIP Alumni
In response to Rod.Blackie

‎02-02-2012 08:33 AM

Rod,

It's not correct.

The Cisco VCS Solution has features enough to work with most of the video conference system actually.

In your case, you should only create a neighbor zone to route the call correctly, because the far end is not and enpoint, it's a H323 gateway. I just did a test right now from a client registered to VCS-E, it worked, I am able to call the remote endpoint.

Please, use the below search rule, don't pay attention to the previous serach rule that I sent.

Regards,

Paulo Souza

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

View solution in original post

25 Replies 25

Go to solution
Paulo Souza
VIP Alumni
VIP Alumni

‎02-02-2012 05:07 AM

Hi friend,

The VCS-E pass over the rule "Polycom-test" and gets the reason "Destination not found". Then, it's probaly that VCS-E has sent a LRQ (Location request) to VCS-C and VCS-C has responsed with a LRJ (Location Reject) message.

I ask you to send us the search history of that call found in VCS-C, so we will be able to undestand all path of the call.

I got just one note:

If your Polycom system is registered on VCS-C having the 9016 E164 alias, then you should translate the pattern you received and send just the E164 alias to VCS-C. I think you should take "90.80.109.47##9016" and tranform in just "9016".

Can you show me the VCS-C's registration table so that I can see the alias of your Polycon system?

Regards

Paulo Souza

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
0 Helpful

Go to solution
Rod.Blackie
Level 1
Level 1
In response to Paulo Souza

‎02-02-2012 05:21 AM

Hi Paulo

Thanks for the reply. The Polycom system is not registered to our VCS - it's an external system that one of our customers uses. The VCS-E routes the call ok ( search on VCS-E below) but it's our internal VCS-C system that can not place the call. The search rule "polycom test" should pass the call to the traversal zone and isn't - it's being passed to the local zone and because the system does not exist on our network it's failing.

Search for 90.80.109.47##9016 on VCS-E

  • Search (14)
    • State: Completed
    • Found: True
    • Type: H323 (LRQ)
    • CallRouted: True
    • CallSerial Number: 0a9cd85a-4da0-11e1-9dba-0010f31a4570
    • Tag: 0a9cd936-4da0-11e1-b26d-0010f31a4570
    • StartTime: 2012-02-02 13:15:56
    • Duration: 0.25
    • Source (1)
      • Authenticated: False
      • Aliases (1)
        • Alias (1)
          • Type: H323Id
          • Origin: Unknown
          • Value: xcom-locate
      • Zone (1)
        • Name: LocalZone
        • Type: Local
    • Destination (1)
      • Alias (1)
        • Type: H323Id
        • Origin: Unknown
        • Value: 90.80.109.47##9016
    • SubSearch (1)
      • Type: Transforms
      • Action: Not Transformed
      • ResultAlias (1)
        • Type: H323Id
        • Origin: Unknown
        • Value: 90.80.109.47##9016
      • SubSearch (1)
        • Type: Admin Policy
        • Action: Proxy
        • ResultAlias (1)
          • Type: H323Id
          • Origin: Unknown
          • Value: 90.80.109.47##9016
        • SubSearch (1)
          • Type: FindMe
          • Action: Proxy
          • ResultAlias (1)
            • Type: H323Id
            • Origin: Unknown
            • Value: 90.80.109.47##9016
          • SubSearch (1)
            • Type: Search Rules
            • SearchRule (1)
              • Name: LocalZoneMatch
              • Zone (1)
                • Name: LocalZone
                • Type: Local
                • Protocol: H323
                • Found: False
                • Reason: Not Found
                • Gatekeeper (1)
                  • Address: 86.12.153.205:0
                  • Alias (1)
                    • Type: H323Id
                    • Origin: Unknown
                    • Value: 90.80.109.47##9016
              • Zone (2)
                • Name: LocalZone
                • Type: Local
                • Protocol: SIP
                • Found: False
                • Reason: Not Found
                • Gatekeeper (1)
                  • Address: 86.12.153.205:0
                  • Alias (1)
                    • Type: H323Id
                    • Origin: Unknown
                    • Value: 90.80.109.47##9016
            • SearchRule (2)
              • Name: URL DNS
              • Zone (1)
                • Name: URI DNS
                • Type: DNS
                • Protocol: H323
                • Found: False
                • Reason: Resolution failed
                • Gatekeeper (1)
                  • Alias (1)
                    • Type: H323Id
                    • Origin: Unknown
                    • Value: 90.80.109.47##9016
            • SearchRule (3)
              • Name: Polycom Test
              • Zone (1)
                • Name: Nuvia-trav-zone
                • Type: TraversalServer
                • Protocol: H323
                • Found: True
                • Gatekeeper (1)
                  • Address: 86.12.153.195:48641
                  • Alias (1)
                    • Type: H323Id
                    • Origin: Unknown
                    • Value: 90.80.109.47##9016
0 Helpful

Go to solution
Paulo Souza
VIP Alumni
VIP Alumni
In response to Rod.Blackie

‎02-02-2012 05:41 AM

Friend,

Now I understood .

Ok. It seems that the search rules on both VCS are correct. Just tell me one thing: Is the parameter "Calls to unknown IP addresses" on VCS-E set as "Direct"?

If yes, I ask you to make a call again and put here the event log details of both VCSs. But before it make sure that the log level is defined as "4", so we'll have detailed informations.

Regards,

Paulo Souza

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
0 Helpful

Go to solution
awinter2
Level 7
Level 7
In response to Paulo Souza

‎02-02-2012 05:47 AM

The VCS wouldn't recognise "90.80.109.47##9016" as a call to an IP address (And therefore, 'Calls to unknown IP addresses' would not be relevant), which is why I suggested changing this alias to 9016@90.80.109.47, which would be recognised by the VCS as a call to an IP address.

- Andreas

0 Helpful

Go to solution
bannouraw
Level 1
Level 1
In response to awinter2

‎07-02-2017 06:04 AM

Hi Guys,

I am facing a problem with telepresence SX20. I can receive calls from anywhere without any issues , but i am unable to make any outgoing calls.

It gives error 404 not found.

Please help to solve this problem. Kindly find the below attached log report :

  • Search (49)
    • State: Completed
    • Found: False
    • Reason: Not Found
    • Info: Policy Response
    • Type: SIP (INVITE)
    • SIPVariant: Standards-based
    • CallSerial Number: eb41778f-5257-47c2-ab61-4db6b78730c9
    • Tag: 0605ecb7-3190-4a7c-81ed-f8dbec828178
    • Source (1)
      • Authenticated: False
      • Aliases (1)
        • Alias (1)
          • Type: Url
          • Origin: Unknown
          • Value: 123@10.30.27.15
      • Zone (1)
        • Name: Traversal Zone
        • Type: TraversalServer
      • Path (1)
        • Hop (1)
          • Address: 10.30.27.18:5061
        • Hop (2)
          • Address: 10.30.27.15:5070
    • Destination (1)
      • Alias (1)
        • Type: Url
        • Origin: Unknown
        • Value: sip:709@kdcc.com
    • StartTime: 2017-07-02 15:45:06
    • Duration: 38.19
    • SubSearch (1)
      • Type: Transforms
      • Action: Not Transformed
      • ResultAlias (1)
        • Type: Url
        • Origin: Unknown
        • Value: 709@kdcc.com
      • SubSearch (1)
        • Type: Admin Policy
        • Action: Proxy
        • ResultAlias (1)
          • Type: Url
          • Origin: Unknown
          • Value: 709@kdcc.com
        • SubSearch (1)
          • Type: FindMe
          • Action: Proxy
          • ResultAlias (1)
            • Type: Url
            • Origin: Unknown
            • Value: 709@kdcc.com
          • SubSearch (1)
            • Type: Search Rules
            • SearchRule (1)
              • Name: LocalZoneMatch
              • Zone (1)
                • Name: LocalZone
                • Type: Local
                • Protocol: SIP
                • Found: False
                • Reason: Not Found
                • StartTime: 2017-07-02 15:45:06
                • Duration: 0
                • Gatekeeper (1)
                  • Address: 10.30.27.19:0
                  • Alias (1)
                    • Type: Url
                    • Origin: Unknown
                    • Value: 709@kdcc.com
              • Zone (2)
                • Name: LocalZone
                • Type: Local
                • Protocol: H323
                • Found: False
                • Reason: Not Found
                • StartTime: 2017-07-02 15:45:06
                • Duration: 0
                • Gatekeeper (1)
                  • Address: 10.30.27.19:0
                  • Alias (1)
                    • Type: Url
                    • Origin: Unknown
                    • Value: 709@kdcc.com
            • SearchRule (3)
              • Name: DNS Zone search rule
              • Zone (1)
                • Name: DNS Zone
                • Type: DNS
                • Protocol: SIP
                • Found: False
                • Reason: Request Timeout
                • StartTime: 2017-07-02 15:45:06
                • Duration: 10.06
                • Gatekeeper (1)
                  • Alias (1)
                    • Type: Url
                    • Origin: Unknown
                    • Value: 709@kdcc.com
              • Zone (2)
                • Name: DNS Zone
                • Type: DNS
                • Protocol: H323
                • Found: False
                • Reason: Undefined reason - Request timeout
                • StartTime: 2017-07-02 15:45:27
                • Duration: 17.9
                • Gatekeeper (1)
                  • Alias (1)
                    • Type: Url
                    • Origin: Unknown
                    • Value: 709@kdcc.com

_____________________________________________________________-

2017-07-02T15:46:05.393+03:00 tvcs: Event="Search Completed" Reason="Not Found" Service="H323" Src-alias-type="H323" Src-alias="123@10.30.27.15" Dst-alias-type="H323" Dst-alias="709@kdcc.com" Call-serial-number="3f8bee57-839d-4a93-ab0d-11101fac8617" Tag="0605ecb7-3190-4a7c-81ed-f8dbec828178" Detail="found:false, searchtype:LRQ" Level="1" UTCTime="2017-07-02 12:46:05,391"
2017-07-02T15:45:45.119+03:00 tvcs: Event="Search Attempted" Service="H323" Src-alias-type="H323" Src-alias="123@10.30.27.15" Dst-alias-type="H323" Dst-alias="709@kdcc.com" Call-serial-number="3f8bee57-839d-4a93-ab0d-11101fac8617" Tag="0605ecb7-3190-4a7c-81ed-f8dbec828178" Detail="searchtype:LRQ" Level="1" UTCTime="2017-07-02 12:45:45,119"
2017-07-02T15:45:45.109+03:00 tvcs: Event="Call Rejected" Service="SIP" Src-ip="10.30.27.18" Src-port="25031" Src-alias-type="SIP" Src-alias="sip:123@10.30.27.15" Dst-alias-type="SIP" Dst-alias="sip:709@kdcc.com" Call-serial-number="eb41778f-5257-47c2-ab61-4db6b78730c9" Tag="0605ecb7-3190-4a7c-81ed-f8dbec828178" Detail="Not Found" Protocol="TLS" Response-code="404" Level="1" UTCTime="2017-07-02 12:45:45,106"
2017-07-02T15:45:45.109+03:00 tvcs: Event="Search Completed" Reason="Not Found" Service="SIP" Src-alias-type="SIP" Src-alias="123@10.30.27.15" Dst-alias-type="SIP" Dst-alias="sip:709@kdcc.com" Call-serial-number="eb41778f-5257-47c2-ab61-4db6b78730c9" Tag="0605ecb7-3190-4a7c-81ed-f8dbec828178" Detail="found:false, searchtype:INVITE, Info:Policy Response" Level="1" UTCTime="2017-07-02 12:45:45,106"
2017-07-02T15:45:06.926+03:00 tvcs: Event="Call Attempted" Service="SIP" Src-ip="10.30.27.18" Src-port="25031" Src-alias-type="SIP" Src-alias="sip:123@10.30.27.15" Dst-alias-type="SIP" Dst-alias="sip:709@kdcc.com" Call-serial-number="eb41778f-5257-47c2-ab61-4db6b78730c9" Tag="0605ecb7-3190-4a7c-81ed-f8dbec828178" Protocol="TLS" Auth="NO" Level="1" UTCTime="2017-07-02 12:45:06,922"
2017-07-02T15:45:06.926+03:00

tvcs: Event="Search Attempted" Service="SIP" Src-alias-type="SIP" Src-alias="123@10.30.27.15" Dst-alias-type="SIP" Dst-alias="sip:709@kdcc.com" Call-serial-number="eb41778f-5257-47c2-ab61-4db6b78730c9" Tag="0605ecb7-3190-4a7c-81ed-f8dbec828178" Detail="searchtype:INVITE" Level="1" UTCTime="2017-07-02 12:45:06,922"

Call information
State Connection Failed
Start time 2017-07-02 15:45:06
End time 2017-07-02 15:45:45
Duration 39 seconds
Tag 0605ecb7-3190-4a7c-81ed-f8dbec828178
Serial number eb41778f-5257-47c2-ab61-4db6b78730c9
Type Video
SIP variant Standards-based
Bandwidth
Requested 384 kbps
Allocated 384 kbps
Route Traversal Zone -> Zone003ToTraversalSZ -> TraversalSubZone -> Zone002ToTraversalSZ -> DNS Zone
Leg 1
Bandwidth node Traversal Zone
Source alias 1 sip:123@10.30.27.15 (Url)
Target alias 1 sip:709@kdcc.com (Url)
Protocol SIP
Address 10.30.27.18:25031
Transport TLS
Encryption type None
Reason Not found
Cause 404
Leg 2
Bandwidth node DNS Zone
Target alias 1 sip:709@kdcc.com (Url)
Protocol SIP
Address 62.215.248.172:5061
Transport TLS
Encryption type None
Leg 3
Bandwidth node DNS Zone
Target alias 1 sip:709@kdcc.com (Url)
Protocol SIP
Address 62.215.248.172:5060
Transport TCP
Encryption type None
Leg 4
Bandwidth node DNS Zone
Target alias 1 sip:709@kdcc.com (Url)
Protocol SIP
Address 62.215.248.172:5060
Transport UDP
Encryption type None
Leg 5
Bandwidth node DNS Zone
Target alias 1 709@kdcc.com (H323Id)
Protocol H323
Address 62.215.248.172:1719
Reason Undefined reason
Cause Request timeout
Session 1
Status Failed
Media routed True
Call routed True
Participant 1 Leg 1
Participant 2 Leg 2
Bandwidth allocated 384 kbps
Bandwidth requested 384 kbps
Route Traversal Zone -> Zone003ToTraversalSZ -> TraversalSubZone -> Zone002ToTraversalSZ -> DNS Zone
Session 2
Status Failed
Media routed True
Call routed True
Participant 1 Leg 1
Participant 2 Leg 3
Bandwidth allocated 384 kbps
Bandwidth requested 384 kbps
Route Traversal Zone -> Zone003ToTraversalSZ -> TraversalSubZone -> Zone002ToTraversalSZ -> DNS Zone
Session 3
Status Failed
Media routed True
Call routed True
Participant 1 Leg 1
Participant 2 Leg 4
Bandwidth allocated 384 kbps
Bandwidth requested 384 kbps
Route Traversal Zone -> Zone003ToTraversalSZ -> TraversalSubZone -> Zone002ToTraversalSZ -> DNS Zone
Session 4
Status Failed
Media routed True
Call routed True
Participant 1 Leg 1
Participant 2 Leg 5
Bandwidth allocated 384 kbps
Bandwidth requested 384 kbps
Route Traversal Zone -> Zone003ToTraversalSZ -> TraversalSubZone -> Zone002ToTraversalSZ -> DNS Zone

0 Helpful

Go to solution
Rod.Blackie
Level 1
Level 1

‎02-02-2012 05:29 AM

OK I think I've noticed the issue. The VCS-E seems to be passing the calls for IP##Alias back to the VCS-C. It seems the calls to unknown ip address rule isn't picking up on the IP##Alias and thenfore not routing the calls directly.

The plot thickens...

0 Helpful

Go to solution
awinter2
Level 7
Level 7
In response to Rod.Blackie

‎02-02-2012 05:34 AM

Rod,

could you try changing the search rule so that the called alias is modified from 90.80.109.47##9016 to 9016@90.80.109.47 and see if this helps?

This should be your new search rule:

rule name=polycom test ! source=any ! mode=alias pattern match ! pattern type=regex ! pattern string=(^.*)##(.*) ! pattern behaviour=replace ! replace string=\2@\1 ! on match=continue ! target=trav-zone

Also make sure that the VCS-E has been set with 'Calls to unknown IP addresses' = Direct, and that your LocalZone search rule on VCS-E has lower priority than any of the search rules for the traversal server zone from VCS-E to VCS-C.

Regards

Andreas

0 Helpful

Go to solution
Rod.Blackie
Level 1
Level 1
In response to awinter2

‎02-02-2012 05:51 AM

Hi Andreas

Thanks for responding.

I changed the rules as you instructed and now the VCS-C passes the calls to the VCS-E via the traversal zone. The VCS-E also has calls to unknown IP addresses as direct.

The problem now is when I do the trace on the VCS-E it' sends the traffic back onto the traversal zone and now out via the gateway.

I've attached a picture of the search rules configured on the VCS-C and E

Thanks for your help.

Rod

0 Helpful

Go to solution
awinter2
Level 7
Level 7
In response to Rod.Blackie

‎02-02-2012 06:05 AM

Rod,

what do you mean by "the VCS-E it' sends the traffic back onto the traversal zone and now out via the gateway"?

Do you mean that the VCS-E sends an LRQ for the alias 9016@90.80.109.47 back towards the VCS-C? What gateway are you referring to?

Could you paste a screenshot of the search history on the VCS-E for a search for '9016@90.80.109.47' received from the VCS-C?

Thanks,

Andreas

0 Helpful

Go to solution
Paulo Souza
VIP Alumni
VIP Alumni
In response to awinter2

‎02-02-2012 06:25 AM

Friend,

Post here the search history as Andreas suggested, and also post the "network log" and "event log".

Regards,

Paulo Souza

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
0 Helpful

Go to solution
Rod.Blackie
Level 1
Level 1
In response to awinter2

‎02-02-2012 06:40 AM

Hi Andreas,

Sorry I should have been clearer. The VCS-E sends the call towards the VCS-C. The search below from the VCS-E shows a call to 90.80.109.47##9016 hitting rule 3 (VCSe) and being sent towards our VCS-C which sits behind the IP address 86.12.153.195

I would have hopped the VCS-E would have routed the call towards the internet and on to it's destination...

  • SearchRule (3)
    • Name: VCSe
    • Zone (1)
      • Name: Nuvia-trav-zone
      • Type: TraversalServer
      • Protocol: H323
      • Found: True
      • Gatekeeper (1)
        • Address: 86.12.153.195:48641
        • Alias (1)
          • Type: H323Id
          • Origin: Unknown
          • Value: 90.80.109.47##9016

This is the search from the VCS-C for 90.80.109.47##9016 (this works as expected but doesn't seem to being routed out via the VCS-E [86.12.153.205] correctly)

  • Search (20)
    • State: Completed
    • Found: True
    • Type: H323 (LRQ)
    • CallRouted: True
    • CallSerial Number: 07b37bea-4da9-11e1-8554-0010f31a4464
    • Tag: 07b37cbc-4da9-11e1-8254-0010f31a4464
    • StartTime: 2012-02-02 14:20:17
    • Duration: 0.15
    • Source (1)
      • Authenticated: False
      • Aliases (1)
        • Alias (1)
          • Type: H323Id
          • Origin: Unknown
          • Value: xcom-locate
      • Zone (1)
        • Name: LocalZone
        • Type: Local
    • Destination (1)
      • Alias (1)
        • Type: H323Id
        • Origin: Unknown
        • Value: 90.80.109.47##9016
    • SubSearch (1)
      • Type: Transforms
      • Action: Not Transformed
      • ResultAlias (1)
        • Type: H323Id
        • Origin: Unknown
        • Value: 90.80.109.47##9016
      • SubSearch (1)
        • Type: Admin Policy
        • Action: Proxy
        • ResultAlias (1)
          • Type: H323Id
          • Origin: Unknown
          • Value: 90.80.109.47##9016
        • SubSearch (1)
          • Type: FindMe
          • Action: Proxy
          • ResultAlias (1)
            • Type: H323Id
            • Origin: Unknown
            • Value: 90.80.109.47##9016
          • SubSearch (1)
            • Type: Search Rules
            • SearchRule (1)
              • Name: traversal-ALIAS
              • Zone (1)
                • Name: Nuvia-trav-zone
                • Type: TraversalClient
                • Protocol: H323
                • Found: False
                • Reason: Destination not found
                • Gatekeeper (1)
                  • Address: 86.12.153.205:6001
                  • Alias (1)
                    • Type: H323Id
                    • Origin: Unknown
                    • Value: 90.80.109.47##9016
            • SearchRule (2)
              • Name: Polycom Test
              • Zone (1)
                • Name: Nuvia-trav-zone
                • Type: TraversalClient
                • Protocol: H323
                • Found: True
                • Gatekeeper (1)
                  • Address: 86.12.153.205:6001
                  • Alias (1)
                    • Type: H323Id
                    • Origin: Unknown
                    • Value: 9016@90.80.109.47

0 Helpful

Go to solution
Paulo Souza
VIP Alumni
VIP Alumni
In response to Rod.Blackie

‎02-02-2012 06:52 AM

Rod,

Let me know one thing:

VCS-C sent the URI "9016@90.80.109.47" towards VCS-E. Ok. So, why does VCS-E make a search by using the pattern "90.80.109.47##9016"? It should make a search by using a pattern "9016@90.80.109.47" and then route the call by "unknow IP Address" rule.

Did you put the correct logs? Beacause it's impossible that happens.

Regards,

Paulo Souza

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
0 Helpful

Go to solution
Rod.Blackie
Level 1
Level 1
In response to Paulo Souza

‎02-02-2012 07:07 AM

Yes I know - something is not right.

I've just tried to place a call to 90.80.109.47##9016 from my MCU and the call routes through the VCS-C and then onto the VCS-E - I can see the activity. However when it hits the VCS-E I get an error that says "unidentified reason"

the search details are listed below.

Can you explain why a Polycom system is expecting IP##Alias tag and we are sending out a Alias@IP tag? who will the Polycom system pick it up???

Thanks.

  • Search (187)
    • State: Completed
    • Found: False
    • Reason: Undefined reason
    • Type: H323 (Setup)
    • CallSerial Number: 60741c12-4dae-11e1-9eb5-0010f31a4570
    • Tag: 60510678-4dae-11e1-92f7-0010f31a4464
    • StartTime: 2012-02-02 14:58:33
    • Duration: 0.28
    • Source (1)
      • Authenticated: False
      • Aliases (1)
        • Alias (1)
          • Type: H323Id
          • Origin: Unknown
          • Value: MCU
        • Alias (2)
          • Type: E164
          • Origin: Unknown
          • Value: 72
      • Zone (1)
        • Name: Nuvia-trav-zone
        • Type: TraversalServer
    • Destination (1)
      • Alias (1)
        • Type: H323Id
        • Origin: Unknown
        • Value: 9016@90.80.109.47
    • SubSearch (1)
      • Type: Transforms
      • Action: Not Transformed
      • ResultAlias (1)
        • Type: H323Id
        • Origin: Unknown
        • Value: 9016@90.80.109.47
      • SubSearch (1)
        • Type: Admin Policy
        • Action: Proxy
        • ResultAlias (1)
          • Type: H323Id
          • Origin: Unknown
          • Value: 9016@90.80.109.47
        • SubSearch (1)
          • Type: FindMe
          • Action: Proxy
          • ResultAlias (1)
            • Type: H323Id
            • Origin: Unknown
            • Value: 9016@90.80.109.47
          • SubSearch (1)
            • Type: Search Rules
            • CallsToUnknownIPAddresses (4)
              • Mode: Direct
              • Found: True
              • Zone (1)
                • Name: DefaultZone
                • Type: Default
                • Protocol: H323
                • Found: False
                • Reason: Undefined reason
                • Gatekeeper (1)
                  • Address: 90.80.109.47:1720
                  • Alias (1)
                    • Type: H323Id
                    • Origin: Unknown
                    • Value: 9016@90.80.109.47
            • SearchRule (1)
              • Name: LocalZoneMatch
              • Zone (1)
                • Name: LocalZone
                • Type: Local
                • Protocol: H323
                • Found: False
                • Reason: Not Found
                • Gatekeeper (1)
                  • Address: 86.12.153.205:0
                  • Alias (1)
                    • Type: H323Id
                    • Origin: Unknown
                    • Value: 9016@90.80.109.47
              • Zone (2)
                • Name: LocalZone
                • Type: Local
                • Protocol: SIP
                • Found: False
                • Reason: Not Found
                • Gatekeeper (1)
                  • Address: 86.12.153.205:0
                  • Alias (1)
                    • Type: H323Id
                    • Origin: Unknown
                    • Value: 9016@90.80.109.47

0 Helpful

Go to solution
Paulo Souza
VIP Alumni
VIP Alumni
In response to Rod.Blackie

‎02-02-2012 07:29 AM

Rod,

Now VCS-E routed the call as we was expecting, it used the "Call to unknow IP Address" rule.

So... I think that the remote destination is not able to receive the URI 9016@90.80.109.47. It is probaly expecting receive the pattern 90.80.109.47##9016. But it seems that VCS-E does not treat the "90.80.109.47##9016" address as being a "Call to unknow IP Address", so it does not route the call.

What do you have in fard end? Gatekeeper? Endpoint? Gateway?

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
0 Helpful
Customers Also Viewed These Support Documents