Nolan Harvey (Comp E) finished his third tour at Adtran.

Nolan Harvey is now a senior in the Computer Engineering program. He is from Union , Kentucky where he graduated from Ryle High School . Here is a detailed report of his 3rd and final work session.

  "The Integrated Access Devices group at Adtran is primarily concerned with adding new features and fixing bugs in the Adtran Operating System. They code in C and C++ as well as some xml (for CLI and web interfaces) and perl (for scripting).

  Since the IAD group focuses on the voice products it requires an in-depth knowledge of the Session Initiation Protocol (SIP). SIP is the protocol that our voice products use to setup and tear down voice over IP calls. For instance, SIP is used when one phone wants to call another. Once the two endpoints are connected and media (sound) is flowing SIP is not used until users want to hang up, put someone on hold, initiate a 3-way call, etc. I had to learn how SIP messages are composed and what each header in a SIP message means. SIP messages tell everything about the call--who the caller is, who the recipient is, any hops that exist between the two endpoints, among other things.

  Once I became familiar with SIP I was asked to help implement a new feature in the router products called transparent proxy. All I had to do was turn on certain flags in the code so that transparent proxy could be used. Once I built the code and fixed any errors associated with these changes I had to analyze the effect this had on the size of the code. What I did was run the before and after files through a script that would compare sections of the code and display the amount of change. I had to make sure that implementing transparent proxy did not increase the size of the code by an unreasonable amount. Once I found these results I published them on an internal wiki page so the other design engineers could view the results.

  Next I was asked to create a command line interface (CLI) command that would print out how much RAM the SIP stack was using. The SIP stack simply implements the SIP protocol according to the standard that is set up. This means that it composes the messages so that any device that can handle SIP can look at the messages and determine what to do with it. What I had to do was add a variable to the code that would keep track of the RAM usage. Once I created this variable I needed to create a CLI command that could access this variable and print the results to the user. The CLI, however, cannot directly access any variable. It must interface with a database which can then access the variable. What I had to do was create a cell in the database that made a function call to get this variable I added. This variable is stored in the cell and then my CLI command makes a function call to access this cell. When the command is entered by the user the value in my cell is displayed to the screen.

  One of my final tasks was to add filters to one of our debug commands. What I had to do was give the user the option of filtering a debug command so that only the data they want to see is displayed. Currently there is a command called "debug sip stack messages", what this does is display any SIP messages being received or transmitted in our unit. Obviously this is a large amount of information, most of which the user might not want to see. What I needed to do was give the user the option of only seeing received or transmitted messages, request or response messages, messages based on the SIP method (i.e. INVITE, SUBSCRIBE, REGISTER, etc), messages from a certain user, and messages to a certain user. For example, the user could now type "debug sip stack messages request rx INVITE from John to Bill". This will filter all the SIP messages to only request messages that are received INVITE's from John to Bill. Once all of these combinations were constructed it added a total of 3780 commands to the command line. This will be very helpful to the user because now they can only debug the messages they want to see.

  This term was different from my last in that I got a huge amount of experience working in C++ and learning the concepts applied to a large code-base. Obviously one person cannot maintain a project composed of thousands of files of source code. Certain techniques are applied to the code to make it simpler to understand and easier to manage. I feel like I learned very much about C++ coding in general and some of the more advanced concepts that you don't always implement in class.

  I feel like I was fairly prepared through my coursework for this work term. I had a general understanding of C++ concepts and how object oriented programming works. One thing I hadn't learned in class was how very large projects are organized and maintained and how engineers can work separately to create a working project. Obviously, this would be hard to teach in class because you don't always have time to work on large projects since a semester only lasts about 5 months. However, I do think that the concepts could be taught in class in a very abstract manner and if these classes do exist I have not taken them yet.

  Overall, I think the computer engineering curriculum at UK prepared me for all of my work terms here at Adtran. I usually had a general understanding of the concepts I would be dealing with and work taught me how these concepts are applied to real life. Work also gave me the opportunity to work with more advance programming concepts that are touched on in class but never expanded on. The combination of work and school, I feel, has benefited me greatly for the future.

  I would say that the cost of living in Huntsville is comparable to that of Lexington . The pay at Adtran was good and a co-op could easily go back to school with at least three or four thousand dollars but probably more. Adtran pays based on where you are in your curriculum and your grades in school, so it really does pay to do your best."