#29 VoIP Gateway doesn’t generate SIP fail codes to PBX,when a PSTN call is rejected by user

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 🙂

#28 How to block Teamviewer/RDP on Firewall

Ticket :

How to block teamviewer on my ASA firewall

Analysis:

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

Solution:

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:

http://www.cisco.com/en/US/products/ps6823/index.html

http://www.cisco.com/en/US/docs/security/csc/csc63/administration/guide/csc4.html#wp1065979

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

parameters

message-length maximum 512

match domain-name regex class TV-CLS

drop

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 🙂

#27 : MGCP Right Fax server not working

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 192.168.10.39. The 192.168.10.39 was the Right Fax server.

I could ping 192.168.10.39 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 192.168.10.25 ccm-manager config

!

mgcp
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

Solutions:

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 🙂

#26 : No Calling name Display for ISDN calls

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
h323
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

Notes:

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:
https://supportforums.cisco.com/docs/DOC-8873

Credits: amyengineer.com

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

#25 : VG224 MGCP gateway not registering with cucm

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 🙂

#24 : CUCM 8.0.3 -Calls over ICT have delayed voice

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 🙂

#23 : Downloading MOH file from Pub to Sub

Ticket :

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

Analysis:

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.

Solutions:

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 🙂

#22 : SIP Trunk:CME Call Forward to Internal Extension not Working

Ticket :

CME Call Forward to Internal Extension not Working

Came across an interesting issue for a Swiss customer where they were having problem with Call-forward to an internal extension on their CME systems.

Scenario & Analysis :

Call-forward to an internal extension seems quite straight-forward so I checked how telephony-service is configured and found both call-forward patterns as well as transfer-pattern were configured as .T .. so no real issue there.

Customer added that it use to work fine before but not working anymore. After asking few questions I found that they recently migrated from ISDN to a SIP provider so all incoming calls are coming on SIP while I was thinking it’s all ISDN.

Ran our usual ccsip all, dial-peer all, ccapi inout debugs and found that when call is getting forwarded from 608 to 612, we are getting and then the call was getting disconnected.
Debug msg was showing this:

“SIP/2.0  302  Moved Tem porarily ”
When a call comes in on an SIP trunk and gets forwarded (CFNA / CFB / CFA), then the default behavior is for the CME to send the 302 “Moved Temporarily” SIP message to the Service Provider (SP) proxy.

Sometimes provider may not support this and that was the case in this problem. Same issue is for Transfer as by default CME sends a SIP REFER message to Service Provider (SP) proxy and in this case SP was not able to handle it well.

I decided to configure the following commands before going to carrier as I was trying to disable this default behavior of CME.

!
voice service voip
no supplementary-service sip refer
no supplementary-service sip moved-temporarily
!

This fixed the issue without logging any ticket with carrier as I changed the behavior of CME. Now when call is forwarded to 612 I was getting this instead of 302 Moved Temp

SIP/2.0 180 Ringing

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

#21 : EIGRP finding AS value of an inaccessible router

Ticket :

If you have ever wondered how to find out an AS number of an existing EIGRP process on a router which is not accessible.

It is simple to get the information if you have access to the router – but what to do if you do not have access and want to join the EIGRP process with a new router.

Solutions :

First you need a direct connection with the router running the EIGRP process you want to join

Now we start an EIGRP process on our router (which we can control) and choose a random number for the process. Without that, our routers won’t start chatting with each other over EIGRP

Next step is to create an ACL to filter the packets – this creates less information overhead

access-list 103 permit eigrp any host 224.0.0.10

Using the created ACL we start our debug

debup ip packet detail 103

We do get the IP address of our EIGRP neighbour using the debug ( or we can get the same info using cdp command)
This information is used to create a new ACL
Note: that is done to do not overload the router with too much debug information our second ACL to get more but filtered information by including the IP from before

access-list 102 permit eigrp host x.x.x.x host 224.0.0.10
if everything is set-up properly we can start the next debug without killing our router

debug ip packet detail 102 dump
Now we do get something like the sample output below:

CoreRouter#debug ip packet 102 dump
IP packet debugging is on (dump) for access list 102
CoreRouter#no debug all

*Mar 8 06:32:11.580: IP: s=150.150.15.15 (FastEthernet0/0.1), d=224.0.0.10, len 60, rcvd 2
07DF1A00: 0100 5E00000A ..^…
07DF1A10: 001BD495 A8E80800 45C0003C 00000000 ..T.(h..E@.<….
07DF1A20: 015832FB 96960F0F E000000A 0205EE36 .X2{….`…..n6
07DF1A30: 00000000 00000000 00000000 00000096 ……………
07DF1A40: 0001000C 01000100 0000000F 00040008 ……………
07DF1A50: 0C040102 …

The line with the leading zeros is the one we need:
07DF1A30: 00000000 00000000 00000000 00000096 ……………

Take the value after the double point, start your on-board calculator and convert the number from HEX to Decimal and you do have the AS number of your neighbour – in this case it is 150.

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

#20 : Call Transfer Override

Ticket:

call forward/transfer override

I have 3 phones with lines – 39100, 39101 and 39102 all in same pickup group/partition/CSS.

If I do a call forward all on 39100 to 39101 and then make a call from another phone, 39101 rings which is fine. If I answer on 39101 and then transfer back to 39100 – all is OK as I have the transfer override set to true.
However, if I do a pickup on 39102 when 39101 is ringing and then try to transfer back to 39100 it fails with re-order.

Is there a way to overcome this?

Analysis:

What is Transfer override?

This feature was added around the release of CUCM 6.x Cisco Unified CallManager provides a service parameter (CFA Destination Override) that allows the administrator to override Call Forward All (CFA) when the target of the CFA calls the initiator of the CFA, so the CFA target can reach the initiator for important calls.

In other words, when the user to whom calls are being forwarded (the target) calls the user whose calls are being forwarded (the initiator), the phone of the initiator rings instead of call forwarding back to the target. The override works whether the CFA target phone number is internal or external.

When the CFA Destination Override service parameter is set to False (the default value), no override occurs. Ensure the service parameter is set to True for CFA override to work
CFA override only takes place if the CFA destination matches the calling party and the CFA Destination Override service parameter is set to True. If the service parameter is set to True and the calling party does not match the CFA destination, CFA override does not take place, and the CFA remains in effect.

Solutions:

For this problem,  you can create a second number (39104) on the second button on the phone’s and forward to this number

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