Mental wanderings of a lost mind
Some of the older UC520 systems were shipped with other firmware versions for the 521 and 524 phones. It seems there are a number of feature upgrades with the newer firmwares. One of which is the ability to enable the switch port on a 524SG model phone.
You should load at least 8.1.13 or higher firmware on the system.
Don’t forget to setup the tftp-server and load commands so that your phone updates.
There are several ways to configure a gateway for use in Cisco’s Unified Communications Manager. MGCP, H.323, SIP. Each has it’s own benefits and drawbacks.
Here are some of the big issues for me :
I know there are other issues here, but these were the important ones for me. MGCP provides the centralized management, but not the other features. Most importantly Call Preservation. This is why I rarely use MGCP for VoIP deployments.
To configure a SIP gateway for a Cisco Unified Communications Manager there are two steps.
This part is fairly easy. Here I’m assuming that you already have your PRI configured.
voice rtp send-recv
!
dial-peer voice 1000000 voip
incoming called-number .
dtmf-relay rtp-nte
!
dial-peer voice 9000100 pots
 destination-pattern [2-9]……
 no digit-strip
 port 0/0/0:23
dial-peer voice 9000200 pots
 destination-pattern 1[2-9]..[2-9]……
 no digit-strip
 port 0/0/0:23
You could have more dial-peers, but this is enough to get started.
Go to the Device -> Trunk menu.
Click on the Add New button
Select SIP Trunk as the type and click the Next button.
There are a few fields here that need to have information in them:
There are two other settings here to be aware of:
Media Termination Point Required
This should be unchecked. While some SIP gateways may require this, it’s my experience that it causes more headaches than anything else. It also causes all outbound calls to consume an MTP resource or Transcoder in some configurations.
DTMF Signaling Method
You might be wondering why DTMF signaling makes any difference… here’s why: On a Cisco Unified Communications Manager even if you have MTP requirements disabled, if the DTMF relay types do not match (or are not compatible) the trunk will dynamically allocate an MTP resource which will act as a DTMF translator converting one method to another. For maximum compatibility use : RFC 2833. You’ll see that the gateway configuration above uses RFC 2833 for it’s DTMF relay with the following command : dtmf-relay rtp-nte
Now that our system is configured, we can make calls out. You’ll find that everything seems to work fine. There are a few cases however where it will not. An example of this is when the telco sends an announcement message prior to connecting the call. A few common uses of this method are prompts for account codes, incorrect dialing messages, etc.
SIP Trunks on Cisco’s Communications Managers create ringback locally and wait for the ISDN Connect message before actually connecting the IP media stream. So if you receive a message from your telco before their switch sends you the Connect message, you will only continue to hear ringback on the phone until the telco terminates the connection.
An easy way to fix this is to require that all calls use a Media Termination Point. I pointed out above that I don’t recommend this. It drives cost up, makes troubleshooting more difficult and can cause issues with faxing.
The better way to fix this is simple, but I’m going to go into a little background explaining the why.
Whenever your telco sends an announcement message, they will flag the Progress Indicator of the Q.931 message with an 8 (Usually.  Some telcos may do this a little differently) Your Cisco gateway will take this indicator and generate a SIP 183 Session Progress message which contains an SDP with connection parameters. This tells the Communications Manager that there is possibly some in-band data that the user may be interested in. The problem is that the Communications Manager will ignore this and continue to play the ringback tone instead of letting you hear the message.
To allow the Communications Manager to react to the 183 messages go into System -> Service Parameters, select your server then select the CallManager service. Scroll down and find the Clusterwide Parameters (Device – SIP) section. Find the SIP Rel1XX Enabled parameter and set it to True. This parameter tells the Communications Manager to send ACK packets back in response to any 100 series SIP message received. The IOS command above, voice rtp send-recv, is used to connect the media path in both directions instead of just a single direction.
That’s it! Press the Save button and you’re done. Now when the system is signalled from the ISDN network it will properly cut through the media path and your users will hear any possible announcement messages.
A big drawback to the previous post is that ATAs cannot be used for fax machines. The reason for this is because the gateway, when sensing a fax tone, immediately moves into T.38 mode. The ATA is unable to handle T.38 and so tries to continue in g.711 mode. Since these two are incompatible, the call will fail.
However, even Cisco recommends that a fax machine be connected to a VG224/VG248 or FXS card connected to a router. These devices support more than just straight passthrough for fax machines.
Fax issues are the bane of my existance. It never ceases to amaze me how difficult it can be to get them to work sometimes.
A brief history of fax machines :
Years ago, the ancients developed a technology for sending images across standard telephone lines. Man called it Fax.  Somewhere around the time man discovered fire, this technology was found to be obsolete. But for some reason continued to use it. Even with newer high-speed data connections capable of transmitting color images of much greater detail at speeds thousands of times faster with less error, there are some that cling to the fax technology like a floating piece of wood in piranha infested waters. The log won’t save them from the piranha, but they cling to it anyway.
If, for some unholy reason, you must use faxes on a VoIP network. Fax relay is the way to go.
The problem is that it’s not 100% compatible with callmanager 4 and 5. Cisco got this fixed with version 6 and above.
In order to make fax relay work properly on MGCP controlled voice gateways, the following command should appear in the config:
mgcp fax t38 gateway force
This command will cause the gateways to negotiate the fax-relay themselves rather than rely on the call processing system (callmanager).
If you need to do the same thing with H.323or SIP the command is
voice service voip
fax protocol t38 nse force
And just like that… it’s 2 weeks have passed. I can’t believe how much I’ve had to do at home and work. I really mean to keep this updated daily, but somehow things just make their way on top of the priority list.
This last week we were having issues with some VG224s interoperating with fax machines. One technician noted that the line voltage was only 38 volts. Many fax machines, particularly the older ones, and other devices do not work properly or at all with voltages as low as 38.
The fix for this is simple, the following command placed under the voice-port configuration will increase the idle voltage of the VG224 port to a more acceptable level.
alt-battery-feed feed2
Recently I was asked by a customer to deliver .wav files to the inbox of their mail server from a Unity Connection server. Well, by asked I mean that the salesperson promised it to them and I had to find a way to deliver it.
I came up with an idea to do this… it didn’t work. But the idea was sound, it just needed a little tuning to make it work right.
I used a Linux server with PHP and Postfix to make all the magic work. It also helped that none of the customers used Unity Connection’s web client.
I created aliases on the Postfix server redirecting users to a custom script. The script then logs into the Unity Connection system and retrieves the .wav file and retransmits it as a new message to a specified email address.
I’m still polishing it up a bit, but it’s fully functional and delivering .wav files to our inboxes as expected. When I get it to a more flexible format I’ll release it on this site. For now, if you are interested and don’t mind a ‘beta’ version of the software, let me know and I can provide you with a copy and instructions for use.
Here’s the solution to Challenge 2
Now the problem… I’m still working on Challenge 3, but can barely keep my eyes open. To ensure the quality of Challenge 3, I’ll be posting it tomorrow. Sorry for the delay.
Here’s the answers to Challenge 1 : Answers 1
And here’s the next one, Challenge 2 : Challenge 2
I had the opportunity recently to troubleshoot some erratic and intermittent UC500 problems. The issues were everything from dropped calls to echo on some calls.
It seemed that two phones were actually bad and had to be replaced. But the real fun came when I checked out the log:
 070782: Apr 9 xx:xx:xx.xxx: %IP-3-LOOPPAK: Looping packet detected and dropped -
src=192.168.1.101, dst=192.168.1.1, hl=20, tl=229, prot=17, sport=138, dport=138
in=Vlan1, nexthop=192.168.1.1, out=Vlan1
options=none -Process= “IP Input”, ipl= 0, pid= 75, -Traceback= 0×80E38860 0×8131DCDC 0×8131F3C4 0×81560EC4 0×815611E8 0×81562A64 0×81306F24 0×8130ADD0 0×8130BC04 0×8130BCF4 0×8130BEB8 0×801778EC 0×8017A1EC
These entries were filling up the log fairly quickly. The first thing I noticed was that all the packets had the same port numbers: netbios. At this point I checked the interface configurations and found a configuration like this:
interface Vlan 1
ip address 192.168.1.1
ip helper-address 192.168.1.1
I can’t think of any good reason the helper-address would be pointed to itself, so I removed it. This resolved all the issues the customer was having outside of broken phones.Â
Simple fix, but very interesting impact on system functionality.
I’ve decided to start posting weekly practice labs. I hope everyone will enjoy studying them as much as I am enjoying writing them.
The answers will be posted the following week.