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.
Since I’ve had several requests for more information on this, I thought I’d get back into my blogging by addressing this topic.
There are 2 ways to get this functionality. And I believe there are Pros and Cons to each approach. Both methods require that you have licensing on the system for IMAP access.
For Either Method :
First, create a new Class of Service in Unity Connection. Duplicate your default settings. Under ‘Licensed Features’ check ‘Allow Users to Access Voice Mail Using an IMAP Client’ and select ‘Allow Users to Access Message Bodies’.
Save the Class of Service. If you have sufficient licensing, you can just change the default Class of Service and skip the next step.
Next you will need to select which users will have this feature by selecting their Alias under Users and
changing ‘Class of Service’ to whatever you named the class you just created.
At this point you may need to change the Web Application password for the user account. Or at least set the password not to require changing at login. This is the password that will be used to access the server.
Method 1 : Configuring another account on the mail client
This is probably the easier of the two options to implement. But with multiple users it can also be the most time consuming.
Simple change the settings on the users email client.
Create a new account with the following settings :
Type : IMAP
Server : UnityConnectionIP
User Name : (Unity Alias)
Password : (Unity Alias Password)
Then you will probably want to configure rules that copy the incoming messges to the users inbox.
Copying is important since if you move it, the voicemail will be removed from the users phone as well.
Method 2: Forwarding voicemails to the primary mail server
This method is a little more difficult and requires an extra server. As it is more in-depth I’ll address it in my next post.
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
And so it begins again… the helplessly frustrating, yet incredibly entertaining monotony we call work.
Regularly scheduled updates, including new challenges, will begin this week… stay tuned…
My family and I have recently embarked on a vacation to Japan. The trip was much easier than I thought it would be with 3 young children. There were some very interesting changes though with Swine Influenza spreading. We had a long layover in Taiwan and when we left the aircraft, there were a very good deal of people wearing masks in the airport. Probably a good idea even without an influenza scare since there are people in the airport from all over the world. Our arrival in Japan, however, was even more involved. Before passing through customs, we were required to fill out a document regarding our recent health and travel. Since we were coming from the U.S. we were further required to undergo a simple health check. Apparently on some flights, the health inspectors actually board the flight and check people before allowing anyone to leave the plane.