11-21-2012 02:20 AM - edited 03-18-2019 12:10 AM
Hi
We always seem to have problems calling VCS to VCS systems with endpoints via the internet. We're running 7.2 on our VCS and the remote company is running 7.1 on their VCS. Calls connect ok however there are random drops during the session 3 over a 1.5 hour session. I get user busy errors (logged on TMS) when trying to reconnect and I eventually get through after a couple of minutes trying. I've checked the C20 error logs and can find this error - can anyone explain the lines highlighed below? or explain why I'm getting the disconnects?
Thanks
Rod
(The VC call is passing over the internet to the remote system)
Nov 21 07:32:41 (none) main: 3150.48 MC I: RemoteParticipant::configureIncomingChannel: Capability table:
Nov 21 07:32:41 (none) main: 3150.48 H323Call I: h323_call_handler::handleH323IncMode: incoming mode
Nov 21 07:32:41 (none) main: 3150.48 MC I: RemoteParticipant::configureIncomingChannel: Capability table:
Nov 21 07:32:41 (none) main: 3150.48 H323Call I: h323_call::configureIncomingChannelCnf(p=6): Not sending openSessionCnf upon receive mode change
Nov 21 07:32:41 (none) main: 3150.49 DATACTRL I: DataGateCfgReq(ig=5) hdlc=yes
Nov 21 07:32:41 (none) main: 3150.49 DATACTRL I: DataGateCfgReq(ig=5) hdlc=yes
Nov 21 07:32:41 (none) main: 3150.49 H323Call I: h323_call::configureIncomingChannelCnf(p=6): Not sending openSessionCnf upon receive mode change
Nov 21 07:32:41 (none) main: 3150.49 H323Call I: h323_call_handler::handleH323IncMode: incoming mode
Nov 21 07:32:41 (none) main: 3150.50 MC I: RemoteParticipant::configureIncomingChannel: Capset empty
Nov 21 07:32:41 (none) main: 3150.50 H323Call I: h323_call_handler::handleH323IncMode: incoming mode
Nov 21 07:32:41 (none) main: 3150.50 MC I: RemoteParticipant::configureIncomingChannel: Capset empty
Nov 21 07:32:41 (none) main: 3150.50 H323Call I: h323_call::configureIncomingChannelCnf(p=6): Not sending openSessionCnf upon receive mode change
Nov 21 07:32:41 (none) main: 3150.50 H323Call I: h323_call::configureIncomingChannelCnf(p=6): Not sending openSessionCnf upon receive mode change
Nov 21 07:32:41 (none) main: 3150.74 MediaStreamController I: MV::getVCSetting getOutputPortStatus initialized 1
Nov 21 07:32:41 (none) main: 3150.74 MediaStreamController I: MV::getVCSetting localHwCookieHint_ 1 w 1920 h 1080
Nov 21 07:32:42 (none) main: 3150.79 VIDEOCTRL-0 I: Reset flux probe for (outputvideo,2)
Nov 21 07:32:42 (none) main: 3150.80 H323Call I: h323_call::configureIncomingChannelCnf(p=6): Not sending openSessionCnf upon receive mode change
Nov 21 07:32:42 (none) main: 3151.35 MC I: RemoteInputGateImpl::setIncomingModeReport(ig=60,p=6) [Audio (1): aud-off stereo 0k ]
Nov 21 07:32:44 (none) main: 3152.97 H323Call I: h323_call_handler::handleDiscInd(p=6, s=1) Received disconnect indication (Cause: 11:55, h323 cause: 16:55)- RemoteRejected Q850
Nov 21 07:32:44 (none) main: 3152.98 MC I: RemoteParticipant::reevalRefMode(p=6,ch=2) set ref [Video (2): vid-off 0x0@0.0 0k ] q= auto, t60=6000
Nov 21 07:32:44 (none) main: 3152.98 ModesController I: ModesController::resetRateLimit(ch=2)
Nov 21 07:32:44 (none) main: 3152.98 MC I: RemoteParticipant::modeChanged(p=6, ch=2): ModesController wants to run mode: Video (2): vid-off 0x0@0.0 0k
Nov 21 07:32:44 (none) main: 3152.99 H323Call I: h323_call::sendOutgoingModesToStack(p=6): Modes sent to stack: audio: AAC-LD, video: vid-off, duo: vid-off, data: H.224-HDLC
Nov 21 07:32:44 (none) main: 3153.03 H323Call I: h323_call::affirmIncomingDisconnect(p=6): Incoming disconnect affirmed
Nov 21 07:32:44 (none) main: 3153.09 MC W: RemoteParticipant::disconnectTokenParticipant(p=6) No call
Nov 21 07:32:44 (none) main: 3153.09 MC I: Conference::updateCommonCapSet(c=5)
Nov 21 07:32:44 (none) main: 3153.10 IXUser I: iXController teardownIxChannel: Not connected
Nov 21 07:32:44 (none) main: 3153.11 MC I: CapabilityControllerImpl::setCapset() reduced = 0, waitForDuoGate = 1, hasLegacyVideo = 0
Nov 21 07:32:44 (none) main: 3153.14 RTP I: TrafficCtrl: Deleting entry (main): id: 34, tcid: 65568
Nov 21 07:32:44 (none) main: 3153.14 RTP I: TrafficCtrl: Deleting entry (duo): id: 36, tcid: 65568
Nov 21 07:32:44 (none) main: 3153.15 CAMERA I: CamVisca::Ready_doCAMActionReq cameraId=1 actionId=20
Nov 21 07:32:44 (none) main: 3153.16 MediaStreamController I: MV::getVCSetting getOutputPortStatus initialized 1
Nov 21 07:32:44 (none) main: 3153.16 MediaStreamController I: MV::getVCSetting localHwCookieHint_ 1 w 1920 h 1080
Nov 21 07:32:44 (none) main: 3153.18 MediaStreamController I: doAUDIOMIXERREMGATECNF(ms-ig=7) not found
Nov 21 07:32:44 (none) main: 3153.19 DATACTRL I: DataGateRemReq(ig=5)
Nov 21 07:32:44 (none) main: 3153.20 DATACTRL I: DataGateRemReq(og=2)
Solved! Go to Solution.
12-18-2012 03:49 AM
Hi Rod,
It's not easy to lead you to the root cause, why the endpoint disconnects the call, with the information and log summary above.
I would recommend you to open a support ticket with Cisco, and also attach the diagnostics log (with DEBUG level) from both VCSs, if possible, as well as logs from the endpoints in the call. Then we should be able to find the root cause for this problem.
Normally, B2B calls are disconnected because of security, e.g. incorrect firewall configurations or application layer gateways, like H323 fixup enabled etc.
It's also good to exclude scenarios; like is this happening with all endpoint? From every location? To every location? Where are the endpoints registered, and which firewalls etc. does it have to traverse when this is failing.
Hope this helps,
Arne
12-18-2012 03:49 AM
Hi Rod,
It's not easy to lead you to the root cause, why the endpoint disconnects the call, with the information and log summary above.
I would recommend you to open a support ticket with Cisco, and also attach the diagnostics log (with DEBUG level) from both VCSs, if possible, as well as logs from the endpoints in the call. Then we should be able to find the root cause for this problem.
Normally, B2B calls are disconnected because of security, e.g. incorrect firewall configurations or application layer gateways, like H323 fixup enabled etc.
It's also good to exclude scenarios; like is this happening with all endpoint? From every location? To every location? Where are the endpoints registered, and which firewalls etc. does it have to traverse when this is failing.
Hope this helps,
Arne
12-18-2012 05:35 AM
Hi Arne
Thanks for responding. I thought I had closed this thread down. The issue was caused by the default time out values applied to H.225 and H.245 traffic inspection on our Palo Alto firewall.
I increased the timeouts and this resolved the problem.
Thanks
Rod
12-18-2012 05:57 AM
Hi Rod,
I'm glad to hear that you fixed this. Thanks for adding the solution to this thread!
Cheers,
Arne
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide