Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

My office has a large Cisco UCM setup, and I work primarily remotely with a physical Cisco 7940 phone. I've battled some quality issues before, which turned out to be a bad switch port. But mostly my quality has been fine for months. Recently, people complain that my voice breaks in and out, and they can't understand me. I'm currently using the G.729 codec and my calls all have an average MOS LQK of 3.68. My phone is reporting no RxLost, no jitter. My TxSize is 20ms, but I don't know how that affects audio transmission. I have never had a problem receiving audio.

My connection to the UCM is over an IPSec VPN handled by an ASA5505 to an ASA5580. The ASA5505 plugs into my home network, and then goes though my home router to access the internet. My phone plugs into an ASA5505 PoE port.

In one-to-one calls, I rarely, if ever, have had a problem. Most people never know I'm on an IP phone. However, with internal conference bridges, I recently have to call in from an outside line to speak. I have also experienced this problem with outside bridges at other companies when I call into their meetings, but less often. I can't find any correlation of what might be occurring when poor quality issues happen. Traffic on my home network is almost non-existent. I do have another SIP internet phone sharing the same broadband connection, but my quality issues occur regardless of whether that phone is in use or not at the same time.

Previously I monitored traffic from the ASA5505 and noticed it is tagging encapsulated VoIP on the outside segment as Expedited Forwarding with DSCP 46 (I as surprised the IPSec packets were tagged as this but our VPN/Phone guy had no idea what DSCP was). I can prioritize this (currently I am not), but in the past it did not help. Below is Vyatta config code for this:

qos-policy {
    traffic-shaper EXTERNAL_QOS {
        bandwidth 1mbit
        class 10 {
            bandwidth 90%
            description "Match VoIP traffic"
            match VOIP {
                ip {
                    dscp 46
                }
            }
        }
        default {
            bandwidth 5%
        }
        description "External bandwidth QoS Policy"
    }
}

Is there anything I can tell the group that manages the Phone and ASA to help them resolve this? As of now, they refuse to believe the problem is on their side, only that since it runs through my home router, I'm at fault. I guess they presume I have a bunch of torrents running...

share|improve this question
    
Try calling someone 1-to-1 and have them pull up their info for the call. The Rx Jitter/RxLost make sense from your PoV because you are hearing them fine. They however, should show some lost on their Rx-side when you speak. Most importantly, you want to know their RxLost, RxJitter (avg/max) & the field that shows the silenced seconds (I think it's ErrSec) I can't remember. Because it's happening only on your outgoing, I would venture to say it could possibly be your broadband (consumer broadband usually has poor upload compared to download). Are you on DSL..Cable...? –  Nextraztus Feb 23 '10 at 6:12
    
I'm on cable. 10mbit down, 1mbit up. I normally get those speeds when I do a test, never below 900kbps up. I think on my phone it is called concealed secs. I will need to call someone tomorrow with a VoIP phone to get that info, but it makes sense. I also enabled QoS on my home router for DSCP-46, but as I said, that didn't help before. –  user29107 Feb 23 '10 at 6:19
    
Any reason why 1-to-1 calls sound fine, but bridges are terrible? The bridges are primarily on an older system in the same building where UCM is. I assume there is some analog or digital trunk between the two. –  user29107 Feb 23 '10 at 6:24
    
900kBit upload should be more than enough, even if it gets bogged down you can handle G.729. Here's something else I would do - see if you can get a stream cap of a phone call to both a conference bridge and to another person. The idea will be to compare the underlying codec that is negotiated. WireShark should decode the RTP stream packets nicely (if you can set yourself up a monitor port or bridging computer so you can intercept these packets). I think with this information someone on here will be of better help. And btw, thats bad news about not knowing what DSCP is :/ –  Nextraztus Feb 23 '10 at 6:26
    
9 times out of 10 call-quality issues that spring up like this out of the blue tend to be caused by device-pack upgrades or IOS/firmware/DSP upgrades that don't support codecs. On that note, compare your Device Load/App Load numbers with someone else that isn't having trouble either (but is on the same model phone). This might help pinpoint it down further as well. If those numbers don't match than it's possible your phone didn't get some upgrade. You may also consider a factory reset, although I'm not sure thats a good idea if you can't get to work if it breaks something. –  Nextraztus Feb 23 '10 at 6:29

1 Answer 1

The only real difference I know of with conference calls are timing in the pbx and the echo canceler.

Assuming the pbx is working for everyone else, I have two suggestions. Timing will cause dropped frames, codec resets, etc. Echo can mute your outgoing voice.

Try seeing if not dropping silent frames will fix timing issues. It's wasteful, but it it trying to emulate circuit switch system. Have the phone send every frame, silent or not.

As for the Echo canceler, you're side isn't going to be able to have it's echo canceler "train". while on conference call, you're echo isn't going to be sent back while another circuit is doing voice. Disable any aggressive settings on you're side, the conference bridge is probably already doing very aggressive echo cancellation. On that note, are you using speaker-phone? Speaker-phone also requires aggressive echo cancellation.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.