My name is Jianfeng Chen. I am a 4th year computer science major enrolled at UCSB. I am currently working at Cisco Systems at Santa Barbara, California. I got the job after looking at an advertisement from Azita Kia, my boss, on the UCSB computer science web page (www.cs.ucsb.edu). Unfortunately she was looking for a grad student, but I went for the position anyway. After two interviews with couple of people, I got a phone call of a job opportunity at Cisco Systems Voice over IP division at Santa Barbara. I accept it and a week later I started working at Cisco Systems.
My over all experience working here have been great. There are only 32 employees here in Santa Barbara. With such small group of people, you become familiar with everyone. With a great working environment, and a well paying job that is a bike distance from campus, I couldn't ask for anything more.
Symbol Technologies Inc (www.symbol.com). currently manufacture NetVision Phones. These phones are portable telephones that can transmit up to 500feet from the receiver. The receiver/transmitter can be attached to our Cisco Voice Over IP routers (VOIP, 3600, 5400) (www.cisco.com).
These portable phones transmit UDP/IP packets to receiver and then the receiver will relay it to the VOIP routers. The UDP/IP packets are used to transport voice data to and from the NetVision Phone usually containing 20-30 ms of voice time. Some of these packets will be lost in transmission due to the nature of wireless phones. This will result in short gaps in the audio playback. This is tolerable for speech applications, it is not suitable for transporting DTMF tones. For example, a continuos DTMF tone with a gap in the middle will be interpreted as the same tone repeated. This will cause serious problems with DTMF recognization programs.
UDP/IP is unreliable and therefore is not suitable to transmit the DTMF/hook-flash tones (hook-flash being on-hook signal / 500ms delay / off-hook signal, i.e. what you use to answer call waiting). Therefore, we need to need use another protocol to send our DTMF tones on.
Version 3 of the H.245 specification has enhanced the UserInputIndication message to allow DTMF and hook-flash signaling to be performed via H.245 channel. Since H245 uses TCP/IP, it is reliable. This introduced a new problem, the synchronization of the H245 and UDP packet. The belief (hope) is that the applications that require DTMF signaling will be tolerant of this timing skew.
Requirements: One of the requirement of this project is to make this H245_DTMF feature optional. So the user gets to choose if they want to use this feature or not. Another feature is to send the DTMF tones in alphanumeric coding or signaling configurable by user. One last feature is to make the duration between on-hook and off-hook configurable by user.
The NetVersion phone uses the UserInputIndication message defined by Version 3 of H.245 protocol. The UserInputIndication message is sent to the router. The data flow is along the path/protocol layer:
tcp -> h.245 -> cch323 -> ccapi -> Session App -> ccapi -> vtsp -> DSP/TSP
The H245 UserInputIndication message arrives at the bottom of the protocol stack layer, and eventually passes up to the layers and plans out using the DSP, and TSP if the UserIndication message is a hook-flash signal to the outgoing call leg. We also have to check to see if the output port is FX0 or FXS. FXS is not capable of playing out the TSP on/off hook signals.
The code of each layer is modified to suit the UserIndication message and the old code is also accessible because the user has the option of not using the H245 UserIndication feature.
Call Control API. An API to provide call control facilities to voice applications. This API
is used as an implementation independent layer to call control.
Digital Signal Processors
Plain Old Telephone Service
Foreign Exchange Station. The network side of a POTS interface
Foreign Exchange Office. The handset side of a POTS interface
Voice Over IP