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.
Here’s the scenario: We have a Cisco Unified Communications Manager 6.1, an MGCP controlled VG224, a SIP trunk to the PSTN and hardware transcoders. We place the SIP trunk and VG224 into different regions so that they should use the g.729 codec. Transcoders go into a region that will always use g.711.
Symptom : Calls show up on the SIP gateway as g.711, not g.729
This is because the system is using transcoders to complete the call. The big question is ‘Why?’. Both devices are natively capable of supporting g.729, but they insist on using a transcoder. The transcoder sits in a g.711 only reason, so both sides of the gateway run g.711.
Here’s the reason why : When calls connect to a SIP trunk in Cisco’s Communications Manager, the system will dynamically allocate a Media Termination Point (MTP) if the two endpoints are configured with incompatible DTMF signalling types. Since transcoders can be used as MTPs, a transcoding session is invoked.
In many cases VG224s are used to handle Fax calls. For those who don’t know… Fax machines and transcoders don’t mix. But even if there are no fax machines in the mix, at remote locations this issue can cause overutilization of bandwidth.
The solution is simple, just make sure that all of your endpoints use compatible DTMF relay methods.
For example in MGCP
mgcp dtmf-relay voip codec all mode nte-ca
is compatible with this command in SIP (RFC-2833)
dtmf-relay rtp-nte
I’ve been talking about MOS scores recently and answering a lot of questions. So I thought it might be worth a quick note. I’ll write a more detailed article about IP voice quality a little later.
MOS Scores are used to quantify the quality of a phone conversation. In the past this was based on the “Mean Opinion” of several call testers. On modern IP telephony systems, there are mathematical alogrithms that do this for us. They take into account the various inconsistencies that plague VoIP calls: loss, jitter and latency.
Those algorithms then give us a number to rate the results. The number is from 1 to 5. 5 being a theoretical maximum. I’m not aware of any system that claims 5.0 MOS.
|
MOS Score |
Quality |
Example |
|
5.0 |
Perfect Audio |
Face to face conversation |
|
4.4 |
Maximum digital* |
Crystal clear phone call |
|
4.0 |
Very good |
Normal phone call |
|
3.8 |
Good |
Average cell phone call |
|
3.5 |
Minimum for Faxing |
A few skips, but otherwise okay |
|
3.0 |
Minimum phone call |
A few missed words, but otherwise okay |
|
2.0 |
Poor but usable |
Callers need to repeat messages often |
|
1.0 |
Very Poor quality |
Zombies have taken over the planet and this is the only way to communicate with other outposts. It sucks but it’s all we got. |
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.
I am rarely very impressed with 3rd Party software, but Agito Networks has impressed me. I spent most of my day working with their team to integrate and test their Mobile Router with our IP Telephony platform.  Their solution integrates with most IP Telephony systems and wireless platforms to create a nearly seamless roaming functionality between the corporate environment and wifi enabled cell phones.
Their system allows your cell phone to ring as if it shared a line with your desk phone. You can pick up calls on either cell or desk phones. When you’re within range of a wifi access point, the phone will connect using IP Telephony rather than cellular service. When you’re out of range, it uses cellular. This saves minutes and LD costs on your cellular account. The really cool thing is that the platform can switch from wifi to cellular without dropping your call! In most cases you may not even be aware of the transition.
There are also several other features like corporate directory integration which would allow your cell phone access to the corporate directory stored on your office telephone system.
For anyone interested in taking a closer look, you can find more information about Agito Networks Mobile Router here
.
If you’ve worked with Cisco IP Telephony products, you’re probably familiar with their Attendant Console software. The software allows receptionists to manage incoming calls from their PC. This allows them to transfer calls with simple drag and drop functions. It also provides a quick list of user line status, whether they are on the phone or available. There are a number of additional features in this software but it is outside the scope of my rant. Using standard Cisco software, this software doesn’t exist for Callmanager Express (CME) patforms. The reccomended replacement is to use an expansion module which gives a phone “switchboard like” functionality.
ArcSolutions provides software that has similar functionality to Cisco’s Attendant console. This software is, in my opinion, one of the worst add-on technologies I have ever seen. I’ll explain and let you make up your own mind though.
ArcExpress requires that a “server” installation be configured on a single PC. That PC houses a SQL database for all other clients to attatch to. This PC has to remain on at all times, or the ArcExpress users all lose functionality. The “server” software is configured using the CME Configuration utility. This utility logs into the CME system and reads the configuration. At this point it attempts to make several configuration changes. Some of these changes include :
This was my first issue. In order to complete the CME Configuration, you must have at least 2 free phone licenses available. It also requires several available directory numbers for feature support. If your licensing does not allow for the recommended changes, the configuration will not continue.
At least the configuration utility gave me a list of the changes it was going to make. From that list I was able to adjust the changes to fit within the licensing constraints of the system.
At this point however, even though the ArcExpress virtual phone showed registered in the CME system, it did not function. Attempting to call Tech Support resulted in sitting on hold for an eternity. But I understand that problem. When you have a product as shoddy as this, one must expect a lot of tech-support calls. Their techs were probably all just very busy.
After many hours of work trying to get ArcExpress to function I have decided that it is not worth the effort. I will never work on another project using this software if I can at all help it.