cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2074
Views
0
Helpful
4
Replies

How to make the ip dialing between unregistered device with registered device in VCS

jidesh chandran
Level 1
Level 1

hi ,

in my infra i have

VCS 7.2 .VCSE7.2, mcu 8510,tms 14.3 ,cisco endpoint sx20 ,polycom endpoint hdx7000,8000 , lifesize and Aethra Vega X5

All cisco and polycome and lize size device is registered with vcs and works fine. Aethra not added with vcs and it is separatly conneted and used for isdn calls.

all sx 20 have 3 mutisite call  licence installed .

1:now my concern is whenever i create booking of multiple room it is not creating bridge at mcu and it using  mutisite feture of the endpoint . my requirement is not use the multisite feature for creating the multiple room calls.

2: need to call Aethra device by ip dialing and Aethra to endpoint registered with VCS , i tried on the settings on vcs by changing indirect mode to direct .

how to achieve this on my infra


1 Accepted Solution

Accepted Solutions

William Bell
VIP Alumni
VIP Alumni

As I am sure you are aware, Dialing by IP address is only supported on H.323 devices. When a H.323 device is registered to a call processing system (e.g. the VCS Control), it is still possible to call the device directly by IP address. However, in these instances the endpoint will typically respond with a H.225 message to route the call through the appropriate gatekeeper. This means that the calling device must have a viable IP path to the gatekeeper and the H.323 endpoint or device.


When the VCS control receives a H.225 SETUP message from an unregistered device, that device is associated to the Default Zone. The Default Zone authentication policies are applied and the calling device is treated as “not authenticated”. Therefore, you must account for call and search rule authentication policies to ensure that calls using this method conform to organizational policies.

The search rule that would be matched by the VCS in this scenario is “Known IP”.

The VCS considers an IP address to be “known” if it belongs to a specific registered endpoint or falls within the IP address range of a subzone membership rule. Any other IP addresses are considered to be unknown.

So, I believe you can address this requirement by:

1. Creating a subzone membership rule with the IP address or subnet of your Aethra device

2. Ensuring that your search rule authentication policies will allow calls from unauthenticated devices (like your Aethra codec)

3. Create a search rule where the Source Zone is "Any", the Pattern Match is AnyIPAddress, and the target zone is Local. If you already have a search rule with AnyIPAddress (i.e. you have a VCS-E and using Indirect method) then you should ensure that the "intra-site" AnyIPAddress search rule is higher priority than the "external" (i.e. VCS-E path) search rule. Also, set the "intra-site" rule to continue on match condition.

HTH

-Bill (@ucguerrilla)

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

View solution in original post

4 Replies 4

William Bell
VIP Alumni
VIP Alumni

As I am sure you are aware, Dialing by IP address is only supported on H.323 devices. When a H.323 device is registered to a call processing system (e.g. the VCS Control), it is still possible to call the device directly by IP address. However, in these instances the endpoint will typically respond with a H.225 message to route the call through the appropriate gatekeeper. This means that the calling device must have a viable IP path to the gatekeeper and the H.323 endpoint or device.


When the VCS control receives a H.225 SETUP message from an unregistered device, that device is associated to the Default Zone. The Default Zone authentication policies are applied and the calling device is treated as “not authenticated”. Therefore, you must account for call and search rule authentication policies to ensure that calls using this method conform to organizational policies.

The search rule that would be matched by the VCS in this scenario is “Known IP”.

The VCS considers an IP address to be “known” if it belongs to a specific registered endpoint or falls within the IP address range of a subzone membership rule. Any other IP addresses are considered to be unknown.

So, I believe you can address this requirement by:

1. Creating a subzone membership rule with the IP address or subnet of your Aethra device

2. Ensuring that your search rule authentication policies will allow calls from unauthenticated devices (like your Aethra codec)

3. Create a search rule where the Source Zone is "Any", the Pattern Match is AnyIPAddress, and the target zone is Local. If you already have a search rule with AnyIPAddress (i.e. you have a VCS-E and using Indirect method) then you should ensure that the "intra-site" AnyIPAddress search rule is higher priority than the "external" (i.e. VCS-E path) search rule. Also, set the "intra-site" rule to continue on match condition.

HTH

-Bill (@ucguerrilla)

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

Thanks its work fine

ahmashar
Level 4
Level 4

Hi,

1- How do you setup your conference bridges? via TMS?

if TMS manages the conferences then when you setup the conferences, make sure you choose MCU first on the list of participants.

2- Where is Aethra device located on the same internal LAN or on Internet?

as William described above, make search rule with IPaddress dialing and give a higher priority (lower value) on local LAN otherwise send it to traversal zone and have a similar rule on VCSE to dial out with IPaddress. VCSC should be configured with indirect call and VCSE with direct call policies.

regards, Ahmad

Hi  Ahamed ,

Thanks for your response .. changed the external mcu usage in routing option in conference setting and working fine now .

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: