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.
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.
Well, this weeks challenge never made it to the web. I wasn’t happy with the way it was turning out. I’m rethinking how I want to do them to try to save time and provide better study material. Look for new challenges in the next few weeks. We’re heading out on vacation for the next two weeks, so updates will be sparse. But I’m hoping to have a better idea of exactly what I want to do after a few weeks of letting my brain out of the frypan.
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.