VoIP Problems with Procurve 3500s

[darklywhite]

All our sites are working fine with our 3300: T1s, fractional T1s as little as 900kb bw, etc.  At our biggest site however....

We are having a VoIP issues across 2 Procurve 3500s: a 24-port (branch) and a 48-port (main office).

Intermittently, users complain of not being able to hear those who answer the phones at the site. If you call the site, you can tell the phone has been answered, but you cannot hear anyone for approx. 5 seconds. After that delay, the call is great -- no drops of any kind or static.

I found this forum post which describes the _exact_ same problem on Cisco equipment:

http://www.gossamer-threads.com/lists/cisco/nsp/96713

The solution: enable “fast start” on the router.

I then found the command in our 3500s: “lldp fast-start-count”

Is this the same as that Cisco command? I tried it on our main office 3500, but it did not fix. Yesterday, I tried it on the branch 3500. In both cases, I have set to 1 second (default is 5). It is currently _not_ running on our main office 3500, so it is at 5 seconds.

I know there are other lldp tweaks.

If you can provide any advice that would be great.

[ralph]

I wouldn't have thought lldp would have anything to do with it.
After reading the thread you posted, "fast start" has to do with H.323 - not a Mitel supported protocol.

Are your phones all on the same sub-net as your controller?

Ralph

[darklywhite]

I wouldn't have thought lldp would have anything to do with it.
After reading the thread you posted, "fast start" has to do with H.323 - not a Mitel supported protocol.

Are your phones all on the same sub-net as your controller?

The site with the voice vlan having the problem is on the same subnet as our main office.  It is simply at a single branch office that we are having this problem.  The connection for the problem voip is unique to us-- our only metro-E.  Other connection-types from same teleco are fine, even though on separate subnets _and_ much smaller connections

Good catch on H.323

Here is what HP says about fast-start-count (I admit I may be barking up the wrong tree):

“LLDP-MED Fast Start Control

Syntax: lldp fast-start-count < 1 - 10 >

An LLDP-MED device connecting to a switch port may use the data contained in the MED TLVs from the switch to configure itself. However, the lldp refresh-interval setting (default: 30 seconds) for transmitting advertisements can cause an unacceptable delay in MED device configuration. To support rapid LLDP-MED device configuration, the lldp fast-start-count command temporarily overrides the refresh-interval setting for the fast-start-count advertisement interval. This results in the port initially advertising LLDP-MED at a faster rate for a limited time. Thus, when the switch detects a new LLDP-MED device on a port, it transmits one LLDP MED advertisement per second out the port for the duration of the fast-start-count interval. In most cases, the default setting should provide an adequate fast-start-count interval. (Range: 1 - 10 seconds; Default: 5 seconds) Note: This global command applies only to ports on which a new LLDP-MED device is detected. It does not override the refresh-interval setting on ports where non-MED devices are detected.”

[Mattmayn]

The LLDP would only effect the phones when they are connected to the switch and before bootup, once the phone has booted you would no longer be receiving any discovery info.

You said that this is your only Metro-E site, is the telco providing any of their "special" VOIP or QOS services on this circuit?

[ralph]

This audio cut through delay issue sure feels familiar.   I just can't put my finger on it.
I'll have to cogitate on it a bit more.

Ralph

[darklywhite]

The LLDP would only effect the phones when they are connected to the switch and before bootup, once the phone has booted you would no longer be receiving any discovery info.

Good point, and I've thought of that: that why would LLDP have _anything_ to do with this?

My bad science is:
1. google for the exact problem (cannot hear first 5-or-so-seconds, then perfect connection).
2. found _exact_ same-description of problem, fix being fast start/H.323.
3. find "lldp fast-start-count" command bcs of same words ("fast start")
4. read procurve description of "lldp fast-start-command" which deals with "delay" and default being "5 seconds" <-- same amount we are experiencing....

Some Cisco guys pointed out the same thing: "hey dummy! that forum you linked is about H.323, so, no, that's not your problem...." <-- I concur on the observation regarding H.323 vs. LLDP.

I also concur on the question of: "why would LLDP have _anything_ to do with this?"

Still....

Is it the telco?  I dunno.  I have sent all of this information to them, and am waiting -- they make me wait very long lots....

You said that this is your only Metro-E site, is the telco providing any of their "special" VOIP or QOS services on this circuit?

They have sent me the configs on the Cisco ME 3400s way back.  I can reask/try-to-find them.  Good point.

I'm wondering if there isn't something they need to do in that regard and if this isn't a problem similar to the H.323 "fast start" I found in that forum post.

[darklywhite]

I spoke to/emailed a telco engineer ystdy who stated he could find nothing with their Cisco ME 3400s (the 2 devices that hand-off the ethernet to our Procurve 3500s) that would be causing this.  They are doing all Layer2 for us.  I mentioned CEF, but again, Layer2, and that's Layer3.

I'm considering doing QoS on the switch on the branch side, even tho HP, et al., have stated it isn't needed with as much bandwidth as we have (majority of time, usage extremely low).

I do not have QoS setup on any switch with the same speed, which are fine.

Finally, just gotta get more measurements from the phone, calls, etc., and looking into that.

Any other advice appreciated from here....

[boycey9]

Are you using compression zones? could be codec negotiation issues

[billbry66]

how about spanning tree - maybe portfast is the cure?

[ralph]

Looking at this a bit closer.
Can you tell us if the delay happens when the call comes in via PRI on one controller but is answered by a phone registered on another controller?
Does the delay happen when answering on a phone registered to the same controller as the trunk?

Ralph

[darklywhite]

FYI, we have apparently fixed this issue.  The problem/fix was to hard code the line speed between the 3300 interface and the 3500 interface.  We had already hard coded it from 3500 to telco 3400 cisco on both ends, but we had not hard coded it beyond that.  Again, all other sites were fine _except_ the 100mb site.

Like this:

BO -- 3500 -- telco3400 -- telco3400 -- 3500 -- PBX

Everything was hard coded on line speed (100mb fd) except between 3500 -- PBX.

We have been good with no VoIP problems since doing this around October 30th.