Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Mx300 G2 on VCS can not establish call with CUCM device

Hi Folks,


I've got a really strange one. Our company has VCS-C and CUCM integration, and there are a handful of MX300 registered to VCS and the calls between them and CUCM devices have been fine. Last week we put in a MX300 G2 which registered to the same VCS-C, but it could not establish either audio or video call to CUCM devices, but the other direction works fine. The search history indicates a pattern not found, but the locate tool indicates that my search rules work ok (surely so as the other MX300 are ok).By looking through the VCS log, there was a 503 service unavailable error after 180 ringring, and then I could see a 404 not found. I wonder how is it that MX300 G2 behave differently than MX300? 

MX300 (VCS) <--> CUCM devices

MX300 G2 (VCS) <---CUCM devices


Any suggestions is greatly appreciated! VCS log attached.





How are callsMX300 (VCS) <=>

How are calls

MX300 (VCS) <=> MX300 G2 (VCS)

Are these calls successful?

New Member

Yes, LC, these calls are

Yes, LC, these calls are working fine.

New Member

Hi,  I cant find much details



I cant find much details but wondering if someone can guide me into right direction.


we recently got MX300 and have successfully registered with our CUCM using SIP protocol.

our parent company uses VCS. we need to be able to register to both VCS using H323 and CUCM using SIP. It registers fine however we can't seem to differentiate outbound calls.

Now if we try to reach the device at VCS using H323, we cannot do that. All outbound calls seems to follow SIP to CUCM.

If we remove SIP configuration then we can successfully call devices registered at VCS.


any help will be greatly appreciated.

VIP Green

Hi Ali,Your question is a

Hi Ali,

Your question is a little off topic of the original post, and really should be its own seperate discussion, but I'll try to answer it briefly below.

Firstly, your endpoint should only be registered to one Call Control platform at a time, either the VCS, or the CUCM, not both.

The correct way to have calls between those devices registered to your CUCM and those registered to the VCS at the parent company is to put in a link between the VCS and the CUCM.

I suggest you have a look at the Cisco VCS and CUCM Deployment Guide for some ideas on how to achieve this.

Please remember to rate responses and to mark your question as answered if appropriate.

Please remember to rate responses and to mark your question as answered if appropriate.

Does it make a difference if

Does it make a difference if you use SIP/TLS instead of SIP/TCP when registering the endpoint?


Did you check the logging of the endpoint as well? (log output + xconf and xstat) could be interesting, incl the trace.


At the moment I would wonder if its either some application layer gateway which locks something up or if it could be some media encryption setting (or something else ;-)




Please remember to rate helpful responses and identify

New Member

Hi MartinWe dont currently

Hi Martin

We dont currently have TLS in place, so I just simply turned off TLS in the SIP configuration in VCS.

Here is a snippet from the console logs:

393965.11 SipStack I: SipDialog(ui=53,s=85) sendInviteRejToStack (404:Not Found)
393965.11 SipCall I: sip_call_handler::handleSIPMCallRej(53/85/-1): Call rejecte                                                              d (cause: Not Found)
393965.12 MainEvents I: CallDisconnectRequested(p=53) remoteURI='sip:25835@onene                                                              t.aib.pri' cause=[normal('') 'LocalDisconnect']
393965.12 MainEvents I: ParticipantLeftConference(c=50,p=53)
393965.14 MainEvents I: CallDisconnected(p=53) remoteURI='sip:25835@onenet.aib.p                                                              ri' causeToLocal=[fail_network_rejected('Call party not registered') 'NetworkRej                                                              ected'] causeToRemote=[normal('') 'LocalDisconnect']
393965.20 MC I: CapabilityControllerImpl::setCapset() reductionLevel = 0, waitFo                                                              rDuoGate = 0, hasLegacyVideo = 0


so it looks like that the MX300 G2 thought the dialed URI is not a registered endpoint? The search history keeps showing up "not found". I have attached the xstat and log output log.





New Member

Came across the following: It

Came across the following:


It looks like the VC unit does not have the correct packet size on the codecs



08:20:59.149 |DET-MediaManager-(1294272)::preCheckCapabilities, region1=Default, region2=VIDEO_REG,


Pty1 capCount=9 (Cap,ptime)= (25,40) (4,40) (2,40) (86,60) (15,60) (16,60) (11,60) (12,60) (257,1),

Pty2 capCount=4 (Cap,ptime)= (4,20) (2,20) (11,20) (12,20)|1,100,63,1.227023600^^*


In CUCM the Packet size is set to 20 whereas on the VC unit they are set to 40 or 60... 


Has anyone come across the message above?




New Member

The case is resolved.

The case is resolved. Although there hasn't been much response here, I thought it'd be still a good idea to post up the solution in case anyone else ran into the same:

MX300 G2 sends out the SIP invite with a IX mline, and such is not supported on CUCM 8.6.x and earlier. Therefore the solution is to go into the VCS CUCM zone and turn on the IX filter. That resolved the issue.




VIP Green

Please note, if you have the

Please note, if you have the IX filter turned on, there is a security vulnerability, cisco-sa-20141015-vcs, that you should take notice of.  You should, as suggested in the SA, upgrade your VCS to software version X8.2 or later.

Please remember to rate responses and to mark your question as answered if appropriate.

Please remember to rate responses and to mark your question as answered if appropriate.