One-Sided Fade Outs on IPO4 5

[573dawn]

Hi All, new thread for a not-so-new problem. I'm sure some of you are well aware of my dropped call issues. Afte changes made today, we are getting fewer drops, though not eliminated. However, we have this new problem: The call will "fade out" while you are on the phone. It doesn't drop, but one or the other party will get silence, while the remainign party can still hear the opposite party. This lasts a few seconds and then both parties can hear each other again.

In Monitor I can see:

********** contact lost with 192.168.3.180 at 14:13:28 6/7/2007 - reselect = 2178 **********
******************************************************************


********** SysMonitor v6.0 (5) **********

********** contact made with 192.168.3.180 at 14:13:28 6/7/2007 **********

********** System (192.168.3.180) has been up and running for 2days, 22hrs, 34mins and 31secs(254071121mS) **********

Along with the occasional dopped packets. But these calls DON'T disconnect, just fade in and out.

 

[aarenot]

Dawn,
What do they intend to ground to this new ground wire to the electrical panel ground? The Telco should be providing its own ground for its equipment, not you. If you were required to provide them a ground you would have had that as a condition of your contract, sales, or service agreement with them.
Same goes for your BP, if you were required to provide anything, it should have been documented in your contracts, or sales agreements. This type of grounding should be highlighted in an environemental document which was provided for you as part of your contract, or at least your project manager would have communicated this.

Also, if you were serioulsy required to supply something in order for them to perform, do you think it would have come up during implementation, or after the fact when they do not perform? Sounds like finger pointing, or at least they failed to advise you of the environmental requirements for the system, if so, it is back on them.

Yes, I do have these types of documnets as part of my proccess to inform the customer what is expected from them. If they so choose we can with approval make an add to the contract to provide these environemntal elements at a cost. I require an earth ground as part of the environemental requirements for the customer to provide, unless specified that we are providing. In which case we get one installed and certified/tested by a qualified electrician with the proper equipment to verify the ground.

 

[573dawn]

aarenot, sorry it took me so long to answer, yesterday was my b-day and I left early and pretended there was no such thing as a phone.

Apparently what happened was our BP was at the 21, and an ATT engineer showed up, not sure for what problem, took one look at the demarc, stated we weren't in compliance, and left. Out BP was just as shocked as I am. The 12-guage jacketed copper that is the current ground was installed when that was the specification required by ATT, years ago. This was the first we had heard of any change, our BP included.

 

[aarenot]

I would get the ATT requirement in writing from ATT, before I believe your BP.

 

[573dawn]

aarenot, you have a point <g>...We have the pots lines in place now, and that helps. I've started a thread over on the cisco forum to see if anyone can assist me with traffic shaping, because packet priority has been mentioned many times and I've not done any shaping.

Is IPO using RTP? It looks that way from the config. If so, my cisco 1720/21 can't be configured to prioritize RTP traffic, I'll have to go to a 1600 or 2600 series. Although I see no particular issues with either bandwidth or errors across the PTP, I have to wonder if I switched to an RTP priority capable router and shaped the traffic if it might make a difference. What do you think?

Thanks, Dawn

 

[573dawn]

aarenot, is there a list of callLost codes out there somewhere? In monitor I see alot of

CMARSEndpoint: :CallLost(cause=124)

or

CMARSEndpoint: :CallLost(cause=16)

And I think I've seen another cause as well somewhere. Just wondered if there is a list or if this is even something to worry about.

What I DO see an awful lot of, at my trouble site, are the messages like that in my first post of this thread. I can see it, just in the last hour, over and over again.

 

[Gibsonic]

i hear if you offer your first born with and a wad of cash you might get Avaya to provide a list of what these cause codes mean.

 

[573dawn]

Gibsonic, well, no first borns, no cash, guess I'm screwed (and you might just owe me a keyboard, the screen wipes off).

I can see those CMARS codes in monitor at all locations, but I only see "contact lost" errors at my trouble site. I know that sometimes the "contact lost" occurs when a fade out is in progress, because it has happened to me while watching monitor. I don't know if or how many represent true drops.

I do know though that I counted 11 of them just between 2:43PM & 3:42PM, and I can basically sit and watch monitor and watch them as they go by. I turned debugging on both my routers to that site, so far nothing, as expected.

 

[tlpeter]

here is a list but it does not contain the 124 error

http://www.spinics.net/linux/cause_codes.html

ACA - Implement IP Office
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[Gibsonic]

are you sure those are ISDN error codes that she posted?

they certainly could be, but the CMARSEndpoint doesn't make me think ISDN.

just a thought.

dawn, you know i saw a link the other day that showed you could actually just put your keyboard in the dish washer to clean it...not sure i would try it, but well, it may come in handy for you

we could use a lil more humor around here...but i'll be sure to warn you next time

 

[tlpeter]

i don't know indeed
but i just post them in case they are


ACA - Implement IP Office
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[573dawn]

tlpeter, thanks!

Gibsonic, believe me I needed the laugh Keyboard is fine too!

I am getting ready to go to my trouble site and chage out the workgroup switch, which somehow I can't ping, but I know is working. I think it lost it's config. Why am I changing out the switch you ask?

Well, this morning ATT & I broke the T1 several times between my main and trouble sites. The really interesting thing is that the "contact lost" errors almost always ocur within the same second, yet when we broke the T1, it took as many as 5 seconds to get the "contact lost" error.

SO, this morning I set up a continious ping from my desk to the far end cisco, and a continious ping from my desk to the DS unit. Almost without exception, you will see a timeout coming from the DS unit, which at the same time gets you a "contact lost" in Monitor, BUT the timeout doesn't occur on the cisco.

SO, the only device inbetween is the workgroup switch, which I can't ping, and since the only laptop I have has a screen so dim I can't use it to console into the switch, so I'm just finishing up configuring another switch (Avaya P133GT2) and will head that way.

I will be very interested to see what happens when I am pinging all 3 devices.

 

[aarenot]

No time to chat out the door on emergency serv call, plumber involved so I may have a bathed system. TTYL, hope this helps.


Cause Codes (ISDN)
When a call is ended, a cause code may be shown in the Monitor trace. This cause code is not
necessarily an error as cause codes are shown at the end of normal calls. Cause codes 0 to 102 are
standard ISDN cause codes. Causes codes 103 upwards are IP Office specific codes.
To display cause codes, ensure that the Monitor | Call | Extension Send option is enabled. The cause
code is then shown are part of CMExtnTx: events within the monitor trace. For example:
10185mS CMExtnTx: v=100, p1=1
CMReleaseComp
Line: type=DigitalExtn 3 Call: lid=0 id=-1 in=0
UUI type=Local [....] [0x03 0x00 0x00 0x00 ]
Cause=16, Normal call clearing
Timed: 12/07/05 11:00
The cause codes are listed below. Those marked with a * were added in release 3.0.1. Those marked
with a + were added in 3.0.40. Note that the Disconnect codes marked with a * or + are not available in
2.1 or 3.0DT releases.







• 124 Answered By Other (Internal IP Office code).

 

[573dawn]

Amazing, I put in the replacement switch, the 2nd replacement I might add, and I haven't seen a "contact lost" since. I am asking my users to please keep me posted on the phones, and I am about to delve into the switch I replaced to see if I can get it to lose packets, etc. Durn thing was an older model, but brand new in the box, never been used. I hate it when that happens.

Still, I am cautiously optimistic! I will keep the thread informed.

Thanks, Dawn

 

[Gibsonic]

you know, most tech problems like this seem to come down to Layer1 and sometimes Layer2 issues.... (your switch)

 

[573dawn]

Gibsonic, I hate to admit this, but I have to. Somehow, I misaddressed this switch, I had it matching the cisco's fast ethernet address. How I managed to make such a stupid stupid mistake I have no idea. No wonder I couldn't ping the durn thing. It remains to be seen whether or not the problem is solved, a couple hours isn't enough. BUT, with the rate of errors going from 10-15 per hour to zero in the last couple hours, I'm keeping my fingers crossed.

With as many problems as we have had overall with this system, one problem can mask another and so on, so we shall see.

I am so embarassed. However, if my mistake helps someone else it's ok. I'm not looking forward to telling my boss though <g>.

 

[aarenot]

Dawn,
Do not be so hard on yourself, you have learned a lot about the IPO, and you have fixed many problems on your systems yourself which did not pertain to this data switch as the cause in any way shape or form.
Here is the way I look at troubleshooting. It is the art of figuring out what the problem IS NOT.
The things we elimiated as issues were the things we did not change, all the things we had to change in the set up of the IPO, and its configurations were the issues, and each one did eliminate part of the problems. Then we start over again, since we had one more thing which we fixed, so we knew the problem was not that any longer since it got better after the change we made. Although more problems did remain, we had gotten one more thing determined to no longer be the probelm.

If we had not had the myriad of items the BP did to mess up, we would have gotten down to the one thing left much sooner, like with your first thread June 16th, instead of your 7th thread July 6th!!!!!!!!!!!!!!!

Even if your issue had not occurred, the IPO was not set up anywhere near well enough to not have still had serious issues, we just found all of his first. Also, a network assesment would have found your mistake if it had been done as it should have been. So, back on the BP for not doing the NA as Avaya requires. O.K. that may not make you feel better about the NA because it was your mistake on that data switch, but it is true it should have discovered it.

 

[573dawn]

Thanks aarenot, you have a great way of making me feel much better. I have learned a great deal about the system, and I would be thrilled if this were a total fix, then I just got an email, someone saying a call dropped over there. However, I see no corresponding error in monitor, no alarms in SSA, and I am likely to think that perhaps there was some user error or even a cell phone drop. After all, calls DO drop for other reasons!

I should probably tell you that the mis-addressed switch was actually the 3rd switch. The first swtitch was unmanaged and unaddressable. We then put in a used Avaya P133G2 that my BP sold me, but he didn't have the console cable for it (didn't mention that when we bough it either) and I couldn't address it either, so it sat on the network with the IP that was assigned by it's previous owner. So I went to ebay and found 4 P133GT2s that had never even been unboxed, I bought them, mis-addressed one, and switched it out with the used one (which we returned to the BP). It wasn't until ATT & I broke the circuit yesterday to see what would happen in Monitor that I decided to configure another one and swap them out. Brought the mis-addressed one back to my office, consoled in and sat there dumbfounded when I saw the IP. So an NA wouldn't have caught it, but in reality I shouldn't have had to go through 4 switches anyway <g>.

What will I do if we solve all the problems? I enjoy the people on this forum, I guess I'll just have to keep learning about it so maybe I can contribute

 

[tlpeter]

i give you a star for not giving up
this is the best way to learn ,learn on the job


ACA - Implement IP Office
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[573dawn]

tlpeter, thanks! That has been my method for my entire 12 year IT career, started in phone support for GW back in '95 and never looked back. That said, if it weren't for many talented and generous professionals I've met along the way, I never would have made it. That and alot of hard work! I thank all of you for your support so far, and in advance for the future!

I'm still hearing that there are some drops, but vastly reduced. I did go over to the cisco threads and a nice person over there gave me some traffic shaping for my 1720s, here it is for anyone who might need it, nice and simple and the person who wrote it wrote it for Avaya voip packets (thread

http://www.tek-tips.com/viewthread.cfm?qid=1387004&page=1):

class-map match-any VoIP
match ip dscp ef
match ip dscp af41

policy-map voipQos
class VoIP
priority 768
class class-default
fair-queue
random-detect dscp-based

Interface XXXXX
service-policy output voipQos

 

[573dawn]

tlpeter, my very first star, I didn't realize it at first thanks again! Dawn