Unity Connection 7.1.5 detects leading silence timeout from PSTN callers

[Waruna Wijewardena]

Hi Everyone,

I have setup Unity Connection 7.1.5 cluster with CCM 4.3 cluster.

Caller from Internal CCM partitions would be able to keep messages as usual , and Unity connection detects those are new messages &  called user is able to retrieve them . This is normal condition.

When PSTN external caller call ,the greeting played by Unity connection, after the beep it detects silence ,so caused not to record the messages , eventually leading silence timeout reached .. so called users does not get MWI on , so new messages for him in the database..

Cisco TAC also troubleshooted this and they identified no messages saved in the database. Captured ip packets from unity connection shows packets are sourced from Hardware conference Bridge ( cisco 2800 series router) . This is pretty unusual.. It was expecting from the voice gateway..

We isolated the conference bridge from network. then pstn callers are able to keep messages as normal. UC records the message & playback for called users ..Then we plugged conf bridge back , It continued to work for sometime ok  and then detected the same issue like earlier..( re-registering the conf bridge i suppose)

Could anybody guess ,where is the malfunction happening & cause UC get the silence from PSTN caller.

Waruna

[Craig Cooper]

Hi Waruna,

I suspect the Conference Bridge DSP resource is also a Transcoder or Media Termination Point (MTP).   It could be that the PSTN gateway (if it's H.323 or SIP) or, if you've integrated Cisco Unity Connection (CUC) with a SIP Trunk instead of using SCCP, the CUC server, have an issue when using that particular DSP resource as an MTP.   Alternatively, if the PSTN gateway and CUC are in Regions that require the use of a Transcoder, then it's invoking the DSP resource that way.    Either way, this could either be a routing issue, causing one way voice, between the DSP resource and either CUC or the gateway, or possibly an issue with the DSP's themselves on that DSP resource.

More troubleshooting would definitely be required to isolate the cause.   I suspect if you collected a sniffer capture at the CUC server the RTP stream from the DSP resource would either not be arriving, or would contain nothing but silence.

Kind regards,

Craig

[Waruna Wijewardena]

Hi Craig,

Thanks for the feedback.

This network has 4 Voice gateways , calls coming from 2 of those gateways ( Cisco 7206VXR)  gives the problem .,Those are with H323 gateway control protocol.

The other Voice Gateways ( Cisco 2800)  which are on SIP trunks with CCM . Calls coming via SIP don't have this problem.

Cisco TAC captured the audio file from unity . I attached here it , It's silence message for UC ..

regards,

Waruna

[Waruna Wijewardena]

Hi,

Graph analysis say RTP stream established between conf bridge & UC.. ( Why voice gateway not coming into the picture)

So once HW bridge not in the network ,, it works means.

DSP resource from HW conf bridge invoked instead Gateway's .

Pls refer attached .

Conf Bridge IP -172.20.100.9

VGW IP- 172.20.100.2

UC-192.168.127.11

CCM- 192.168.127.5

Regards,

Waruna

[Craig Cooper]

Hi Waruna,

Please make sure you have a voice class codec set up, on the H.323 gateways, and applied to each of the VoIP dial peers; to ensure each of those gateways can use the codecs required by CUCM, rather than CUCM having to invoke a transcoder.

e.g.

voice class codec 101

codec preference 1 g711ulaw

codec preference 2 g729r8

!

dial-peer voice 100 voip

voice-class codec 101

!

Please also try unchecking "Media Termination Point Required", if you have this check against the H.323 gateway configuration pages in CUCM... as having this checked means that CUCM needs to allocation an MTP for each and every call from the gateway (which is not normally necessary these days).

Kind regards,

Craig