No SIP Audio when connecting to Cisco Meeting Server

[cHrome08]

Hi Guys,

I have 2 cisco meeting server (CMS) which is running fine.
We have a connection from our Avaya VOIP system that will divert calls internally to the CMS server via CUCM.
So in a case where a user dial the extension 1220, the traffic will be route from the Avaya -> CUCM -> CMS.
This is working fine for the 2 space that was created by the network engineer before me.

So, the organisation request to add in another 3 more space and I have configured it.
I can confirm that the routes from the CMS to the ExpW C and vice versa is set up.
Also added the route to the new extension assigned to the new space in my CUCM and its working fine too.
However, I recetly find a strange issue and would like to ask for assistance.

When I dial in the different extension, the traffic will be as below:-

Ext: 1221 -> Space 1 -> SIP traffic will go towards CMS1 and audio is working fine

Ext: 1222 -> Space 2 -> SIP traffic will go towards CMS1 and audio is working fine

Ext: 1223 -> Space 3 -> SIP traffic will go towards CMS2 and audio is not working

Ext: 1224 -> Space 4 -> SIP traffic will go towards CMS2 and audio is not working

Ext: 1225 -> Space 5 -> SIP traffic will go towards CMS2 and audio is not working

When i take a look at the call logs in CMS2, I saw that the incoming SIP call in CMS2 will always have no audio under the incoming media and outgoing media (as attached).
I was wondering if anyone has ever encountered this issue.
Thanks.

Regards,

Han

[Wayne DeNardi]

If you set up another space on CMS1 do you still have the "no audio" issue, or does it work properly on there?

What happens when you add a space from CMS2 to a call to a space on CMS1?  Does the audio work between the two?

These are some ideas to help you determine where you may possibly have a call routing or firewall issue between your devices.

[cHrome08]

Hi Wayne,

Thanks for your response.
I saw a bit of a pattern though when the issue occurs.
I have 3 CMS server with 2 of them being a callbridge.
Lets call this CMS1 and CMS2.
CMS3 is there for database replication purposes.

So the SIP from Avaya will go via Avaya -> CUCM -> CMS.
CUCM has SIP trunks to both Avaya and CMS.
CUCM SIP trunk to CMS will prioritize the connection to CMS1 first before proceeding to CMS2.

I have a total of 5 space, lets call this Space1, space2 etc..

When I dial into Space1,2 and 4, the call will go to CMS1. (I can see this via WebGUI Status->Calls page).
When I dial into Space3 and 5, the call will go to CMS2 (this is where the audio issue occur) <- Not too sure why this happen since the priority of the trunk is set to CMS1 first.

What I noticed is that on the Call Status of CMS2 (for Space3 and Space5), the incoming and outgoing media will always say No audio.
Whereas, for CMS1 (which is working fine), the incoming/outgoing media is set to PCMA.\

There is no firewall in between as its within the same subnet (L2 communication) between the CMS and CUCM.
Sorry for the long explanation.

Can you tell me how to do the following?

"What happens when you add a space from CMS2 to a call to a space on CMS1"Thanks.

Regards,

Han

[Patrick Pettit]

I'm not sure if you are up to it, but seeing a sip trace on non working CMS Server would help.  If no FW between it and CMS 2, maybe some sort of MTP getting a hold of something perhaps.  I can only venture a guess.  Anyhow, if the connection in IP address in the invite from endpoint is the IP of the endpoint/phone and server in the 200 ok answer is its IP address (callbridge listening interface), then media should go between the two. You can pcap both places to see if media is being set to the appropriate place and if endpoint is sending media to CMS and you don't see it in CMS pcap, have to check network to see where its getting lost.  

[cHrome08]

Hi Patrick,

I have opened up a TAC case.
Originally, I have CMS server V2.3.7 installed but has since upgrade to V2.9.1 as advised by Cisco TAC.
However, issue still exist after the upgrade.
I have found another pattern though.
If the cospace doesn't have PIN/passcode, the call will go through.
MTP has been disabled on the CUCM trunk towards the CMS.

TAC has taken the logs/trace from CUCM as well as the CMS server and is investigating further.

Will update everyone once available.
Thanks.

Regards,

Han

[Patrick Pettit]

Oh ok Han.  Thanks for letting us know.  

One thing I want you to look at, which is wrong to me is that if you look at interface a and b on both your servers and perhaps on the db only server to (I don't see a log for this box), the two IP's are on the same subnet.  

I'd suggest you take a look at this.  Having two interfaces on the same subnet will cause you problems.  Not saying it will fix this, but the configuration is incorrect and should be resolved. 

Do a double check on all your services.  Whatever services you have running on B may need to be moved.  For these servers, does look like dbclustering is on interface B.  You may want to ask TAC the question on how to reassign this to interface A.  It may involve taking down the cluster, removing interface B from the VM's and re initializing and rebuilding on A.  

And the reason why I say B and not A is that A looks to be the default interface and B is not.  I hate for other issues to come up because of this and its not a good idea or recommended to have 2 IP's assigned on the same subnet on two seperate interfaces.

For the no audio issue, have you tested this with a phone on CUCM to see if the same problem persists?

VR

P2

[cHrome08]

Hi Patrick,

Yeah, I have 2 interfaces running on the each CMS server.

Interface a is meant for communicating for audio/video purposes.
Interface b is meant for database replication.
And you are right that both interface a and b are in the same subnet (was wondering how did you get this info too, lol)

I will take a look at making the IP address change for interface b so that it will be unique for the communication between the CMS for the database server only.

As for the audio issue, it seems like the problem is caused because of the different region that is set on the CUCM MTP configuration.
The MTP configuration is set to default region whereas the trunk to a different pool which is set to a different region.
Changing the MTP configuration on the CUCM end to the correct region fixed the issue.
Hope this might help someone else in the future