This Book
This book has been a part of my life for the last four years. It started as an outline when I was working at Intel. Herman D'Hooge had produced the first version of the TAPI (Telephony API) specification, and Paul Drews was leading its implementation. I was working in a group building telephony boards and telephony applications. I remember it was quite a challenge debugging early TAPI applications that were using alpha versions of TAPI 0.9 through first-try TSPs running in VxDs acting as a multi-tasking OS below single-tasking Windows 3.1 communicating with another OS running on a preproduction DSP mounted on a prototype telephony board. If you think the Telephony API hard to program now, you don't know what you missed. Which brings me to the purpose of this book. The Telephony API is a fundamental piece of the communications architecture of the modern versions of Windows, that is, Windows 9x, Windows NT 41, and even Windows CE. However, it's fairly large and somewhat daunting to the uninitiated. Still, there is an underlying architecture and a philosophy that, once understood, makes TAPI, if not especially easy, at least approachable. As one of the world's first TAPI programmers, I feel I have a TAPI story to tell that will help ease you into the world of Windows Telephony. This book tells that story.
Who This Book Is For
This book is for any C or C11 developer interested in building telephony applications under Windows. This may include human-assisted applications such as call control, call monitoring, and predictive dialing or human-free applications such as audiotex, voicemail, and automatic call directing. The range of telephony applications includes really anything you can do when you hook a telephone or telephone line to a computer. This book is also useful for the TAPI Service Provider developer, as an example of both how typical TAPI applications are written as well as how to write an actual TSP.
Simplifying TAPI
This book will be especially useful to the C11 and Microsoft Foundation Classes programmer. In the course of developing TAPI applications, I found myself doing the same things over and over. So, like any C11 programmer, I built a class library. And then I threw it away. I built another one, and I threw that one away, too.1 Finally, I built the Telephony Framework (TFX). The TFX provides a set of C11 classes that, while leveraging the object model built into TAPI, removes much of the grunt work of developing TAPI applications. Since I was using the TFX to build MFC applications, it has been designed to work well in MFC applications. In addition, many of the
samples in this book use the TFX in MFC applications to demonstrate how TAPI is used. That's not to say that this book is useful only to MFC programmers. In fact, only half of the chapters of this book mention MFC. Those that do always describe and show how the underlying TAPI functions work before they show the TFX equivalent. If you never want to use the TFX or MFC or even C11, I believe this book still provides a good starting place for any TAPI developer. The TFX itself is really just a repository for a set of classes that I find useful when developing telephony applications in C11. I present them so that the sample applications, and therefore the concepts, are a little cleaner. If you want to use the TFX to build telephony applications, feel free. If you'd rather just use it as a set of code to copy and paste from or as an illustration of the concepts of TAPI, that's OK, too.
Who I Am
Whenever I pick up a technical book of any kind, I always wonder what makes the author qualified to write the book. I assume you do the same, so I wanted to tell you a little bit about myself. I've done telephony work of one kind or another for about nine years as of the time of this writing. I started at Spanlink Communications building small- to medium-sized multicaller voicemail, audiotex, and host access systems. Those 386 systems, at their peak, handled about 50 simultaneous calls at a rate of 1,200 calls/day.2 After about three years at Spanlink, I moved to Intel to help with their telephony efforts. Although the telephony boards I helped to build never saw the light of day, they did spawn the current crop of video conferencing boards that Intel still makes. While at Intel, I developed a bunch of TAPI applications, provided many bug reports, submitted a telephony-related patent,3 and wrote the original outline of this book . . . which I then filed in a drawer. I left my software engineering job at Intel to become an instructor at DevelopMentor. There, I began hanging out with the cream of the crop of the Windows community. These were the guys who spoke at the conferences, wrote the magazine articles, and authored the books that I knew and loved. What can I say? I was inspired. A couple of e-mails later and this book was born. TAPI has evolved since I first put fingers to keyboard composing that original outline. It's moved from 16-bit TAPI 1.3 running under Windows 3.x, to half 16-bit/half 32-bit TAPI 1.4 running under Windows 95, to full 32-bit TAPI 2.0 running under Windows NT 4.0, to the latest COM-based TAPI 3.0 slated to run under Windows NT 5.0. While I have drawn the line at covering any 16-bit versions of TAPI, I've tried to cover the basics of writing both TAPI applications as well as TAPI Service Providers for all 32-bit versions. The last chapter provides
an advance preview of TAPI 3.0.
Need More?
This book is not an encyclopedia of TAPI. Instead, I have emphasized its architecture and philosophy with the idea that anything else you need to learn will fit more easily into your newfound understanding. I can recommend several additional resources. First, I recommend the online documentation. The overviews of both TAPI and the TSPI included with the platform SDK are excellent. They were an immensely helpful resource in my understanding some of the more obscure parts of TAPI, as well as helping to track the changes from one version to another. I also recommend several resources on the Internet. Two public newsgroups,microsoft.public.win32.programming.tapi and microsoft.public.win95.commtelephony, have many excellent people answering questions. If your local USENET provider doesn't have these newsgroups, Microsoft maintains a public news server at msnews.microsoft.com. Microsoft maintains a World Wide Web ("Web") site dedicated to the communications infrastructure of Windows that includes the latest news onTAPI. That address is www.microsoft.com/communications. It alsomaintains an FTP site with some tools and samples at ftp.microsoft.com/developr/TAPI. If you'd like answers to some questions about TAPI that I didn't cover enough in the book and you suspect that they have been asked before, I recommend the two TAPI Frequently Asked Questions pages that I'm aware of: http//ourworld.compuserve.com/homepages/schenck/tapifaq.txt http//ourworld.compuserve.com/homepages/bruce_pennypacker/ tapifaq.htm
Both are well-maintained by long-time TAPI developers Bruce Pennypacker and Grant Schenck. If you post a question on one of the newsgroups, it's likely that one of these two guys will be providing the answer. If you'd like more information from me, the Web site for this book is maintained at www.sellsbrothers.com/telprog and will include any updates that I need to make after the book is published. Finally, if you'd like to comment to me about this book, you may send me e-mail at csells@sellsbrothers.com.
The Source
The source code for all of the samples provided with the book as well as the entire TFX is provided on the Web sitehttp://www.sellsbrothers.com/telprog. I thought long and hard about providing the source as a set of appendices for this book and ultimately decided against it. Printed source is sometimes useful for understanding specific implementation details. As these details come up, I tried very hard to put the significant source into the text of the chapters themselves. On the other hand, having the full source printed at the end of the book performs no real service except to puff up the size (and potentially the perceived cove age) of the book. As my favorite books are of the thin, focused variety, I found this unnecessary bloating unappealing to me. Plus, I may save a few trees in the bargain.
Acknowledgments
This book is the concentrated effort of many individuals. First, I want to thank my wife, Melissa. She tolerates me and my work. What could be more helpful to a telephony nerd than that? And I'd like to thank my kids, John and Tom, for bringing me back to reality when I needed it most. You guys give meaning and perspective to everything I do. I'd like to thank my publishing team at Addison-Wesley. Because I'm such a sloth of an author, this has included several people who have come and gone during the life of this project, as well as others who have stuck it out the whole time, including Mike Hendrickson, Ben Ryan, J. Carter Shanklin, Alan Feuer, and Rachel Beavers. I'd also like to thank the folks who invented, implemented, evangelized, and supported this technology, including Herman D'Hooge, Raman Srinivasan, Paul Drews, Guy Blair, Toby Nixon, Dan Knudson, Charles Fitzgerald, and Mitch Goldberg. As there the guys in the trenches battling it out over my clumsy prose, the reviewers need a great deal of thanks. They are Jon Flanders, Tim Ewald, Raman Srinivasan, Alan Moffet, Bruce Pennypacker, Grant Schenck, R. Keith Cox, and Erik Gilbert. I'd really like to thank Tim specifically. He had no telephony background before reading this book, but he has such great insight into the flow of any story that his feedback was indescribably valuable. I'd like to thank Brett Shockley, Todd Parentau, and Skip Singer for the job at Spanlink Communications, where I got my start in telephony. I'd like to thank Matt Katzer for hiring me at Intel, where I was allowed to play with TAPI before nearly anyone else. Finally, I'd like to thank Mike Abercrombie and Don Box for hiring me at DevelopMentor. DevelopMentor has really given me the skills to tell this story. Don specifically showed me what the term "expert" means and why no one can ever truly be one (with the possible exception of Don himself).These people have made the book as good as it is. Of course, all mistakes and omissions are mine.
This Book
This book has been a part of my life for the last four years. It started as an outline when I was working at Intel. Herman D'Hooge had produced the first version of the TAPI (Telephony API) specification, and Paul Drews was leading its implementation. I was working in a group building telephony boards and telephony applications. I remember it was quite a challenge debugging early TAPI applications that were using alpha versions of TAPI 0.9 through first-try TSPs running in VxDs acting as a multi-tasking OS below single-tasking Windows 3.1 communicating with another OS running on a preproduction DSP mounted on a prototype telephony board. If you think the Telephony API hard to program now, you don't know what you missed.
Which brings me to the purpose of this book. The Telephony API is a fundamental piece of the communications architecture of the modern versions of Windows, that is, Windows 9x, Windows NT 41, and even Windows CE. However, it's fairly large and somewhat daunting to the uninitiated. Still, there is an underlying architecture and a philosophy that, once understood, makes TAPI, if not especially easy, at least approachable. As one of the world's first TAPI programmers, I feel I have a TAPI story to tell that will help ease you into the world of Windows Telephony. This book tells that story.
Who This Book Is For
This book is for any C or C++ developer interested in building telephony applications under Windows. This may include human-assisted applications such as call control, call monitoring, and predictive dialing or human-free applications such as audiotex, voicemail, and automatic call directing. The range of telephony applications includes really anything you can do when you hook a telephone or telephone line to a computer. This book is also useful for the TAPI Service Provider developer, as an example of both how typical TAPI applications are written as well as how to write an actual TSP.
Simplifying TAPI
This book will be especially useful to the C++ and Microsoft Foundation Classes programmer. In the course of developing TAPI applications, I found myself doing the same things over and over. So, like any C++ programmer, I built a class library. And then I threw it away. I built another one, and I threw that one away, too. Finally, I built the Telephony Framework (TFX). The TFX provides a set of C++ classes that, while leveraging the object model built into TAPI, removes much of the grunt work of developing TAPI applications. Since I was using the TFX to build MFC applications, it has been designed to work well in MFC applications. In addition, many of the samples in this book use the TFX in MFC applications to demonstrate how TAPI is used.
That's not to say that this book is useful only to MFC programmers. In fact, only half of the chapters of this book mention MFC. Those that do always describe and show how the underlying TAPI functions work before they show the TFX equivalent. If you never want to use the TFX or MFC or even C++, I believe this book still provides a good starting place for any TAPI developer.
The TFX itself is really just a repository for a set of classes that I find useful when developing telephony applications in C++. I present them so that the sample applications, and therefore the concepts, are a little cleaner. If you want to use the TFX to build telephony applications, feel free. If you'd rather just use it as a set of code to copy and paste from or as an illustration of the concepts of TAPI, that's OK, too.
Who I Am
Whenever I pick up a technical book of any kind, I always wonder what makes the author qualified to write the book. I assume you do the same, so I wanted to tell you a little bit about myself. I've done telephony work of one kind or another for about nine years as of the time of this writing. I started at Spanlink Communications building small- to medium-sized multicaller voicemail, audiotex, and host access systems. Those 386 systems, at their peak, handled about 50 simultaneous calls at a rate of 1,200 calls/day. After about three years at Spanlink, I moved to Intel to help with their telephony efforts. Although the telephony boards I helped to build never saw the light of day, they did spawn the current crop of video conferencing boards that Intel still makes. While at Intel, I developed a bunch of TAPI applications, provided many bug reports, submitted a telephony-related patent, and wrote the original outline of this book . . . which I then filed in a drawer.
I left my software engineering job at Intel to become an instructor at DevelopMentor. There, I began hanging out with the cream of the crop of the Windows community. These were the guys who spoke at the conferences, wrote the magazine articles, and authored the books that I knew and loved. What can I say? I was inspired. A couple of e-mails later and this book was born.
TAPI has evolved since I first put fingers to keyboard composing that original outline. It's moved from 16-bit TAPI 1.3 running under Windows 3.x, to half 16-bit/half 32-bit TAPI 1.4 running under Windows 95, to full 32-bit TAPI 2.0 running under Windows NT 4.0, to the latest COM-based TAPI 3.0 slated to run under Windows NT 5.0. While I have drawn the line at covering any 16-bit versions of TAPI, I've tried to cover the basics of writing both TAPI applications as well as TAPI Service Providers for all 32-bit versions. The last chapter provides an advance preview of TAPI 3.0.
Need More?
This book is not an encyclopedia of TAPI. Instead, I have emphasized its architecture and philosophy with the idea that anything else you need to learn will fit more easily into your newfound understanding. I can recommend several additional resources. First, I recommend the online documentation. The overviews of both TAPI and the TSPI included with the platform SDK are excellent. They were an immensely helpful resource in my understanding some of the more obscure parts of TAPI, as well as helping to track the changes from one version to another.
I also recommend several resources on the Internet. Two public newsgroups, microsoft.public.win32.programming.tapi and microsoft.public.win95.commtelephony, have many excellent people answering questions. If your local USENET provider doesn't have these newsgroups, Microsoft maintains a public news server at msnews.microsoft.com.
Microsoft maintains a World Wide Web ("Web") site dedicated to the communications infrastructure of Windows that includes the latest news on TAPI. That address is http://www.microsoft.com/communications. It also maintains an FTP site with some tools and samples at ftp://ftp.microsoft.com/developr/TAPI.
If you'd like answers to some questions about TAPI that I didn't cover enough in the book and you suspect that they have been asked before, I recommend the two TAPI Frequently Asked Questions pages that I'm aware of:
http://ourworld.compuserve.com/homepages/schenck/tapifaq.txt
http://ourworld.compuserve.com/homepages/bruce_pennypacker/ tapifaq.htm Both are well-maintained by long-time TAPI developers Bruce Pennypacker and Grant Schenck. If you post a question on one of the newsgroups, it's likely that one of these two guys will be providing the answer.
If you'd like more information from me, the Web site for this book is maintained at http://www.sellsbrothers.com/telprog and will include any updates that I need to make after the book is published. Finally, if you'd like to comment to me about this book, you may send me e-mail at csells@sellsbrothers.com.
The Source
The source code for all of the samples provided with the book as well as the entire TFX is provided on the Web site http://www.sellsbrothers.com/telprog. I thought long and hard about providing the source as a set of appendices for this book and ultimately decided against it. Printed source is sometimes useful for understanding specific implementation details. As these details come up, I tried very hard to put the significant source into the text of the chapters themselves. On the other hand, having the full source printed at the end of the book performs no real service except to puff up the size (and potentially the perceived coverage) of the book. As my favorite books are of the thin, focused variety, I found this unnecessary bloating unappealing to me. Plus, I may save a few trees in the bargain.
Acknowledgments
This book is the concentrated effort of many individuals. First, I want to thank my wife, Melissa. She tolerates me and my work. What could be more helpful to a telephony nerd than that? And I'd like to thank my kids, John and Tom, for bringing me back to reality when I needed it most. You guys give meaning and perspective to everything I do.
I'd like to thank my publishing team at Addison-Wesley. Because I'm such a sloth of an author, this has included several people who have come and gone during the life of this project, as well as others who have stuck it out the whole time, including Mike Hendrickson, Ben Ryan, J. Carter Shanklin, Alan Feuer, and Rachel Beavers.
I'd also like to thank the folks who invented, implemented, evangelized, and supported this technology, including Herman D'Hooge, Raman Srinivasan, Paul Drews, Guy Blair, Toby Nixon, Dan Knudson, Charles Fitzgerald, and Mitch Goldberg.
As they're the guys in the trenches battling it out over my clumsy prose, the reviewers need a great deal of thanks. They are Jon Flanders, Tim Ewald, Raman Srinivasan, Alan Moffet, Bruce Pennypacker, Grant Schenck, R. Keith Cox, and Erik Gilbert. I'd really like to thank Tim specifically. He had no telephony background before reading this book, but he has such great insight into the flow of any story that his feedback was indescribably valuable.
I'd like to thank Brett Shockley, Todd Parentau, and Skip Singer for the job at Spanlink Communications, where I got my start in telephony. I'd like to thank Matt Katzer for hiring me at Intel, where I was allowed to play with TAPI before nearly anyone else. Finally, I'd like to thank Mike Abercrombie and Don Box for hiring me at DevelopMentor. DevelopMentor has really given me the skills to tell this story. Don specifically showed me what the term "expert" means and why no one can ever truly be one (with the possible exception of Don himself).
These people have made the book as good as it is. Of course, all mistakes and omissions are mine.
Loading...