Ticket :

I have configured a Cisco 2901 router with VWIC3 card as VoIP gateway.

When I throw calls from the IP network (with Asterisk PBX) to the PSTN network, and the call is rejected by the end user, the call end never arrives to my Asterisk PBX.

I can see in logs that the busy code arrives from PSTN to the 2901, but no SIP message is sent to the Asterisk PBX, so it can not know wich was the fail cause of the call.

The Asterisk PBX is connected to GigabitEthernet0/0 and the PSTN connection is an E1 primary trunk.

Scenario & Analysis :

VoIP gateway is configured correctly and all the necessary SIP commands are given.

PSTN is sending Call Fail Codes to the gateway but the gateway is not generating SIP fail codes and sending it to the PBX.

Checked IOS version and comparability for errors.

Normally the cause code mapping between the pstn and sip is set by default.

Tried the commands “signaling forward rawmsg/unconditional”  under “voip service voip”:

Note: “signaling forward rawmsg/unconditional” adds information in the SIP messages payload (183, session progress), but doesn’t generate the SIP message, with the fail cause for PBX, when the end user rejects the call.

Possible Cause & Solutions :

After analysing “debug ISDN q931” , the problem seems to be that the CISCO postpone the forward of the call ends, as you can see in debug messages:

ISDN Se0/0/0:15 Q931: call_disc: PI received in disconnect; Postpone sending RELEASE for callid 0x8028

To solve it  add “voice call disc-pi-off” in global configuration.

With this option enabled the Cisco router sends the SIP message SIP/2.0 486 Busy here. when the disconnects arrives from the ISDN interface.

If you have more info/doubts about this post, pls share it on the comment section #knowledge-the more u give more you gain 🙂

Ticket :

How to block teamviewer on my ASA firewall


Applications like Teamviewer are very resilient in a firewalled environment and can often connect on multiple different ports and protocols. This makes it easy for users to connect without the need for any network configuration, but difficult to stop with a firewall.

The ASA won’t be able to inspect the HTTPS traffic . You could try blocking the DNS lookups for the servers, but the application might then try a hard-coded IP address. You could use a 3rd party device to act as an HTTPS proxy and block the connection that way. However, even with that it’s possible that the application would just choose some other port to use. This is why blocking the application itself is the best choice  through host-based application


There are actually some methods by which you can accomplish this.

1. If your hardware allows it you might want to consider installing a CSC module on your ASA, the CSC will allow you to block a particular category that involves all these remote controll programs:

Category Group: Internet Security

Category Type: Remote Access Program

Definition: Sites that provide tools for remotely monitoring and controlling computers

For further info:



2. We can use another aproach, that is blocking every dns request for the .teamviewer.com and/or .dyngate.com using regular expression

regex TV-RGX “\.teamviewer\.com”

regex DG-RGX “\.dyngate\.com”

class-map type regex match-any TV-CLS

match regex DG-RGX

match regex TV-RGX

policy-map type inspect dns TV-PLC


message-length maximum 512

match domain-name regex class TV-CLS


policy-map global_policy

class inspection_default

inspect dns TV-PLC

service-policy global_policy global

# If you have more info/query on this, let others know #knowledge- more you give, more you gain 🙂

Ticket :

RightFax Server not working – MGCP
I had an interesting scenario where customer logged a case with us regarding their RightFax server not working.
When you dial the fax number from outside, it reaches the gateway and you hear one ringback and then a fast busy.

Scenario & Analysis :

The call flow was something like this: 0XXXX23422 >>>> Birmingham GW  FXO >>> on CCM we have FXO port with number 3422 >> on CCM there was a RP 3422 with a RL pointing towards an Intercluster trunk to The was the Right Fax server.

I could ping which proved no issues between CCM and Right fax server.

I then opened debug voip ccapi inout and observed the Ringback and fast busy tone which was not very helpful.
I then asked the customer if fax calls through any other gateway are working and luckily I found one gateway where they had successful fax calls. 

I compared the MGCP config on both gateways and found one line missing from this gateway which was not working.

The MGCP commands common to both:

ccm-manager fallback-mgcp
ccm-manager redundant-host BELL
ccm-manager mgcp no ccm-manager fax protocol cisco
ccm-manager music-on-hold ccm-manager config server ccm-manager config


mgcp call-agent MICKEY 2427 service-type mgcp version 0.1
mgcp rtp unreachable timeout 1000 action notify
mgcp modem passthrough voip mode nse mgcp package-capability rtp-package mgcp package-capability sst-package mgcp package-capability pre-package no mgcp package-capability res-package no mgcp timer receive-rtcp

mgcp sdp simplemgcp fax t38 ecm
mgcp bind control source-interface FastEthernet0/0
mgcp bind media source-interface FastEthernet0/0


mgcp profile default


The command which was missing was this:
mgcp rtp payload type g726r16 static

added that command and Fax started working

# If you have more info/query on this, let others know #knowledge- more you give, more you gain 🙂

Ticket :

No Calling name Display for inbound calls through h323 gateway

Scenario & Analysis :

if you are dealing with H323 gateways, calling name is being delivered in the Facility IE, and your inbound calling name isn’t being displayed on the phone*

confirme with the carrier that calling name *is* being sent.

have also confirmed, with debug isdn q931, that you are seeing calling name in the debug. It will look something like this:

RX <- FACILITY pd = 8  callref = 0x018C Facility i = 0x9F8B0100A117020101020100800F41524E4F4C4420414D592020202020 Protocol Profile =  Networking Extensions 0xA117020101020100800F41524E4F4C4420414D592020202020 Component = Invoke component Invoke Id = 1 Operation = CallingName Name Presentation Allowed Extended Name = AMY

Typically if you have gotten this far and your inbound calling name is still not showing, you are nearly there.  Adding the h225 display-ie ccm-compatible command should do the trick:
voice service voip
h225 display-ie ccm-compatible

If you don’t see calling name in the debug, then you likely need to enter a few commands to make the Facility IE delivery work. Your serial interface should look something like this:
interface Serial0/0/0:23
no ip address
encapsulation hdlc
isdn switch-type primary-ni
isdn incoming-voice voice
isdn supp-service name calling
isdn outgoing display-ie

Try the above commands if you are seeing something like the debug output below.Also be certain that your switch type supports Facility IE, not all switch types do.

Facility i = 0x9F8B0100A11D02010106042B0C0900801254656C65547261636B204F7574626 F756E64 Protocol Profile =  Networking Extensions 0xA11D02010106042B0C0900801254656C65547261636B204F7574626F756E64 Component = Invoke component, Unsupported operation


I recently did an upgrade from 6.1 to 8.6 and inbound calling name wasn’t a problem on 6.1 without the ccm-compatible command, but after the upgrade calling name only worked with this command added.

I also found this link from 2010  helpful when troubleshooting this type of issue:

Credits: amyengineer.com

# If you have more info/query on this, let others know #knowledge- more you give, more you gain 🙂

Ticket :

MGCP configured on a VG224 gateway not registering with cucm

The status stayed in Registering toward the primary, then would occasionally swap to Registering toward the secondary.

Possible Causes & Solutions :

Most commonly the mistake is to forget to use the fully qualified domain name as the device name in Call Manager. If “ip domain name” is set on the router, be sure to include the domain name as part of your device name when adding your VG224 to CUCM. 
(Pro tip: You can see what the FQDN name should be in the #show ccm-manager output.)

My “mistake” was simply this – I was trying to get the VG224 to register, but I hadn’t added any configuration to the ports. 

In VG224 the ports must be configured first before adding to CUCM

# If you have more info/query on this, let others know #knowledge- more you give, more you gain 🙂

Ticket :

I had an interesting case where calls over ICT trunk would connect but then either party will not hear each other for 8-10 seconds.

The issue was first reported from US users trying to reach UK users over an Intercluster trunk (Non-GK).

Scenario & Analysis :

Both clusters had two call managers version 8.0.3. The whole issue started after US call managers were re-located and their IP addresses were changed. The ping response between two clusters was about 145ms which wasn’t too bad.

I did a test call to a UK phone by connecting my IP communicator to US. I did a CFA on UK phone to Voicemail and could see on my communicator that the call has connected but I didn’t hear the first 10 seconds of the voicemail.

I made a similar test by calling a UK phone but this time asked someone to answer it. The call was connected fine but we couldn’t hear each other for like 10 seconds. After 10 s it was all ok.
The issue was bit different when someone from UK to US would call. In that case call will connect 70% of the time with no issues but 30% of the time it will connect and drop.

I had to run through different CCM traces on both clusters to find:

Also, the SDL logs indicate a significant delay in the TCS being sent out.This shows the H225 part of H323 is fine but H245 was taking time. I did reset of trunks, changed Call manager priorities etc but that didn’t help

Possible Causes & Solutions :

H245 Features negotiation was taking time.

I then enabled ‘Outbound FastStart’ for all outbound calls from US to UK and enabled the same for inbound calls on UK trunk. This fixed the issue.

I had to provide a MTP resource under MRGL at US trunk as FastStart needs MTP

Notes :

A little about how ‘Outbound FastStart’ works from Cisco:

Outbound Calls:: Enable Outbound FastStart   Check this check box to enable the H.323 FastStart feature on outgoing calls. By default, the check box remains unchecked for the H.323 gateway or trunk. When you check the Enable Outbound FastStart check box, you must set the Media Termination Point Required, Media Resource Group Lists, and Codec for Outbound FastStart.

Inbound Calls: Enable Outbound FastStart   Check this check box to enable the H.323 FastStart call connections on incoming calls. By default, the check box remains unchecked for the H.323 gateway. For intercluster calls, you must check the Enable Inbound FastStart check box on Cisco CallManager servers in other clusters for the outbound FastStart feature to work.

If you updated Cisco CallManager 3.3(2) servers in other clusters with support patch B, do not enable inbound FastStart because 3.3(2)spB does not support the inbound FastStart feature over intercluster trunks

# If you have more info/query on this, let others know #knowledge- more you give, more you gain 🙂

Ticket :

Came across an MoH issue for a customer where the file was missing from Subscriber.


As you may be aware that an MoH file should always be uploaded across the cluster on each server to work properly.

If you only upload the MoH file on Publisher then it won’t be replicated on other servers. You can check that by going into those servers > Media Resources > Audio Source file.


downloaded the MoH file from Call manager and then uploaded it on Sub. The file has different formats like.alaw ulaw g729 etc. Once you download it, you can change it back to .wav file.
This is  how I downloaded it. 

admin:file list activelog mohprep/* [this will show you all files in MoH dir]

admin:file get activelog mohprep/  [this will Download the file

# If you have more info/query on this, let others know #knowledge- more you give, more you gain 🙂