I wrote two posts in my Avaya blog, summarizing my experience with BCMS in small call center environments. Thought someone might find it useful. 
Part 1, Real Time: Part 2, Historical:
Part 1, Real Time: Part 2, Historical:
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 wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
BCMS tips for small call centers 1
- Thread starter nohuhu
- Start date
- Status
AvayaTier3
Technical User
You should try using terminal type "sunt" and allow resize of window to 80 by 25 to get function key labels.
A great teacher, does not provide answers, but methods to teach others "How and where to find the answers"
bsh
36 years Bell, AT&T, Lucent, Avaya
Tier 3 for 26 years and counting
A great teacher, does not provide answers, but methods to teach others "How and where to find the answers"
bsh
36 years Bell, AT&T, Lucent, Avaya
Tier 3 for 26 years and counting
-
1
- Thread starter
- #3
AvayaTier3,
cool, never knew that. thanks. i would also add that with this terminal code, neither "AT&T 513" nor "Sun Xterm" works, but setting keyboard type to "ESC[n~" does the trick.
p.s. do you, by any chance, have some old dusty developer's manual describing 513's state machine and escape codes? or 4410's? function key codes are all over internet but some codes like screen redraw and line fill i had to reverse engineer and i'm not sure i got them right. the best would be a document describing 513/4410 as compared to vt100, a diff of sorts. that'd be just priceless...
cool, never knew that. thanks.
i would also add that with this terminal code, neither "AT&T 513" nor "Sun Xterm" works, but setting keyboard type to "ESC[n~" does the trick.p.s. do you, by any chance, have some old dusty developer's manual describing 513's state machine and escape codes? or 4410's? function key codes are all over internet but some codes like screen redraw and line fill i had to reverse engineer and i'm not sure i got them right.
the best would be a document describing 513/4410 as compared to vt100, a diff of sorts. that'd be just priceless...
AvayaTier3
Technical User
Code:
KEY 4410/4425 ESCAPE SEQUENCE
Clear Field EscOS
Help EscOT
Next Form EscOU
Next Page EscOV
Previous Page EscOW
Submit (enter) EscOR
Cancel EscOP
Refresh EscOQ
Edit Escf6
GoToPage EscOr
KEY 513 ESCAPE SEQUENCE
Clear Field Esc[J
Help EscOm
Next Page Esc[U
Previous Page Esc[V
Submit (enter) EscSB
Cancel EscOw
Refresh EscNa
GoToPage EscOr
Edit Escf6A great teacher, does not provide answers, but methods to teach others "How and where to find the answers"
bsh
36 years Bell, AT&T, Lucent, Avaya
Tier 3 for 26 years and counting
- Thread starter
- #6
AvayaTier3,
nope, that's not it. functional key sequences are long known, what i'm talking about is documentation for inner workings of the terminal itself. how was ASA developed? programmers should have had access to some developers manual regarding the terminal, and that is what i need...
nope, that's not it. functional key sequences are long known, what i'm talking about is documentation for inner workings of the terminal itself. how was ASA developed? programmers should have had access to some developers manual regarding the terminal, and that is what i need...
- Thread starter
- #7
dufus2506,
thanks but i could find only vt100 mentioned there. vt100 is already implemented in full so i don't need it. i need definitions for "exotic" terminal types like 513 and 4410. i think i got 513 almost right in tutty, including several sequences not found in vt100 and used apparently only by 513, but i can't be 100% sure. as for 4410, i know it has some very advanced capabilities like function keys setup from client, probably screen resizing as well, but i can't find the doc. and trying to reverse engineer it is just too time consuming.
thanks but i could find only vt100 mentioned there. vt100 is already implemented in full so i don't need it. i need definitions for "exotic" terminal types like 513 and 4410. i think i got 513 almost right in tutty, including several sequences not found in vt100 and used apparently only by 513, but i can't be 100% sure. as for 4410, i know it has some very advanced capabilities like function keys setup from client, probably screen resizing as well, but i can't find the doc. and trying to reverse engineer it is just too time consuming.
dwalin,
I am working to automate some simple tasks and I am at a stage where I am looking for a way to emulate a useful terminal type so I can read data from the PBX and send change commands. As you clearly understand, the basic VT100 emulation does not include all the keys needed to execute many necessary functions.
I found several terminal emulation apps but they only implement ANSI/VT100 and I grabbed tutty source and am looking through it now. I had hoped the emulations were setup as something like a class and I would be able to port your implementation directly but it seems to be integrated.
Thank you for all your efforts by the way I do not think I would be as optimistic about my success on this project if I did not find this. I can only imagine how long it took you to work all this out.
I was wondering if I could impose upon you to post a text file of the 513 protocol (or spec - I'm not sure what it is supposed to be called) you have worked out / documented so far.
I have been trying to avoid getting into the nitty gritty of terminal emulation protocols but it seems inevitable at this point. If you have any advice on this topic (or on how you got so far on the topic above) I would greatly appreciate anything you could tell me from your own experience.
Thanks,
B
I am working to automate some simple tasks and I am at a stage where I am looking for a way to emulate a useful terminal type so I can read data from the PBX and send change commands. As you clearly understand, the basic VT100 emulation does not include all the keys needed to execute many necessary functions.
I found several terminal emulation apps but they only implement ANSI/VT100 and I grabbed tutty source and am looking through it now. I had hoped the emulations were setup as something like a class and I would be able to port your implementation directly but it seems to be integrated.
Thank you for all your efforts by the way I do not think I would be as optimistic about my success on this project if I did not find this. I can only imagine how long it took you to work all this out.
I was wondering if I could impose upon you to post a text file of the 513 protocol (or spec - I'm not sure what it is supposed to be called) you have worked out / documented so far.
I have been trying to avoid getting into the nitty gritty of terminal emulation protocols but it seems inevitable at this point. If you have any advice on this topic (or on how you got so far on the topic above) I would greatly appreciate anything you could tell me from your own experience.
Thanks,
B
- Thread starter
- #9
menamena,
the best advice i can give you is not to bother with terminal emulations. if you need to interface with pbx, first option to consider is SMS service on AES. it provides several interfaces for list/add/change/remove commands and if'm not mistaken it's free again in AES5. the other option is to go a level down and find documentation for OSSI terminal protocol, it should be available via devconnect. OSSI is a special terminal type that is optimized to be machine readable. that means no messing with screen painting codes, cursor moves, arbitrary data positions differing between switch software versions and other beauties of human readable terminal. it's for developers, go for it - or rather use SMS service, it's the same OSSI but in a nice wrapping.
the best advice i can give you is not to bother with terminal emulations. if you need to interface with pbx, first option to consider is SMS service on AES. it provides several interfaces for list/add/change/remove commands and if'm not mistaken it's free again in AES5. the other option is to go a level down and find documentation for OSSI terminal protocol, it should be available via devconnect. OSSI is a special terminal type that is optimized to be machine readable. that means no messing with screen painting codes, cursor moves, arbitrary data positions differing between switch software versions and other beauties of human readable terminal. it's for developers, go for it - or rather use SMS service, it's the same OSSI but in a nice wrapping.
Thanks for the help! I really appreciate it. I am guessing that OSSI is available out of the box to everyone since it is used by ASA but before I start testing I was wondering if you could confirm that it is.
We have the most stripped down switch I have ever seen so if OSSI isn't freely avalable I know we have not paid for the upgrade that includes it. (I asked our sales rep to confirm but since I am not asking her to pick up a check I have no idea how long she will take to get back to me.)
As for SMS we do not have AES so if I can use OSSI, it is what I will be using.
I am pretty much ready to work with basic Telnet though so if it turns out I have to I will be ready to work with the lower level telnet terms. I only need to add the escape sequences listed above into my test script to submit more than one command.
I'll let you know how it goes if that is what I end up doing. Either way I'll keep you updated.
Thanks again - and thanks a lot for doing the work on Tutty.
We have the most stripped down switch I have ever seen so if OSSI isn't freely avalable I know we have not paid for the upgrade that includes it. (I asked our sales rep to confirm but since I am not asking her to pick up a check I have no idea how long she will take to get back to me.)
As for SMS we do not have AES so if I can use OSSI, it is what I will be using.
I am pretty much ready to work with basic Telnet though so if it turns out I have to I will be ready to work with the lower level telnet terms. I only need to add the escape sequences listed above into my test script to submit more than one command.
I'll let you know how it goes if that is what I end up doing. Either way I'll keep you updated.
Thanks again - and thanks a lot for doing the work on Tutty.
- Thread starter
- #11
menamena,
i cannot confirm this 100% 'cause i have no access to any documents regarding it, but i know for sure OSSI was available at least since R10. back then i planned to ditch the ugly java kludge known as License Installation Tool used to install license files on R10+ RISC-based switches and did a little reverse engineering that showed LIT used OSSI internally. i never came to implementing this feature in tutty, though, because linux-based switches came along with web interfaces and made all this obsolete. but the idea is simple: since OSSI is an internal mechanism and not a feature for sale, it is available on every switch regardless of options purchased.
as for AES, what platform and release you are running? AES can be very cheap to add to CM3+ system, as software only it goes for $30 or such plus server hardware that can be had for $1k or so for production system - and it runs pretty well as virtual machine for development purposes. i'd consider that over messing with low level protocol that avaya want to hide from us. as much as i love to do everything low level and know every detail, this time i'd probably do it by the book, as i just plain don't see any reason not to use ready available API.
i cannot confirm this 100% 'cause i have no access to any documents regarding it, but i know for sure OSSI was available at least since R10. back then i planned to ditch the ugly java kludge known as License Installation Tool used to install license files on R10+ RISC-based switches and did a little reverse engineering that showed LIT used OSSI internally. i never came to implementing this feature in tutty, though, because linux-based switches came along with web interfaces and made all this obsolete. but the idea is simple: since OSSI is an internal mechanism and not a feature for sale, it is available on every switch regardless of options purchased.
as for AES, what platform and release you are running? AES can be very cheap to add to CM3+ system, as software only it goes for $30 or such plus server hardware that can be had for $1k or so for production system - and it runs pretty well as virtual machine for development purposes. i'd consider that over messing with low level protocol that avaya want to hide from us. as much as i love to do everything low level and know every detail, this time i'd probably do it by the book, as i just plain don't see any reason not to use ready available API.
- Status
Similar threads
