Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Does Avaya have field techs? 1
- Thread starter 573dawn
- Start date
AZJeepGirl
Programmer
Dawn,
No worries, just keep us posted. The VCM and the DS mod are two different things. The VCM is what provides the paths for IP connections (how many paths you can have between that site and your others simulatneously which in your case would be 8) and is internal in the 406. The DS module is what your actual telephones plug into and is an expansion/rack mount unit that would plug into the back of your 406.
There was an issue with the power supplies for DS 30's not too long ago and Avaya changed them. Make sure you run by and check that out. I had an issue with the folks who would place our orders not getting the proper power supplies at one time, so I wouldn't put that past your "BP" especially with a management shift as you mentioned. It can cause problems...
Good Luck & let me know how tomorrow goes...I will check on you through out the weekend when time allows. Too bad I'm not closer (South Carolina) or I'd just come by...my girls would love it LOL!
____________________________________
I'd rather be jeepin'! 0|||||||0
No worries, just keep us posted. The VCM and the DS mod are two different things. The VCM is what provides the paths for IP connections (how many paths you can have between that site and your others simulatneously which in your case would be 8) and is internal in the 406. The DS module is what your actual telephones plug into and is an expansion/rack mount unit that would plug into the back of your 406.
There was an issue with the power supplies for DS 30's not too long ago and Avaya changed them. Make sure you run by and check that out. I had an issue with the folks who would place our orders not getting the proper power supplies at one time, so I wouldn't put that past your "BP" especially with a management shift as you mentioned. It can cause problems...
Good Luck & let me know how tomorrow goes...I will check on you through out the weekend when time allows. Too bad I'm not closer (South Carolina) or I'd just come by...my girls would love it LOL!
____________________________________
I'd rather be jeepin'! 0|||||||0
kurthansen
Technical User
Dawn,
Check some of the calls in SSA on the IP Trunks. See what the IP Office is showing for lost packets and Jitter.
Check some of the calls in SSA on the IP Trunks. See what the IP Office is showing for lost packets and Jitter.
- Thread starter
- #23
Dawn,
Have you considered opening up an Avaya BPship across the street from your current one? I believe you would do well, and they would not.
Another suggestion would be to set an analog ext on your problem site with an answering machine. Set the answering machine with as long an outgoing message as possible. You can then call, and via an AA, transfer yourself to that ext, and stay connected for a long period of time. This can help to be able to try to re-produce a dropped call.
Also, you might want to test to see if some component may be temp losing power, or having a brown out power condition. Cheapest way I have jury rigged is a power strip for a power source for the components with an alarm clock plugged into the same power strip. Choose an alarm clock which resets to flashing midnight if power interupts.
Have you considered opening up an Avaya BPship across the street from your current one? I believe you would do well, and they would not.
Another suggestion would be to set an analog ext on your problem site with an answering machine. Set the answering machine with as long an outgoing message as possible. You can then call, and via an AA, transfer yourself to that ext, and stay connected for a long period of time. This can help to be able to try to re-produce a dropped call.
Also, you might want to test to see if some component may be temp losing power, or having a brown out power condition. Cheapest way I have jury rigged is a power strip for a power source for the components with an alarm clock plugged into the same power strip. Choose an alarm clock which resets to flashing midnight if power interupts.
mattKnight
Programmer
How is your system physically connected to the Cisco router?
I mean is the Cisco plugged directly into the IPO, or linked through a data switch?.
Is it possible this is a router port speed/negotiation issue?
Likewise, have you run an ethereal/wireshark trace on the WAN link?
Take Care
Matt
If at first you don't succeed, skydiving is not for you.
I mean is the Cisco plugged directly into the IPO, or linked through a data switch?.
Is it possible this is a router port speed/negotiation issue?
Likewise, have you run an ethereal/wireshark trace on the WAN link?
Take Care
Matt
If at first you don't succeed, skydiving is not for you.
- Thread starter
- #26
Thanks everyone 
aarenot, LOL! I have actually had that thought a couple times. I have to wonder about all these other systems they claim to have installed that are "100% stable and happy". I mean come one, how many small businesses in a rural area with a tourist driven economy actually have that kind of need (or money)? Anyway, that is a great suggestion about the answering machine and alarm clock! I might have to give that a try.
mattKnight, the IPO is running through a switch, and it is auto-negotiating the port speed/duplexing, but so far I haven't seen them drop to 10 or half (I am monitoring it with solar winds) Likewise I haven't had packet drops, or anything else on the WAN link.
What IS intertesting is that I have had no reports of drops since Thursday. I tweaked the QoS yesterday morning, and all fo a sudden I am seeing af41 and ef stats on my trouble site router. I changed it from a class-map match-any to a class-map match-all.
Before the tweaks, all I could see that was being handled by the policy was cs6. NOW I can see large quantites of af41
and ef, as well as a few cs6. BUT I only see that on the router at the trouble site, on the router here at the Main, I can see only some ef packets even though the policy matches at both ends.
I am inclined to think that there were 2 problems:
1. The VCM. After it was replaced we continued to drop calls, but NOT in clusters, it was one here and one there and greatly reduced.
2. The QoS. If it wasn't handling packets correctly before now, it apears to be doing so at this point. Although the QoS is only in place between the Main and the trouble site, no one else has the sheer volume of calls that they receive.
I am almost holding my breath <g>.
If I get through the next few days without any drops that I can tie directly to the error above, I might just cancel the vendor meet, because if I never see my BP again, it will be too soon.
aarenot, LOL! I have actually had that thought a couple times. I have to wonder about all these other systems they claim to have installed that are "100% stable and happy". I mean come one, how many small businesses in a rural area with a tourist driven economy actually have that kind of need (or money)? Anyway, that is a great suggestion about the answering machine and alarm clock! I might have to give that a try.
mattKnight, the IPO is running through a switch, and it is auto-negotiating the port speed/duplexing, but so far I haven't seen them drop to 10 or half (I am monitoring it with solar winds) Likewise I haven't had packet drops, or anything else on the WAN link.
What IS intertesting is that I have had no reports of drops since Thursday. I tweaked the QoS yesterday morning, and all fo a sudden I am seeing af41 and ef stats on my trouble site router. I changed it from a class-map match-any to a class-map match-all.
Before the tweaks, all I could see that was being handled by the policy was cs6. NOW I can see large quantites of af41
and ef, as well as a few cs6. BUT I only see that on the router at the trouble site, on the router here at the Main, I can see only some ef packets even though the policy matches at both ends.
I am inclined to think that there were 2 problems:
1. The VCM. After it was replaced we continued to drop calls, but NOT in clusters, it was one here and one there and greatly reduced.
2. The QoS. If it wasn't handling packets correctly before now, it apears to be doing so at this point. Although the QoS is only in place between the Main and the trouble site, no one else has the sheer volume of calls that they receive.
I am almost holding my breath <g>.
If I get through the next few days without any drops that I can tie directly to the error above, I might just cancel the vendor meet, because if I never see my BP again, it will be too soon.
Dawn,
Since the Avaya support which should accompany your system requires a network assesment be performed. Assuming the BP included the system being a supported implementation of the IPO by Avaya standards, and requirements within the parameters of the sale. I would demand that the BP perform a network assesment at this time in order to validate the implementation within the Avaya standards.
You might also contact Avaya directly about purchasing an Avaya maint contract, since they will require the network assesment, they can push it from the other end. You could also inquire about an Avaya maint contract purchase through yout BP, which should also require the network assesment.
I would not even consdier paying any more for the network assessment, but demand that it be done if it is required for Avaya to support the system(it is). I would not get the maint contract if I were you since you seem to have become expert enough to support your own product better than your BP, just inquire to push the issue.
They will most probably have to come out and do one before Avaya will bid your maint contract.
I would also inquire with Avaya, and your BP if they have two product authorized techs on the IPO which Avaya requires for a BP to implement the IPO. They should have documentation of the techs PA's from Avaya university.
Since the Avaya support which should accompany your system requires a network assesment be performed. Assuming the BP included the system being a supported implementation of the IPO by Avaya standards, and requirements within the parameters of the sale. I would demand that the BP perform a network assesment at this time in order to validate the implementation within the Avaya standards.
You might also contact Avaya directly about purchasing an Avaya maint contract, since they will require the network assesment, they can push it from the other end. You could also inquire about an Avaya maint contract purchase through yout BP, which should also require the network assesment.
I would not even consdier paying any more for the network assessment, but demand that it be done if it is required for Avaya to support the system(it is). I would not get the maint contract if I were you since you seem to have become expert enough to support your own product better than your BP, just inquire to push the issue.
They will most probably have to come out and do one before Avaya will bid your maint contract.
I would also inquire with Avaya, and your BP if they have two product authorized techs on the IPO which Avaya requires for a BP to implement the IPO. They should have documentation of the techs PA's from Avaya university.
- Thread starter
- #28
aarenot, are you telling me that the BP is REQUIRED by Avaya to have TWO trained installers to be allowed to install these?!? I am not 100% certain he doesn't, but I can distinctly remember my BP telling us that he "really needed to get someone else trained on this" because the installer has such a bad attitude. (I caught him basically abusing one of MY USERS, because the poor guy asked a basic question about how the new phones worked.) I was shocked and immediately got him away from MY USER and complained to my boss, who then complained to his. His attitude cleared up somewhat after that, but not by much.
NO ONE abuses my users but ME <g>.
Anyway, back to the assessment. There was never even mention of an assessment. In fact, after the IPO was installed and we started having so many problems, I was specifically told, well here, read it yourself, this is just an excerpt:
"Dawn,
I am aware of the problems that you are having with your network. Whether the problem is in the network or is configuration is not within the agreed scope of work as per the agreement of the purchase of the telephone system. Below is an excerpt from the terms in the quote that was agreed upon and implemented;
T-1 Data RequirementsData network shall be designed to utilize QOS (Quality Of Service) for routing. IP numbers will be assigned to Missouri Bell Telecom by Glencove Marine IT persons for use as end points for the IP voice for each location. Rule of thumb allocation would be 56K per active IP conduit of voice. (4 Conduit reserve based on call average handling per outbound location.
It was never in our scope to diagnose network issues.
NO ONE abuses my users but ME <g>.
Anyway, back to the assessment. There was never even mention of an assessment. In fact, after the IPO was installed and we started having so many problems, I was specifically told, well here, read it yourself, this is just an excerpt:
"Dawn,
I am aware of the problems that you are having with your network. Whether the problem is in the network or is configuration is not within the agreed scope of work as per the agreement of the purchase of the telephone system. Below is an excerpt from the terms in the quote that was agreed upon and implemented;
T-1 Data RequirementsData network shall be designed to utilize QOS (Quality Of Service) for routing. IP numbers will be assigned to Missouri Bell Telecom by Glencove Marine IT persons for use as end points for the IP voice for each location. Rule of thumb allocation would be 56K per active IP conduit of voice. (4 Conduit reserve based on call average handling per outbound location.
It was never in our scope to diagnose network issues.
- Thread starter
- #29
He also says that they maintain "thousands" of systems, a claim I find dubiuos considering that this is a fairly small market. Our three county area has approximately 80k people, how many "thousands" of systems could ther possibly be?!?
- Thread starter
- #30
ProviderReborn
Technical User
He has many thousands of systems all without Park facility by the sounds of things.
Oh the entertainment it brings me knowing how terrible some one can be at some thing.
Dawn, well done for hanging in there.
ACA - IP Office Implement
ACA - IP Telephony
ACS - IP Office Implement (Aug 30th)
Oh the entertainment it brings me knowing how terrible some one can be at some thing.
Dawn, well done for hanging in there.
ACA - IP Office Implement
ACA - IP Telephony
ACS - IP Office Implement (Aug 30th)
Dawn,
The network assesment does not neccessarily mean that the BP will fix any network issues it may discover. It does however provide documentation that your network has been assessed for certain parameters which Avaya specifies must be documneted and meet minimum requirements in order for Avaya to support the implementation. Without the network assesment, Avaya is not responsible to support your system according to Avayas support policies. The network assessment is supposed to verify, and document that the network can support the application currently. It does not mean they have to configure your network for you, or anyhting like that.
Last I knew, Avaya requires two IPO implement product authorized techs on staff in order for a BP to implement the IPO. They may not go around looking for those who fall out of compliance, or may not strictly enforce the policy, but last I knew it was required. I know when I got my PA it was to gain compliance for my BP to implement the IPO.
The network assesment does not neccessarily mean that the BP will fix any network issues it may discover. It does however provide documentation that your network has been assessed for certain parameters which Avaya specifies must be documneted and meet minimum requirements in order for Avaya to support the implementation. Without the network assesment, Avaya is not responsible to support your system according to Avayas support policies. The network assessment is supposed to verify, and document that the network can support the application currently. It does not mean they have to configure your network for you, or anyhting like that.
Last I knew, Avaya requires two IPO implement product authorized techs on staff in order for a BP to implement the IPO. They may not go around looking for those who fall out of compliance, or may not strictly enforce the policy, but last I knew it was required. I know when I got my PA it was to gain compliance for my BP to implement the IPO.
I really do not blame this IPO tech for not knowing it all. This tech whom we are all (including myself) berating is probably doing the best he knows how. I imagine the situation is about like this.
Avaya offers directly or through its approved sources classroom traing, virtual classroom training, self-training materials/packages, online training, online testing for course material knowledge verification, and for product authorization course programs. There are also third party non-aproved training sources, consultants available for field training, other BP's who will train your techs for a price, and even Avaya techs who can train you for a price.
Therefore there is no reason why a BP should have a tech in place who is not properly trained, and their skill sets verified via tools provided by Avaya.
Chances are 100% if the tech is not qualified that the BP did not provide a qualified tech. The BP is responsible to provide qualified implementors, the techs job is to do their best with what they have. If they have not been trained, then it is not their fault, but the BP who failed to provide the training, and yet put the tech in the position.
We could all argue as to whos duty it is to be competent, trained, and authorized, and who should provide for the tools, time, and resources including financial for the time, and the cost of training for the tech. That is another issue, and one for debate.
Avaya offers directly or through its approved sources classroom traing, virtual classroom training, self-training materials/packages, online training, online testing for course material knowledge verification, and for product authorization course programs. There are also third party non-aproved training sources, consultants available for field training, other BP's who will train your techs for a price, and even Avaya techs who can train you for a price.
Therefore there is no reason why a BP should have a tech in place who is not properly trained, and their skill sets verified via tools provided by Avaya.
Chances are 100% if the tech is not qualified that the BP did not provide a qualified tech. The BP is responsible to provide qualified implementors, the techs job is to do their best with what they have. If they have not been trained, then it is not their fault, but the BP who failed to provide the training, and yet put the tech in the position.
We could all argue as to whos duty it is to be competent, trained, and authorized, and who should provide for the tools, time, and resources including financial for the time, and the cost of training for the tech. That is another issue, and one for debate.
- Thread starter
- #34
TheProvider, thanks for the compliment I have a basic need to solve things, ad once my teeth are sunk in, I obsess until I find a solution.
aarenot, I wouldn't have expected them to configure my network, but it might have been nice to know they should have done one at the time. I can fully appreciate why Avaya would have that as a requirement. Of course we now know that mos tof my problems had nothing to do with the network, and as a update, I have had one report of a drop today, I saw no apparent cause, so it may have just been a hitch. No other reports, and I have asked. On the other hand, our phones have not been as busy as usual. We are now into the school year so alot of tourism drops until Labor Day. The vigil shall continue.
I have a basic need to solve things, ad once my teeth are sunk in, I obsess until I find a solution. aarenot, I wouldn't have expected them to configure my network, but it might have been nice to know they should have done one at the time. I can fully appreciate why Avaya would have that as a requirement. Of course we now know that mos tof my problems had nothing to do with the network, and as a update, I have had one report of a drop today, I saw no apparent cause, so it may have just been a hitch. No other reports, and I have asked. On the other hand, our phones have not been as busy as usual. We are now into the school year so alot of tourism drops until Labor Day. The vigil shall continue.
- Thread starter
- #35
aarenot, I agree, I know that the implementor had 1 week training on this system at some Avaya classroom. In fact, when they first installed the system and arrogantly proclaimed that they wouldn't allow me to work on it for a year, they made the caveat that they would allow me work on it if I went to the same class.
Obviously, things have changed a bit since then <g>.
I would consider becoming a BP if I weren't so darn lazy...
Obviously, things have changed a bit since then <g>.
I would consider becoming a BP if I weren't so darn lazy...
mattKnight
Programmer
Whilst I agree with aarenots comments about training. I remember after completing my training course (and gaining ACA). It was only after 12 months that I began to feel comfortable with the system. Someone recently qualified can recite the "Avaya Hymn Sheet" but doesn't have enough experience to back it up. Likewise if you have only implemented single site systems (regardless of size) you may well struggle with multi-site systems
Dawn - The BP you have are they primarily a telecoms company or a data networking company? In the UK, we have both types - the data people thinking that because the anacronym IP is in the title, the IP office is a data product. Making a sweeping generalisation - the data company implementations disregards basic telephony issues and many Telecoms implementors miss on the IP functionality...
The point I am getting to (1/2 bottle of wine later) is that for a mulitsite implementation to be effective, the data and telcoms teams have to co-operate. The first basic step is to analyse what infrastructure is in place including network performance testing (infrastructure readiness test aka SIRS) This is supposed to measure packet loss, jitter, delay and so on over a protracted length of time (1 week min) and the report produced should graph those critical values. This report shoud be used to improve / reconfigure the data network for optimum voice performance. The report also needs to given to Avaya (as already mentioned for support purposes) Without one of these assesments it is all too easy for the BP to pass the buck back to the network... QoS is almost always listed as an area for improvement!!!
The reason that SIRS is so often overlooked - Price! In teh UK a SIRS test from an Avaya approved comtractor is £2,500. No-one wants to pay that as a pre-install cost!
I am gald that you appear to have finally got an answer to your call drop issues! Maybe you shoudl follow aarenots suggestions - it seems there are 1000's of systems in your area that need someone to look after them, with a clue!
Take Care
Matt
If at first you don't succeed, skydiving is not for you.
Dawn - The BP you have are they primarily a telecoms company or a data networking company? In the UK, we have both types - the data people thinking that because the anacronym IP is in the title, the IP office is a data product. Making a sweeping generalisation - the data company implementations disregards basic telephony issues and many Telecoms implementors miss on the IP functionality...
The point I am getting to (1/2 bottle of wine later) is that for a mulitsite implementation to be effective, the data and telcoms teams have to co-operate. The first basic step is to analyse what infrastructure is in place including network performance testing (infrastructure readiness test aka SIRS) This is supposed to measure packet loss, jitter, delay and so on over a protracted length of time (1 week min) and the report produced should graph those critical values. This report shoud be used to improve / reconfigure the data network for optimum voice performance. The report also needs to given to Avaya (as already mentioned for support purposes) Without one of these assesments it is all too easy for the BP to pass the buck back to the network... QoS is almost always listed as an area for improvement!!!
The reason that SIRS is so often overlooked - Price! In teh UK a SIRS test from an Avaya approved comtractor is £2,500. No-one wants to pay that as a pre-install cost!
I am gald that you appear to have finally got an answer to your call drop issues! Maybe you shoudl follow aarenots suggestions - it seems there are 1000's of systems in your area that need someone to look after them, with a clue!
Take Care
Matt
If at first you don't succeed, skydiving is not for you.
Matt,
I have to agree with you on the assessment of data, and telecom background people and the IPO. They both come in thinking they know it all, and the other portion of the equation is the trained monkey work.
In my experience Telecom guys seem to figure out their inadequacy quickly, and either get out, or learn what they need to. 40% get out, and 40% learn what they need to. The data guys are much the same 20% get out, and 40% learn what they need to.
BP's never get out, and 20% learn what they need to.
I have to agree with you on the assessment of data, and telecom background people and the IPO. They both come in thinking they know it all, and the other portion of the equation is the trained monkey work.
In my experience Telecom guys seem to figure out their inadequacy quickly, and either get out, or learn what they need to. 40% get out, and 40% learn what they need to. The data guys are much the same 20% get out, and 40% learn what they need to.
BP's never get out, and 20% learn what they need to.
kurthansen
Technical User
No wonder people have such a bad view on the IP Office.
- Thread starter
- #39
Morning all, well, drops occurred over the weekend, I am bummed out.
Meanwhile, my BP sent me the following, I'm very concerned here:
We are still planning on being there, but there will not be an Avaya rep on the phone. They stated to me that there is no current trouble ticket on the project, that all prior tickets were resolved, that there are no known bugs that reflect this outcome, and that Avaya equipment is a member on the T-1 and is not acting as a gateway or CSU/DSU. They also stated it is against their policy to become involved in vendor meets with Telco providers, as that is what Missouri bell is trained to do. They have the last set of translations and error logs and have reviewed the equipment swaps we have done since so far it has all been done as RMAs. They have no problem with opening a new ticket to peruse any issues that may be introduced as a result of the vendor meet.
Personally, I understand their point but I was hoping they would do it anyway. We will still be there at 1PM.
To reconfirm, which site at 1PM? 21MM or main?
Meanwhile, my BP sent me the following, I'm very concerned here:
We are still planning on being there, but there will not be an Avaya rep on the phone. They stated to me that there is no current trouble ticket on the project, that all prior tickets were resolved, that there are no known bugs that reflect this outcome, and that Avaya equipment is a member on the T-1 and is not acting as a gateway or CSU/DSU. They also stated it is against their policy to become involved in vendor meets with Telco providers, as that is what Missouri bell is trained to do. They have the last set of translations and error logs and have reviewed the equipment swaps we have done since so far it has all been done as RMAs. They have no problem with opening a new ticket to peruse any issues that may be introduced as a result of the vendor meet.
Personally, I understand their point but I was hoping they would do it anyway. We will still be there at 1PM.
To reconfirm, which site at 1PM? 21MM or main?
AZJeepGirl
Programmer
I would demand they open a ticket. They will probably need to call their distributer as I seriously doubt their company is an SMBS expert. The distributer will then open the ticket with AVAYA. If they can't handle this Dawn, then shoot me an email. Unfortunately it would have to go thru the company if work for, but we can get the ball rolling. I have the numbers for the escalation managers at AVAYA. You would of course still need to have the telco involved, and I couldn't come to the site...but you are there and seem pretty freaking capable to me (unlike the folks whom you've been dealing with)! You can get me at cjsteeber at ya hoo dot co m.
____________________________________
I'd rather be jeepin'! 0|||||||0
____________________________________
I'd rather be jeepin'! 0|||||||0
- Status