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 derfloh 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
-
1
- #2
AZJeepGirl
Programmer
Hi Dawn, They do, but fair warning it will cost you an arm and a leg. AGS is not cheap. 800-345-4960 - Avaya For Hire. You can also open up a ticket on line at their support site at Sorry I haven't followed you issues...So I personally can't be of much help. I will delv into your posts and see if I can see anything as well, but the folks on here look like they have attended to you quite well. I'll let you know if I come up with any other suggestions tho. Good luck
____________________________________
I'd rather be jeepin'! 0|||||||0
____________________________________
I'd rather be jeepin'! 0|||||||0
- Thread starter
- #4
I was just curious since my BP told me that they DON'T HAVE them. Now I know why
AZJeepGirl, thanks, any input would be helpful. I am down to a single error type, and since my boss wants me to let the BP take a more active role I asked for a vendor meet.
However, I am not much of one to give up on something like this. I am stuck on this error and at the risk of repeating myself, here is the error (my thoughts on this error in the next post):
353565408mS CMLineRx: v=40
CMFacility
Line: type=IPLine 40 Call: lid=40 id=734 in=1
353565410mS ERR: EXCEPTION ON MEDIA CONNECTION --- Error from protocol entity! MSDSE --- local timer expired ...
353565410mS CMLOGGING: CALL:2007/08/1410:23,00:01:29,005,16369460655,I,510,510,,,,0,,""n/a,0
353565411mS CD: CALL: 40.734.1 State=2 Cut=3 Music=0.0 Aend="Line 40" (0.0) Bend="Toya Phillips(510)" [Toya Phillips(510)] (1.31) CalledNum=510 (Toya Phillips) CallingNum=16369460655 () Internal=0 Time=95418 AState=2
353565411mS CD: CALL: 40.734.1 Deleted
353565413mS CMLineTx: v=40
CMReleaseComp
Line: type=IPLine 40 Call: lid=40 id=734 in=1
Cause=2, No route to specific transit network/(5ESS)Calling party off hold
353565416mS CMExtnTx: v=510, p1=0
CMReleaseComp
Line: type=DigitalExtn 3 Call: lid=0 id=8799 in=0
Cause=2, No route to specific transit network/(5ESS)Calling party off hold
Timed: 14/08/07 10:24
AZJeepGirl, thanks, any input would be helpful. I am down to a single error type, and since my boss wants me to let the BP take a more active role I asked for a vendor meet.
However, I am not much of one to give up on something like this. I am stuck on this error and at the risk of repeating myself, here is the error (my thoughts on this error in the next post):
353565408mS CMLineRx: v=40
CMFacility
Line: type=IPLine 40 Call: lid=40 id=734 in=1
353565410mS ERR: EXCEPTION ON MEDIA CONNECTION --- Error from protocol entity! MSDSE --- local timer expired ...
353565410mS CMLOGGING: CALL:2007/08/1410:23,00:01:29,005,16369460655,I,510,510,,,,0,,""n/a,0
353565411mS CD: CALL: 40.734.1 State=2 Cut=3 Music=0.0 Aend="Line 40" (0.0) Bend="Toya Phillips(510)" [Toya Phillips(510)] (1.31) CalledNum=510 (Toya Phillips) CallingNum=16369460655 () Internal=0 Time=95418 AState=2
353565411mS CD: CALL: 40.734.1 Deleted
353565413mS CMLineTx: v=40
CMReleaseComp
Line: type=IPLine 40 Call: lid=40 id=734 in=1
Cause=2, No route to specific transit network/(5ESS)Calling party off hold
353565416mS CMExtnTx: v=510, p1=0
CMReleaseComp
Line: type=DigitalExtn 3 Call: lid=0 id=8799 in=0
Cause=2, No route to specific transit network/(5ESS)Calling party off hold
Timed: 14/08/07 10:24
- Thread starter
- #5
Ok, first, who is the protocol entity in this scenario? Is it the IP 406 AT the location losing the calls (this is from Monitor for that location)?
And if the Aend is IP line 40, the IP line at that location, and the Bend is the DS handset, is the error indicative of a loss of communication between the DS and the handset, BOTH local to the site?
And the line I should have included:
353565418mS PRN: EXTN: Toya Phillips received CMFacility msg for deleting ep 0.8799.0 -1 Toya Phillips.-1
This looks to me like it has more to do with the logical channel than with a physical media, but then again I am only an egg...
I found a thesis someone wrote on H.323 terminal, H.245 subset and although I haven't read it all, what I have read seems to indicate that if I can isolate WHO the protocol entity is, then I can go on to figure out WHAT timer and if it is related to our network or something else.
Please forgive me if I am way off the mark
And if the Aend is IP line 40, the IP line at that location, and the Bend is the DS handset, is the error indicative of a loss of communication between the DS and the handset, BOTH local to the site?
And the line I should have included:
353565418mS PRN: EXTN: Toya Phillips received CMFacility msg for deleting ep 0.8799.0 -1 Toya Phillips.-1
This looks to me like it has more to do with the logical channel than with a physical media, but then again I am only an egg...
I found a thesis someone wrote on H.323 terminal, H.245 subset and although I haven't read it all, what I have read seems to indicate that if I can isolate WHO the protocol entity is, then I can go on to figure out WHAT timer and if it is related to our network or something else.
Please forgive me if I am way off the mark
AZJeepGirl
Programmer
Hey Dawn,
You probably already have this but here goes anyway:
I'm not an expert with system monitor by any means, but I will keep researching. From what you posted it looks to me like A is the line a B is the handset and it's lost...
Did you change out the VCM yet? Also, are all the systems now running on 4.0.7?
____________________________________
I'd rather be jeepin'! 0|||||||0
You probably already have this but here goes anyway:
I'm not an expert with system monitor by any means, but I will keep researching. From what you posted it looks to me like A is the line a B is the handset and it's lost...
Did you change out the VCM yet? Also, are all the systems now running on 4.0.7?
____________________________________
I'd rather be jeepin'! 0|||||||0
- Thread starter
- #7
AZJeepGirl, thank you. We changed out the VCM last week, but are still experiecing drops. We have even had a couple at a different site that gets fairly low phone traffic, same error though. All systems are now on 4.0.7 as well.
It just seems to me that this is NOT network or T1 related , the words "media" and "transport" seem to be deceiving in this case. But I have now come around to the idea that the loss is between the line and the handset, because I can find absolutely nothing that indicates differently, and the more I stare at that error, the more that looks like the case. In reading the thesis I came across I would deduce that the protocol entity is the DS unit, and that the handset would be the "other" entity. When looking at the error, A and B ends are clearly the line and the handset.
For example, I can see some packet loss at the location that has had the error a couple times, but it never corresponds with a drop. Likewise at the site I have the biggest drop problem, I see no packet loss at all.
If you read through even a portion of my posts you will discover that 3 months ago I knew NOTHING about phone systems, I have since become somewhat educated. My vendor has given me poor support at best, and I thought it was hilarious yesterday after I pointed out the link you included for Avaya-for-Hire he got quite defensive, and in fact sounded alot like a spoiled child.
Additionally, I asked him to please explain the Media Exception error, at my boss's request. I made a bet with her that he wouldn't answer the question. I won
It just seems to me that this is NOT network or T1 related , the words "media" and "transport" seem to be deceiving in this case. But I have now come around to the idea that the loss is between the line and the handset, because I can find absolutely nothing that indicates differently, and the more I stare at that error, the more that looks like the case. In reading the thesis I came across I would deduce that the protocol entity is the DS unit, and that the handset would be the "other" entity. When looking at the error, A and B ends are clearly the line and the handset.
For example, I can see some packet loss at the location that has had the error a couple times, but it never corresponds with a drop. Likewise at the site I have the biggest drop problem, I see no packet loss at all.
If you read through even a portion of my posts you will discover that 3 months ago I knew NOTHING about phone systems, I have since become somewhat educated. My vendor has given me poor support at best, and I thought it was hilarious yesterday after I pointed out the link you included for Avaya-for-Hire he got quite defensive, and in fact sounded alot like a spoiled child.
Additionally, I asked him to please explain the Media Exception error, at my boss's request. I made a bet with her that he wouldn't answer the question. I won
- Thread starter
- #8
ProviderReborn
Technical User
Hi Dawn, oh what a drama your going through.
I think in reality whilst your picking up on this fantatically.
I need to ask what support are your BP giving?
If you were a customer of mine, And we had been through all this, I had our inhouse Cisco guys look at your Routings I would be raising this to higher tiers through Avaya.
Is your vendor an Avaya BP which is able to get direct support with Avaya, if so I think its possibly about time they got them involved.
1 Question, did you BP do a network assesment before installing your system?
ACA - IP Office Implement
ACA - IP Telephony
ACS - IP Office Implement (Aug 30th)
I think in reality whilst your picking up on this fantatically.
I need to ask what support are your BP giving?
If you were a customer of mine, And we had been through all this, I had our inhouse Cisco guys look at your Routings I would be raising this to higher tiers through Avaya.
Is your vendor an Avaya BP which is able to get direct support with Avaya, if so I think its possibly about time they got them involved.
1 Question, did you BP do a network assesment before installing your system?
ACA - IP Office Implement
ACA - IP Telephony
ACS - IP Office Implement (Aug 30th)
- Thread starter
- #10
TheProvider, LOL, you aren't the first person to ask about the network assessment, and the answer is a resounding NO. I remain dedicated to this issue because I actually CARE. I hate seeing our customers and employees so frustrated.
Like I mentioned in a previous post here, my BP didn't even attempt to answer me when I asked him to explain the error. Instead he asked if we'd replaced the routers at both ends of the trouble site. After all that, here was his ultimate reply:
Avaya has legitimate tech support for dealers and trained personnel. I would want to make it really clear that any decision to pay for any Avaya technicians would be yours. At this point, Avaya has already went through the translations of the switch and verified they are correct. We have physically replaced all the hardware that has anything to do with the problem. The technology works, and I can arrange to show you at least two other sites that are utilizing the same IP technology to transfer calls, so we know the technology works as they are 100% stable and happy.
We can schedule something for mid next week. Don is out with a back injury today, but any day next week we can arrange for a conference call from Avaya support and meet personally with AT&T. It would probably be best not to schedule it on a Monday.
Like I mentioned in a previous post here, my BP didn't even attempt to answer me when I asked him to explain the error. Instead he asked if we'd replaced the routers at both ends of the trouble site. After all that, here was his ultimate reply:
Avaya has legitimate tech support for dealers and trained personnel. I would want to make it really clear that any decision to pay for any Avaya technicians would be yours. At this point, Avaya has already went through the translations of the switch and verified they are correct. We have physically replaced all the hardware that has anything to do with the problem. The technology works, and I can arrange to show you at least two other sites that are utilizing the same IP technology to transfer calls, so we know the technology works as they are 100% stable and happy.
We can schedule something for mid next week. Don is out with a back injury today, but any day next week we can arrange for a conference call from Avaya support and meet personally with AT&T. It would probably be best not to schedule it on a Monday.
- Thread starter
- #11
I might mention too that when he says Avaya went through the translations, what he SHOULD be saying is that sometime about 2 months back they took a couple hours worth of Monitor logs on one day and sent them to Avaya. They haven't looked at Monitor output since, to the best of my knowledge.
ProviderReborn
Technical User
The problem with the IP Office is you can some times get away with poorly programmed systems. I am no way the best engineer but some configs I see are terrible. I hate to say configs I have seen programmed by my fellow collegues.
You of all people know when you first started with your issues, yes your system was working a certain amount, but I have seen all the changes you have made to the system and these things are all well known programming methods of reliable programming.
I have never seen your recorded error, I am one of the guys for our company that gets involved with IP Office multisites Installs, so have seen my fair share of tripe programming and routing.
Are you able to log any pattern to these drops. In any way?
Times/Extensions/Weather conditions/Servers carrying out a scheduled task. Any thing at all.
ACA - IP Office Implement
ACA - IP Telephony
ACS - IP Office Implement (Aug 30th)
You of all people know when you first started with your issues, yes your system was working a certain amount, but I have seen all the changes you have made to the system and these things are all well known programming methods of reliable programming.
I have never seen your recorded error, I am one of the guys for our company that gets involved with IP Office multisites Installs, so have seen my fair share of tripe programming and routing.
Are you able to log any pattern to these drops. In any way?
Times/Extensions/Weather conditions/Servers carrying out a scheduled task. Any thing at all.
ACA - IP Office Implement
ACA - IP Telephony
ACS - IP Office Implement (Aug 30th)
ProviderReborn
Technical User
Interesting. Have been reading some information from another source.
Your all grounded nicely yes?
You are confident with your network.
SO, Your IP Office install, are all the patch leads at the back of the units the correct Avaya supplied 1m patches? Which interlink your DS units to your CCU.
Are you power supplies the correct one for the DS units, if your unsure post up your Voltage details/Watts Ect.
ACA - IP Office Implement
ACA - IP Telephony
ACS - IP Office Implement (Aug 30th)
Your all grounded nicely yes?
You are confident with your network.
SO, Your IP Office install, are all the patch leads at the back of the units the correct Avaya supplied 1m patches? Which interlink your DS units to your CCU.
Are you power supplies the correct one for the DS units, if your unsure post up your Voltage details/Watts Ect.
ACA - IP Office Implement
ACA - IP Telephony
ACS - IP Office Implement (Aug 30th)
- Thread starter
- #14
TheProvider, yes, I have been trying to see if a pattern emerges, and so far this is what I've found:
1. Originally drops were NOT accompanied by specific errors in all events. But that may have been the way Monitor was set up.
2. The BP made alot of config errors, which I have corrected with help from this forum. A great deal of problems, including drops without errors, went away.
3. The remaining drops seem to come in clusters, which prompted us to replace the VCM. You would have the SAME caller dropped 2,3,4,5 times in a row, people started using their cell phones so they wouldn't drop customers.
4. Weather originally was suspected, but has since been ruled out (it hasn't rained in weeks).
5. All errors are now accompanied by the monitor output above, and they still seem to come in clusters, although the rate has steadily dropped and we are now down to 10-15 drops a day, instead of 10-15 drops an hour.
Not much of a pattern, but all I have
1. Originally drops were NOT accompanied by specific errors in all events. But that may have been the way Monitor was set up.
2. The BP made alot of config errors, which I have corrected with help from this forum. A great deal of problems, including drops without errors, went away.
3. The remaining drops seem to come in clusters, which prompted us to replace the VCM. You would have the SAME caller dropped 2,3,4,5 times in a row, people started using their cell phones so they wouldn't drop customers.
4. Weather originally was suspected, but has since been ruled out (it hasn't rained in weeks).
5. All errors are now accompanied by the monitor output above, and they still seem to come in clusters, although the rate has steadily dropped and we are now down to 10-15 drops a day, instead of 10-15 drops an hour.
Not much of a pattern, but all I have
ProviderReborn
Technical User
Are these calls which come into your site locally from your Call provider. Or are these calls which come in and go to another site via your IP Line?
I am assuming the latter here.
ACA - IP Office Implement
ACA - IP Telephony
ACS - IP Office Implement (Aug 30th)
I am assuming the latter here.
ACA - IP Office Implement
ACA - IP Telephony
ACS - IP Office Implement (Aug 30th)
- Thread starter
- #16
AZJeepGirl
Programmer
Hi Dawn,
Do the inbound/transferred calls that are dropped go to the same extension, or is it a random thing? How many exts do you have at your trouble site? Are they all on the exts that have drops assoc. with them on the same module? Verify that if you have DS30's (30 port digital station modules) that you have the correct power supply for the unit (see pdf link below).
Also, what platform is your vmpro/manager app running on? I know some of this seems redundant/irrelivant, but I at this point you've gotten it soooo close to being happy ...LOL.
Anyway here are some more docs that might help...
I know this last one says R1, but the same applies to R2. Make sure your ports are happy on your system and in your routers as well
Is it safe to assume that your so called BP actually ran the bat files for the firewalls?
I assume that you are now using System Status instead of Monitor? (Where are you running the trace from these days?)
____________________________________
I'd rather be jeepin'! 0|||||||0
Do the inbound/transferred calls that are dropped go to the same extension, or is it a random thing? How many exts do you have at your trouble site? Are they all on the exts that have drops assoc. with them on the same module? Verify that if you have DS30's (30 port digital station modules) that you have the correct power supply for the unit (see pdf link below).
Also, what platform is your vmpro/manager app running on? I know some of this seems redundant/irrelivant, but I at this point you've gotten it soooo close to being happy ...LOL.
Anyway here are some more docs that might help...
http://support.avaya.com/elmodocs2/ip_office/tech/us_techtip_no018_Off_hook_station_on_IP_Office.pdf
I know this last one says R1, but the same applies to R2. Make sure your ports are happy on your system and in your routers as well
Is it safe to assume that your so called BP actually ran the bat files for the firewalls?
I assume that you are now using System Status instead of Monitor? (Where are you running the trace from these days?)
____________________________________
I'd rather be jeepin'! 0|||||||0
- Thread starter
- #18
Hi AZJeepGirl, and thank you for all of your research! The calls can drop from any extension at the trouble location. They have a VCM of 8, so I guess that would make them all on the same module. I am pretty sure that it is a DS30, but I will have to double check (can I do that remotely?) and as far as I know it is on the factory power supply.
VM Pro/Manager is running on XP Pro, and it is up to date.
I currently have no firewalls on this system, and I use both SSA and Monitor. I have read over the Monitor pdf you sent me and changed a number of options.
And I have tweaked my QoS for this location on my cisco routers, and have had no drops so far today. Tomorrow will test the system as it is our busiest day of the week.
I will take some time and read over all your links, and I thank you again.
Dawn
VM Pro/Manager is running on XP Pro, and it is up to date.
I currently have no firewalls on this system, and I use both SSA and Monitor. I have read over the Monitor pdf you sent me and changed a number of options.
And I have tweaked my QoS for this location on my cisco routers, and have had no drops so far today. Tomorrow will test the system as it is our busiest day of the week.
I will take some time and read over all your links, and I thank you again.
Dawn
kurthansen
Technical User
Dawn,
Do calls from inside to your trouble site get dropped at all or is is just calls from outside?
Do calls from inside to your trouble site get dropped at all or is is just calls from outside?
- Thread starter
- #20
kurthansen, originally internal calls were being dropped, we eliminated that when we finally removed all the mesh routiing. Now it is most often straigh inbound, or transfers from our Hwy location. I also had 2 drops in the last week from my 1mm, same error.
However, today has been extrordinarily drop free. I am hopeful that the tweak of the QoS is responsible, but I am not holding my breath.
We will see how the we fare over the weekend
However, today has been extrordinarily drop free. I am hopeful that the tweak of the QoS is responsible, but I am not holding my breath.
We will see how the we fare over the weekend
- Status
