Mitel Call Control QoS - DSCP or Port?

[mzinz]

Hi All,

I recently set up a large WAN which is using Mitel as their phone vendor. I used option 134 to set DSCP values on the phones, which they are indeed picking up.

Users report that call quality is excellent. The only complaint they have is that sometimes when calling out, they feel like there is a delay when pushing buttons - this sounds like a call control issue to me.

They have also complained (several sites) that sometimes when they answer it sounds like dead air, almost like the call is "sorta" connected, but one party can't hear the other.

My real question: Could these be call control issues? What port does Mitel call control use? How can I set the DSCP for that?

Thanks,
Tyler

 

[kwbMitel]

Delay while dialing can be quite a number of things. You need to more clearly define what exactly is delayed.

Delay between pressing key and sound emitting? (set issue)
Delay between pressing key and digit displaying? (call Control)
Delay after dialing and before ringback? (ARS Programming)

The second item is far more elusive as there needs to be complaints from both called and calling parties to call it 1 way audio. If you are only getting complaints from internal users then the source of the call needs to be identified before proceeding. (Trunk, Voicemail, Callbacks, etc)





*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[mzinz]

Thank you for the response. You've definitely pointed me in the right direction.

I'm not a phone guy myself (networking, but not much voip), so I wasn't sure on what information to get until now

I'll report back - thanks again.

 

[mzinz]

I haven't gained any more info on the button lag yet, and I have requested that next time a user can't hear the other person (or visa versa), that they call me immediately after to run several tests.

In the meantime, I would like to setup QoS for Call Control.
Right now I'm using DHCP option 134 to mark DSCP on the phones for "ef". Will that only take care of the actual voice stream (RTP), or does that handle call control also?

*What's the best way to match call control packets? I'm fine with doing more DSCP, or doing it by port.*

 

[slapin]

Call control is DSCP 26 or AF31. At least on MXe and CXi. MiNET is pretty compact binary protocol, so it doesn't take too much bandwidth. If you have excessive delay issues all the times, then network having real capacity problem and running under near 100% load.

 

[mzinz]

Thanks for the reply slapin.

We have a Mitel 3300:

http://www.mitel.com/DocController?documentId=9555

Yes - these sites are connected via T1's, so maxing out bandwidth is a very real issue

If I set the DSCP value via DHCP option 134, does that only change the DSCP of the RTP stream (and not the control traffic)?

 

[mzinz]

Anyone know?

"If I set the DSCP value via DHCP option 134, does that only change the DSCP of the RTP stream (and not the control traffic)?

 

[IrwinMFletcher]

if you set if via option 125, it can be entered as follows:

dscp=46v46s26

where the first 46 is for default packets, the v46 is for voice and the s26 is for signalling.

Never tried, but should work for option 134 as well.

 

[mzinz]

That is so awesome. I can't thank you enough.

What are "default packets"?

I will probably just do 46/46/46, then give high priority to all traffic coming from the phones.

 

[IrwinMFletcher]

'default' is anything not voice or signaling...web interface I would guess as an example. Never checked.

 

[mzinz]

Is there any way to verify these settings other than sniffing the traffic?

Thank you so much for your help - really helped me out big time.

 

[IrwinMFletcher]

You can check the phone's network parameters and it should show you the dscp value (only the streaming however). Other than that, sniffing is the best bet.

 

[mzinz]

Not sure what's wrong.

I used: option 125 ascii "DSCP=46v46s26"

I setup my QoS policy to make traffic on DSCP 26.

I cleared my current DHCP binding and restarted the phone. Pulled a new DHCP lease.

When making phone calls, no traffic is matching on DSCP 26.

Any idea where I went wrong?

 

[IrwinMFletcher]

what do tcp packets have/show (going between the phone and the 3300)?

 

[mzinz]

I'm not sniffing the traffic, so I'm not sure 'what' they are. I can just tell that they aren't hitting my QoS match.

They are going from phone to 3300 through a T1.

 

[slapin]

When you restart the phone, do you see "Using Optin 125" message? Or "Using Option 128+" ? Can you setup artificial policy which will match all packets for that phone. If you work with Cisco equipment, create a separate class and separate ACL matching IP address of the phone. Next step will be splitting this ACL in 7 records matching different TOS. Using this method you will be able to narrow down to specific DSCP fairly quick. I found that 5215 phones ignore DSCP settings and mark media traffic as DSCP 44. I didn't look for signaling since it didn't bother me.

 

[mzinz]

It says it's using option 128+...

 

[lcpar]

MZINZ

Your delay on outgoing is because the ARS table number of digits is set to "unknown". If this setting is used the system will delay waiting for a total of 26 digits. This will cause a "delay" while the system times out. I only use the number of digits "unknown" for international calling. Hope this helps.