You are on page 1of 26

Introduction to Voice over IP VoIP was originally developed to provide voice communication between computer users in different locations

. Although it still has this application, it has been further developed into a telephone network in its own right. People using VoIP can call any telephone anywhere in the world and can receive calls on telephone sets connected to the Internet or Local Area Network (LAN). Background It all started back in 1995 when Israeli computer enthusiasts made the first computer to computer voice connection. In the same year this technology was developed into a software package called Internet Phone Software. All that was needed to talk to another computer user was a modem, sound card, speakers, and a microphone. The software digitized and compressed the audio signal before sending it over the Internet in data packets. These voice connections could only occur between computers which had the software installed. The sound quality was very poor -- nowhere near the quality of standard telephone connections. The technology continued to be developed and by 1998 gateways had been established to allow PC-to-phone connections. Later that same year phone-to-phone connections that used the Internet for voice transmission were set in place. These phone-to-phone connections still required a computer to initiate the call, but once the connection was established, the callers could use a regular phone set. VoIP Today There are currently many VoIP services available for residential and commercial use. Some of these still rely on PC-to-PC connections but may offer other services such as PC-to-phone and phone-to-phone. Internet phones are available that plug into the sound card or USB port of a computer. These phones may have number pads and ringers that allow you to use them the same as traditional telephones. The computer can be bypassed completely by connecting a phone directly to a broadband modem (either DSL or cable).

Voice-over-IP Overview Voice-over-IP (VoIP) implementations enables users to carry voice traffic (for example, telephone calls and faxes) over an IP network. There are 3 main causes for the evolution of the Voice over IP market:
y y y

Low cost phone calls Add-on services and unified messaging Merging of data/voice infrastructures

A VoIP system consists of a number of different components: Gateway/Media Gateway, Gatekeeper, Call agent, Media Gateway Controller, Signaling Gateway and a Call manager The Gateway converts media provided in one type of network to the format required for another type of network. For example, a Gateway could terminate bearer channels from a switched circuit network (i.e., DS0s) and media streams from a packet network (e.g., RTP streams in an IP network). This gateway may be capable of processing audio, video and T.120 alone or in any combination, and is capable of full duplex media translations. The Gateway may also play audio/video messages and performs other IVR functions, or may perform media conferencing. In VoIP, the digital signal processor (DSP) segments the voice signal into frames and stores them in voice packets. These voice packets are transported using IP in compliance with one of the specifications for transmitting multimedia (voice, video, fax and data) across a network: H.323 (ITU), MGCP (level 3,Bellcore, Cisco, Nortel), MEGACO/H.GCP (IETF), SIP (IETF), T.38 (ITU), SIGTRAN (IETF), Skinny (Cisco) etc. Coders are used for efficient bandwidth utilization. Different coding techniques for telephony and voice packet are standardized by the ITU-T in its G-series recommendations: G.723.1, G.729, G.729A etc. The coder-decoder compression schemes (CODECs) are enabled for both ends of the connection and the conversation proceeds using Real-Time Transport Protocol/User Datagram Protocol/Internet Protocol (RTP/UDP/IP) as the protocol stack. Quality of Service A number of advanced methods are used to overcome the hostile environment of the IP net and to provide an acceptable Quality of Service. Example of these methods are: delay, jitter, echo, congestion, packet loss, and miss ordered packets arrival. As VoIP is a delay-sensitive application, a well-engineered, end-to-end network is necessary to use VoIP successfully. The Mean Opinion Score is one of the most important parameters that determine the QoS. There are several methods and sophisticated algorithms developed to evaluate the QoS: PSQM (ITU P.861), PAMS (BT) and PESQ.Each CODEC provides a certain quality of service. The quality of transmitted speech is a subjective response of the listener (human or artificial means). A common benchmark used to determine the quality of sound produced by specific CODECs is

the mean opinion score (MOS). With MOS, a wide range of listeners judge the quality of a voice sample (corresponding to a particular CODEC) on a scale of 1 (bad) to 5 (excellent). Services The following are examples of services provided by a Voice over IP network according to market requirements: Phone to phone, PC to phone, phone to PC, fax to e-mail, e-mail to fax, fax to fax, voice to email, IP Phone, transparent CCS (TCCS), toll free number (1-800), class services, call center applications, VPN, Unified Messaging, Wireless Connectivity, IN Applications using SS7, IP PABX and soft switch implementations. Megaco (H.248) Internet draft: draft-ietf-megaco-merged-00.txt The Media Gateway Control Protocol, (Megaco) is a result of joint efforts of the IETF and the ITU-T Study Group 16. The protocol definition of this protocol is common text with ITU-T Recommendation H.248. The Megaco protocol is used between elements of a physically decomposed multimedia gateway. There are no functional differences from a system view between a decomposed gateway, with distributed sub-components potentially on more than one physical device, and a monolithic gateway such as described in H.246. This protocol creates a general framework suitable for gateways, multipoint control units and interactive voice response units (IVRs). Packet network interfaces may include IP, ATM or possibly others. The interfaces support a variety of SCN signalling systems, including tone signalling, ISDN, ISUP, QSIG and GSM. National variants of these signalling systems are supported where applicable. All messages are in the format of ASN.1 text messages.

MGCP Media Gateway Control Protocol (MGCP) is used for controlling telephony gateways from external call control elements called media gateway controllers or call agents. A telephony gateway is a network element that provides conversion between the audio signals carried on telephone circuits and data packets carried over the Internet or over other packet networks. MGCP assumes a call control architecture where the call control intelligence is outside the gateways and handled by external call control elements. The MGCP assumes that these call control elements, or Call Agents, will synchronize with each other to send coherent commands to the gateways under their control. MGCP is, in essence, a master/slave protocol, where the gateways are expected to execute commands sent by the Call Agents. The MGCP implements the media gateway control interface as a set of transactions. The transactions are composed of a command and a mandatory response. There are eight types of commands: MGCP Commands MGC --> MG CreateConnection: Creates a connection between two endpoints; uses SDP to define the receive capabilities of the paricipating endpoints. ModifyConnection: Modifies the properties of a connection; has nearly the same parameters as the CreateConnection command.

MGC --> MG

MGC <--> MG MGC --> MG

DeleteConnection: Terminates a connection and collects statistics on the execution of the connection. NotificationRequest: Requests the media gateway to send notifications on the occurrence of specified events in an endpoint. Notify: Informs the media gateway controller when observed events occur. AuditEndpoint: Determines the status of an endpoint. AuditConnection: Retrieves the parameters related to a connection. RestartInProgress: Signals that an endpoint or group of endpoints is take in or out of service.

MGC <-- MG MGC --> MG MGC --> MG MGC <-- MG

MGC=Media Gateway Controller MG=Media Gateway
y y y y y y y y

CreateConnection. ModifyConnection. DeleteConnection. NotificationRequest. Notify. AuditEndpoint. AuditConnection. RestartInProgress.

The first four commands are sent by the Call Agent to a gateway. The Notify command is sent by the gateway to the Call Agent. The gateway may also send a DeleteConnection. The Call Agent may send either of the Audit commands to the gateway. The Gateway may send a RestartInProgress command to the Call Agent. All commands are composed of a command header, optionally followed by a session description. All responses are composed of a response header, optionally followed by a session description. Headers and session descriptions are encoded as a set of text lines, separated by a carriage return and line feed character (or, optionally, a single line-feed character). The headers are separated from the session description by an empty line. MGCP uses a transaction identifier to correlate commands and responses. Transaction identifiers have values between 1 and 999999999. An MGCP entity cannot reuse a transaction identifier sooner than 3 minutes after completion of the previous command in which the identifier was used. The command header is composed of:

y y

A command line, identifying the requested action or verb, the transaction identifier, the endpoint towards which the action is requested, and the MGCP protocol version, A set of parameter lines, composed of a parameter name followed by a parameter value.

The command line is composed of:
y y

y y

Name of the requested verb. Transaction identifier correlates commands and responses. Values may be between 1 and 999999999. An MGCP entity cannot reuse a transaction identifier sooner than 3 minutes after completion of the previous command in which the identifier was used. Name of the endpoint that should execute the command (in notifications, the name of the endpoint that is issuing the notification). Protocol version.

These four items are encoded as strings of printable ASCII characters, separated by white spaces, i.e., the ASCII space (0x20) or tabulation (0x09) characters. It is recommended to use exactly one ASCII space separator.

Interested in more details about testing this protocol?

MIME http://www.rfc-editor.org/rfcsearch.html RFC 2045 - 2049

This set of standards, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefine the format of messages to allow for textual message bodies in character sets other than US-ASCII, an extensible set of different formats for non-textual message bodies, multi-part message bodies, and textual header information in character sets other than US-ASCII. The initial standard in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. RFC 2046 defines the general structure of the MIME media typing system and defines an initial set of media types. The third standard, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth standard, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final standard, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography. The first standard in this set, RFC 2045, defines a number of header fields, including ContentType. The Content-Type field is used to specify the nature of the data in the body of a MIME entity, by giving media type and subtype identifiers, and by providing auxiliary information that may be required for certain media types. After the type and subtype names, the remainder of the header field is simply a set of parameters, specified in an attribute/value notation. The ordering of parameters is not significant. In general, the top-level media type is used to declare the general type of data, while the subtype specifies a specific format for that type of data. Thus, a media type of "image/xyz" is enough to tell a user agent that the data is an image, even if the user agent has no knowledge of the specific image format "xyz". Such information can be used, for example, to decide whether or not to show a user the raw data from an unrecognized subtype -- such an action might be reasonable for unrecognized subtypes of "text", but not for unrecognized subtypes of "image" or "audio". For this reason, registered subtypes of "text", "image", "audio", and "video" should not contain embedded information that is really of a different type. Such compound formats should be represented using the "multipart" or "application" types. Parameters are modifiers of the media subtype, and as such do not fundamentally affect the nature of the content. The set of meaningful parameters depends on the media type and subtype. Most parameters are associated with a single specific subtype. However, a given top-level media type may define parameters which are applicable to any subtype of that type. Parameters may be required by their defining media type or subtype or they may be optional. MIME implementations must also ignore any parameters whose names they do not recognize. MIME's Content-Type header field and media type mechanism has been carefully designed to be extensible, and it is expected that the set of media type/subtype pairs and their associated parameters will grow significantly over time. Several other MIME facilities, such as transfer encodings and "message/external-body" access types, are likely to have new values defined over time. In order to ensure that the set of such values is developed in an orderly, well-specified, and public manner, MIME sets up a registration process which uses the Internet Assigned Numbers

Authority (IANA) as a central registry for MIME's various areas of extensibility. The registration process for these areas is described in RFC 2048.

Interested in more details about testing this protocol?

RVP over IP RVP Over IP Specification, MCK Communications (Proprietary) Remote Voice Protocol (RVP) is MCK Communications' protocol for transporting digital telephony sessions over packet or circuit based data networks. The protocol is used primarily in MCK's Extender product family, which extends PBX services over Wide Area Networks (WANs). RVP provides facilities for connection establishment and configuration between a client (or remote station set) device and a server (or phone switch) device. RVP/IP uses TCP to transport signalling and control data, and UDP to transport voice data. Signalling and Control Packets Control and signalling packets carried over TCP are encapsulated using the following format, a header followed by signalling or control messages:

1 byte Length

1 byte Protocol code RVP/IP messages

RVP over IP packet structure Length A one byte field containing the length of the header (protocol code and the entire RVP/IP message). The length field allows recognition of message boundaries in a continuous TCP data stream. Protocol code Identifies the RVP/IP protocol: 35 36 RVP/IP control messages (see RVP Control Protocol). RVP/IP signalling data (see RVP Signalling Operations).

RVP/IP messages RVP/IP messages include RVP Control Protocol (RVPCP) and RVP Signalling Operations described below. RVP Control Protocol (RVPCP) RVP Control Protocol is for control messages that configure and maintain the data link between the client and the server. The control protocol was originally developed for point-to-point data applications; most of its functionality is unnecessary when using TCP/IP. During an RVP/IP session, only one class of RVP/IP control message are exchanged: RVPCP ADD VOICE (operation code 12) packet, used to send the UDP port used by the client (for subsequent voice data packets) to the server. This message always takes a single parameter of type RVPCP UDP PORT (type code 9), which always has a length of exactly two and a value that is the two-byte UDP port to which voice data packets should be addressed. The server responds with a packet containing the code RVPCP ADD VOICE ACK (operation code 13) which contains exactly one parameter, the server's voice UDP port. If RVP/IP is operating in "dynamic voice" mode, this exchange must be repeated whenever the voice channel needs to be reestablished, i.e., whenever the phone goes off-hook. The structure of the control messages is described below: 2 bytes Operation code 2 bytes Parameter count Parameters

RVP over IP control message structure

Operation code The operation code defines the class of RVP/IP control messages Possible classes are: 12 13 RVPCP ADD VOICE RVPCP ADD VOICE ACK

Parameter count The parameter count equals exactly one parameter. Parameters Parameters of all control messages are passed as Type, Length and Value (TLV) structures as described below: 2 bytes Type 2 bytes Length Value...

RVP over IP control message structure

Type RVPCP UDP PORT (or type code 9). Length The number of bytes in the value field. Value The UDP port number. RVP Signalling Operations The structure of RVP signalling data (protocol type 36) is described below: 7 Packet Length 8 Protocol 8 Message Length 8 Data

RVP over IP signalling message structure

RVP signalling data packets always begin with a length byte immediately after the RVP/IP encapsulation header. The packets contain two classes of data, either raw digital telephone signalling packets or high-level RVP session commands. Session commands are differentiated from raw signalling data by adding an offset of 130 in the "Message Length" field. All raw

signalling data has a true length field of less than or equal to 128. The true length of a session command message is calculated by subtracting 130 from the length field. For all session commands, the Command Code (one-byte) follows the message length field. Bit seven of the command code is considered the "ACK" bit. All other bits in this field are part of the command code itself. Voice Data Packets The structure of voice data packets, carried over UDP datagrams, is described below: 7 Protocol RVP/IP Voice Data...

RVP over IP Voice packet structure

Protocol The protocol code is always 37 for RVP/IP voice data packets. RVP/IP voice data A single voice packet is carried in each UDP datagram. Interested in more details about testing this protocol?

SAPv2 Internet draft: http://search.ietf.org/internet-drafts/draft-ietf-mmusic-sap-v2-04.txt SAP is an announcement protocol that is used by session directory clients. A SAP announcer periodically multicasts an announcement packet to a well-known multicast address and port. The announcement is multicast with the same scope as the session it is announcing, ensuring that the recipients of the announcement can also be potential recipients of the session the announcement describes (bandwidth and other such constraints permitting). This is also important for the scalability of the protocol, as it keeps local session announcements local.

The following is the format of the SAP data packet. V=1 A R T E C Auth len Originating source Optional Authentication Data Optional timeout Optional payload type 0 Payload SAP data packet structure Msg id hash

V: Version Number The version number field is three bits and MUST be set to 1. A: Address Type The Address type field is one bit. It can have a value of 0 or 1: 0 The originating source field contains a 32-bit IPv4 address. 1 The originating source contains a 128-bit IPv6 address. R: Reserved SAP announcers set this to 0. SAP listeners ignore the contents of this field. T: Message Type The Message Type field is one bit. It can have a value of 0 or 1: 0 Session announcement packet 1 Session deletion packet. E: Encryption Bit The encryption bit may be 0 or 1. 1 The payload of the SAP packet is encrypted and the timeout field must be added to the packet header. 0 The packet is not encrypted and the timeout must not be present. C: Compressed Bit If the compressed bit is set to 1, the payload is compressed.

Authentication Length An 8 bit unsigned quantity giving the number of 32 bit words, following the main SAP header, that contain authentication data. If it is zero, no authentication header is present. Message Identifier Hash A 16-bit quantity that, used in combination with the originating source, provides a globally unique identifier indicating the precise version of this announcement. Originating Source This field contains the IP address of the original source of the message. This is an IPv4 address if the A field is set to zero; otherwise, it is an IPv6 address. The address is stored in network byte order. Timeout When the session payload is encrypted, the detailed timing fields in the payload are not available to listeners not trusted with the decryption key. Under such circumstances, the header includes an additional 32-bit timestamp field stating when the session should be timed out. The value is an unsigned quantity giving the NTP time in seconds at which time the session is timed out. It is in network byte order. Payload Type The payload type field is a MIME content type specifier, describing the format of the payload. This is a variable length ASCII text string, followed by a single zero byte (ASCII NUL). Payload The Payload field includes various sub fields: Version number (V) The version number of the authentication format is 1. Padding Bit (P) If necessary, the authentication data is padded to be a multiple of 32 bits and the padding bit is set. In this case the last byte of the authentication data contains the number of padding bytes (including the last byte) that must be discarded. Authentication Type (Auth) The authentication type is a 4 bit encoded field that denotes the authentication infrastructure the sender expects the recipients to use to check the authenticity and integrity of the information. This defines the format of the authentication sub-header and can take the values: 0=PGP format, 1=CMS format. All other values are undefined.

Interested in more details about testing this protocol?

SDP RFC 2327 ftp://ftp.isi.edu/in-notes/rfc2327.txt The Session Description Protocol (SDP) describes multimedia sessions for the purpose of session announcement, session invitation and other forms of multimedia session initiation. On Internet Multicast backbone (Mbone) a session directory tool is used to advertise multimedia conferences and communicate the conference addresses and conference tool-specific information necessary for participation. The SDP does this. It communicates the existence of a session and conveys sufficient information to enable participation in the session. Many of the SDP messages are sent by periodically multicasting an announcement packet to a well-known multicast address and port using SAP (session announcement protocol). These messages are UDP packets with a SAP header and a text payload. The text payload is the SDP session description. Messages can also be sent using email or the WWW (World Wide Web). The SDP text messages include:
y y y y

Session name and purpose Time the session is active Media comprising the session Information to receive the media (address etc.)

SDP messages are text messages using the ISO 10646 character set in UTF-8 encoding.

Interested in more details about testing this protocol?

SIP For information on how to simulate thousands of SIP calls RFC 2543 ftp://ftp.isi.edu/in-notes/rfc2543.txt Session Initiation Protocol (SIP) is a application layer control simple signalling protocol for VoIP implementations using the Redirect Mode. SIP is a textual client-server base protocol and provides the necessary protocol mechanisms so that the end user systems and proxy servers can provide different services: 1. Call forwarding in several scenarios: no answer, busy , unconditional, address manipulations (as 700, 800 , 900- type calls). 2. Callee and calling number identification 3. Personal mobility 4. Caller and callee authentication 5. Invitations to multicast conference 6. Basic Automatic Call Distribution (ACD)

SIP addresses (URL) can be embedded in Web pages and therefore can be integrated as part of powerful implementations (Click to talk, for example). SIP using simple protocol structure, provides the market with fast operation, flexibility, scalability and multiservice support. SIP provides its own reliability mechanism. SIP creates, modifies and terminates sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate using multicast or using a mesh of unicast relations, or a combination of these. SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. It supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. It is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities. SIP transparently supports name mapping and redirection services, allowing the implementation of ISDN and Intelligent Network telephony subscriber services. These facilities also enable personal mobility which is based on the use of a unique personal identity SIP supports five facets of establishing and terminating multimedia communications: User location User capabilities User availability Call setup Call handling. SIP can also initiate multi-party calls using a multipoint control unit (MCU) or fully-meshed interconnection instead of multicast. Internet telephony gateways that connect Public Switched Telephone Network (PSTN) parties can also use SIP to set up calls between them. SIP is designed as part of the overall IETF multimedia data and control architecture currently incorporating protocols such as RSVP, RTP RTSP, SAP and SDP. However, the functionality and operation of SIP does not depend on any of these protocols. SIP can also be used in conjunction with other call setup and signalling protocols. In that mode, an end system uses SIP exchanges to determine the appropriate end system address and protocol from a given address that is protocol-independent. For example, SIP could be used to determine that the party can be reached using H.323 to find the H.245 gateway and user address and then use H.225.0 to establish the call. SIP Operation Sip works as follows: Callers and callees are identified by SIP addresses. When making a SIP call, a caller first locates

the appropriate server and then sends a SIP request. The most common SIP operation is the invitation. Instead of directly reaching the intended callee, a SIP request may be redirected or may trigger a chain of new SIP requests by proxies. Users can register their location(s) with SIP servers. SIP messages can be transmitted either over TCP or UDP SIP messages are text based and use the ISO 10646 character set in UTF-8 encoding. Lines must be terminated with CRLF. Much of the message syntax and header field are similar to HTTP. Messages can be request messages or response messages. Protocol header structure. The protocol is composed of a start line, message header, an empty line and an optional message body. Request Messages The format of the Request packet header is shown in the following illustration: Method Request URI SIP version

SIP request packet structure

Method The method to be performed on the resource. Possible methods are Invite, Ack, Options, Bye, Cancel, Register Methods Command INVITE ACK BYE CANCEL OPTIONS REGISTER Function Initiate Call Confirm final response Terminate and transfer call Cancel searches and "ringing" Features support by other side Register with location service

Request-URI A SIP URL or a general Uniform Resource Identifier, this is the user or service to which this request is being addressed. SIP version The SIP version being used; this should be version 2.0 Response Message The format of the Response message header is shown in the following illustration: SIP version Status code Reason phrase

SIP response packet structure

Response Codes Response Code Prefix 1xx 2xx 3xx 4xx 5xx 6xx SIP version The SIP version being used. Status-code A 3-digit integer result code of the attempt to understand and satisfy the request. Reason-phrase A textual description of the status code. Typical SIP Calls Function Searching, ringing, queuing Success Fowarding Client mistakes Server failures Busy, refuse, not available anywhere

Enlarge

More Details

Interested in more details about testing this protocol?

SGCP IETF draft: http://www.ietf.org/internet-drafts/draft-huitema-sgcp-v1-02.txt Simple Gateway Control Protocol (SGCP) is used to control telephony gateways from external call control elements. A telephony gateway is a network element that provides conversion between the audio signals carried on telephone circuits and data packets carried over the Internet or over other packet networks. The SGCP assumes a call control architecture where the call control intelligence is outside the gateways and is handled by external call control elements. The SGCP assumes that these call control elements, or Call Agents, will synchronize with each other to send coherent commands to the gateways under their control. The SGCP implements the simple gateway control interface as a set of transactions. The transactions are composed of a command and a mandatory response. There are five types of commands:
y y

CreateConnection. ModifyConnection.

y y y

DeleteConnection. NotificationRequest. Notify.

The first four commands are sent by the Call Agent to a gateway. The Notify command is sent by the gateway to the Call Agent. The gateway may also send a DeleteConnection. All commands are composed of a Command header, optionally followed by a session description. All responses are composed of a Response header, optionally followed by a session description. Headers and session descriptions are encoded as a set of text lines, separated by a line feed character. The headers are separated from the session description by an empty line. The command header is composed of:
y y

Command line. A set of parameter lines, composed of a parameter name followed by a parameter value.

The command line is composed of:
y y

y y

Name of the requested verb. Transaction identifier, correlates commands and responses. Transaction identifiers may have values between 1 and 999999999 and transaction identifiers are not reused sooner than 3 minutes after completion of the previous command in which the identifier was used. Name of the endpoint that should execute the command (in notifications, the name of the endpoint that is issuing the notification). Protocol version.

These four items are encoded as strings of printable ASCII characters, separated by white spaces, i.e. the ASCII space (0x20) or tabulation (0x09) characters. It is recommended to use exactly one ASCII space separator.

Enlarge

More Details

Interested in more details about testing this protocol?

Skinny Cisco protocol Skinny Client Control Protocol (SCCP). Telephony systems are moving to a common wiring plant. The end station of a LAN or IP- based PBX must be simple to use, familiar and relatively cheap. The H.323 recommendations are quite an expensive system. An H.323 proxy can be used to communicate with the Skinny Client using the SCCP. In such a case the telephone is a skinny client over IP, in the context of H.323. A proxy is used for the H.225 and H.245 signalling. The skinny client (i.e. an Ethernet Phone) uses TCP/IP to transmit and receive calls and RTP/UDP/IP to/from a Skinny Client or H.323 terminal for audio. Skinny messages are carried above TCP and use port 2000. The messages consist of Station message ID messages. They can be of the following types: Code 0x0000 Station Message ID Message Keep Alive Message

0x0001 0x0002 0x0003 0x0004 0x0005 0x0006 0x0007 0x0008 0x0009 0x11 0x000A 0x000B 0x000C 0x000D 0x000E 0x000F 0x0010 0x0012 0x0020 0x0021 0x0024 0x22 0x23 0x25 0x26 0x27 0x28 0x0081 0x0082 0x0083 0x0085 0x0086 0x0087 0x0088 0x0089 0x008A 0x008B 0x008F 0x009D 0x009F 0x0090 0x0091 0x0092 0x0093 0x0094 0x0095

Station Register Message Station IP Port Message Station Key Pad Button Message Station Enbloc Call Message Station Stimulus Message Station Off Hook Message Station On Hook Message Station Hook Flash Message Station Forward Status Request Message Station Media Port List Message Station Speed Dial Status Request Message Station Line Status Request Message Station Configuration Status Request Message Station Time Date Request Message Station Button Template Request Message Station Version Request Message Station Capabilities Response Message Station Server Request Message Station Alarm Message Station Multicast Media Reception Ack Message Station Off Hook With Calling Party Number Message Station Open Receive Channel Ack Message Station Connection Statistics Response Message Station Soft Key Template Request Message Station Soft Key Set Request Message Station Soft Key Event Message Station Unregister Message Station Keep Alive Message Station Start Tone Message Station Stop Tone Message Station Set Ringer Message Station Set Lamp Message Station Set Hook Flash Detect Message Station Set Speaker Mode Message Station Set Microphone Mode Message Station Start Media Transmission Station Stop Media Transmission Station Call Information Message Station Register Reject Message Station Reset Message Station Forward Status Message Station Speed Dial Status Message Station Line Status Message Station Configuration Status Message Station Define Time & Date Message Station Start Session Transmission Message

0x0096 0x0097 0x0098 0x0099 0x009A 0x009B 0x009C 0x009E 0x0101 0x0102 0x0103 0x0104 0x105 0x0106 0x107 0x0108 0x109 0x0110 0x0111 0x0112 0x0113 0x0114 0x0115 0x0116 0x0117 0x118

Station Stop Session Transmission Message Station Button Template Message Station Version Message Station Display Text Message Station Clear Display Message Station Capabilities Request Message Station Enunciator Command Message Station Server Respond Message Station Start Multicast Media Reception Message Station Start Multicast Media Transmission Message Station Stop Multicast Media Reception Message Station Stop Multicast Media Transmission Message Station Open Receive Channel Message Station Close Receive Channel Message Station Connection Statistics Request Message Station Soft Key Template Respond Message Station Soft Key Set Respond Message Station Select Soft Keys Message Station Call State Message Station Display Prompt Message Station Clear Prompt Message Station Display Notify Message Station Clear Notify Message Station Activate Call Plane Message Station Deactivate Call Plane Message Station Unregister Ack Message

Advantages & Disadvantages of VOIP: Pros and Cons of Using VOIP VoIP is an established technology that happened because of its many advantages. However, it is not true to say that VoIP has only advantages and no disadvantages at all. If you want to learn more about the advantages and disadvantages of VoIP, keep reading. Advantages of VoIP VoIP is a great technology, which changed the world of telecommunications. Telecom operators might not be all happy about it, but it is a fact that VoIP has been relatively rapidly adopted and that it is here to stay. This is so because VoIP has many advantages. For instance, some of the advantages of VoIP are these:
y

y

y

VoIP is much cheaper. The unbeatable advantage of VoIP over PSTN is that for the end user VoIP is much cheaper and very often it is completely free. For instance, if you are using Skype or a similar service, you can make PC-to-PC calls to any location in the world for no charge at all. Even if you call mobile phones or fixed landlines, for international and long-distance calls VoIP is cheaper. There are VoIP providers, who offer free local calls to fixed landlines as well, so practically all VoIP calls can be cheaper. VoIP offers more features. All equal, VoIP includes more features than a traditional phone service. For instance, conference calls and video conferencing (if offered at all by traditional phone service) tend to be very expensive, while with some forms of VoIP they come for free, provided that you have the equipment for them. The case with call waiting and call forwarding is similar ± almost all VoIP providers offer them for free, while the majority of traditional phone service providers charge extra for them. VoIP is portable. Finally, when you use VoIP, your phone number is portable. If you relocate, you can keep your old number in the new location. With Skype and the other PC-based VoIP services it is even easier ± you just log into your account and this is it.

The advantages of VoIP are certainly substantial. As for disadvantages, it is not precise to say that there aren't any, but in comparison to the advantages of VoIP, its disadvantages are negligible. Disadvantages of VoIP

The disadvantages of VoIP aren't that numerous and what is best ± the issues can be resolved over time. In fact, in recent years much has been done to solve these issues and to constantly improve VoIP service. Here are some of the major disadvantages of VoIP:
y

y

y

Quality could be an issue. The main disadvantage of VoIP is the low quality of the calls. However, if we are to be honest, low quality of the calls happens only when the service is poor ± i.e. the bandwidth is insufficient and there are frequent drops. If the VoIP service is configured properly and has access to sufficient resources, calls can be of crystal quality ± i.e. much better than a call over a fixed digital line and light years from the quality of calls over an ancient analog line. Availability. Availability is another disadvantage of VoIP. When there is a power outage and/or your Internet connection is down, your VoIP service will not be available. This is in contrast to PSTN (unless your phone set uses electricity, of course), where even if there is a local power outage, you still can make and receive calls. However, if your VoIP service provider takes the necessary measures to minimize downtime and you have an UPS or another source of electricity, you might never experience VoIP unavailability. Emergency calls. The fact that VoIP is portable and you can call from anywhere is certainly a disadvantage as far as emergency calls are concerned. It is difficult to locate where a VoIP call is originating from. However, there are steps in this direction as well and hopefully soon emergency services will be adapted to receive VoIP calls and correctly identify the location they originate from.

As you see, the disadvantages of VoIP are not impossible to deal with. Having in mind the numerous advantages of VoIP, it is easy to understand why VoIP became so popular in recent years.