cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1495
Views
5
Helpful
7
Replies

2 MCU and VCS Expressway routing problem

Jose_DA-SILVA
Level 1
Level 1

Hello all,

We have a design with a VCS control cluster (2 members), a VCS Expressway cluster (2 members) and a couple of MCUs (H.323 registred on VCS Control cluster with the same prefix : 90).

Each Expressway has a public IP and incomming calls from outside can only be routed to MCUs :

901000@172.1.1.1 for MCU_1 and 902000@172.2.2.2 for MCU_2 (we don't have external DNS resolution).

I put a Transform in VCS Expressway to change 901000@172.1.1.1 to 901000@video.domain.fr and 902000@172.2.2.2 to 902000@video.domain.fr.

The problem is when someone calls 901000@172.1.1.1 sometimes (randomly) the call is routed to MCU_2 (instead of MCU_1) and so the caller see the auto attendant.

The same occcurs when calling 902000@172.2.2.2 (MCU_2), sometimes the call is routed to MCU_1.

Any idee on what can causes this or a way to do it working well ?

Thanks for help.

José

1 Accepted Solution

Accepted Solutions

I still think that seperate prefix's would work, but here's another couple of ideas:

Are the incoming calls that aren't working possibly using SIP that's being interworked to H323, or are all incoming calls definitely H323?

If you want to keep it pure H323, you could maybe just have a search rule/transform on your VCS-E that changed 90.....@domain.com to an E164 e.g. 90..... and had a search rule on your VCS-C that told 90..... to stop at the local zone.

I also notice that you are directing calls to [number]@MCU-IP - have you tried directing all calls to [number]@VCS-C IP instead?  If the VCS holds a registration for a number, it should be able to route it accordingly.

View solution in original post

7 Replies 7

My guess would be because they are both registered with the same prefix.

Try changing your prefix's to '901' and '902' instead and see how you go, that way VCS shouldn't get confused about which MCU to send the call to.

Thanks for reply Nick,

Having the same prefix for both MCUs is a good practice as mentionned in Cisco guides.

Each conference is automaticaly registred in VCS with its own H.323 alias, so normally the VCS dont should be confused.

Other idee ?

Regards

José

It clearly depends what you are trying to archive.

Which guide did you quote? I only recall some older guide, I think it was about mcu scaling/redundancy or  multiway

mentioning that. Current deployment guides might more point you to use SIP which would not support such

a prefix anyhow.

It all depends onwhat you want to use:

* TMS booking

* Multiway

* pre configured conferences

* ...

What protocol you use

* sip

* h323

Which kind of infrastructure you have

* vcs

* cucm

* mcu

* tps

* conductor

* tms

...

As you see, many parameters/options,that list does not even claim to be complete,...

Some features might also not work together and require dedicated resources for it.

In general it should work with h323 that the same number will be routed by the vcs to the same MCU

as long as resources are available.

But I am not 100% sure if this behavior is guaranteed over all VCS software releases and if

additional action, like search rule or transform  rewrites can mess things up.

I would also say both VCS should be registered to the same VCS and I am not sure how well

it performs on a VCS-Cluster (especially with address rewrites)

You also did not mention what kind of MCUs you have, that and their software version and configuration

might also have an impact.

The whole stuff would only work with H323, so if the number is also reachable via SIP towards the mcu

it might break it as well.

Long story short, use different prefixes like Nick suggested

and if you need a more clever resource allocation a Cisco Conductor together with recent Cisco MCUs

Please remember to rate helpful responses and identify

Hello Martin,

Guides i was talking is here :

http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/config_guide/Cisco_VCS_MCU_Connection_Using_H323_Deployment_Guide.pdf

or here :

http://www.cisco.com/en/US/docs/telepresence/infrastructure/articles/mcu_configure_load_balancing_kb_93.shtml

MCUs are Codian 4505 4.3(2.32)

VCS Control & Expressway X7.2.1

Protocol used : H.323 only

We have a TMS (12.6.2) but is not used to book conferences.

It works fine with internal calls from endpoints (dialing E164 alias of conference) but not with external endpoints (not registred).

Thanks

I still think that seperate prefix's would work, but here's another couple of ideas:

Are the incoming calls that aren't working possibly using SIP that's being interworked to H323, or are all incoming calls definitely H323?

If you want to keep it pure H323, you could maybe just have a search rule/transform on your VCS-E that changed 90.....@domain.com to an E164 e.g. 90..... and had a search rule on your VCS-C that told 90..... to stop at the local zone.

I also notice that you are directing calls to [number]@MCU-IP - have you tried directing all calls to [number]@VCS-C IP instead?  If the VCS holds a registration for a number, it should be able to route it accordingly.

You are right !

I'm confused with "MCU Prefix" and "Service Prefix".

"MCU prefix" must be different.

"Service Prefix" can be the same for adhoc conference load balancing.

With differents MCU prefix it works as expected.

Thanks to taking the time.

Regards

No problem, glad to hear it worked