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:
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
missordered 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 e-mail, 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.
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.
MGC --> MG
ModifyConnection: Modifies the properties
of a connection; has nearly the same parameters as the CreateConnection
command.
MGC <--> MG
DeleteConnection: Terminates a connection
and collects statistics on the execution of the connection.
MGC --> MG
NotificationRequest: Requests the media gateway
to send notifications on the occurrence of specified events
in an endpoint.
MGC <-- MG
Notify: Informs the media gateway controller
when observed events occur.
MGC --> MG
AuditEndpoint: Determines the status of an
endpoint.
MGC --> MG
AuditConnection: Retrieves the parameters
related to a connection.
MGC <-- MG
RestartInProgress: Signals that an endpoint
or group of endpoints is take in or out of service.
MGC=Media
Gateway Controller
MG=Media Gateway
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:
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:
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.
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
Content-Type. 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
1 byte
Length
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
RVP/IP control messages
(see RVP Control Protocol).
36
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
2 bytes
Operation code
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
RVPCP ADD VOICE
13
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
2 bytes
Type
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
8
8
8
Packet Length
Protocol
Message Length
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?
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
Msg
id hash
Originating
source
Optional
Authentication Data
Optional
timeout
Optional
payload type
0
Payload
SAP data
packet structure
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.
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:
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.
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:
Call forwarding in several scenarios:
no answer, busy , unconditional, address manipulations (as
700, 800 , 900- type calls).
Callee and calling number identification
Personal mobility
Caller and callee authentication
Invitations to multicast conference
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
Function
INVITE
Initiate Call
ACK
Confirm final response
BYE
Terminate and transfer call
CANCEL
Cancel searches and "ringing"
OPTIONS
Features support by other side
REGISTER
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
Function
1xx
Searching, ringing, queuing
2xx
Success
3xx
Fowarding
4xx
Client mistakes
5xx
Server failures
6xx
Busy, refuse, not available anywhere
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.
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:
CreateConnection.
ModifyConnection.
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:
Command line.
A set of parameter lines, composed of
a parameter name followed by a parameter value.
The command line is composed of:
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.
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
Station
Message ID Message
0x0000
Keep Alive Message
0x0001
Station Register
Message
0x0002
Station IP Port
Message
0x0003
Station Key Pad
Button Message
0x0004
Station Enbloc
Call Message
0x0005
Station Stimulus
Message
0x0006
Station Off Hook
Message
0x0007
Station On Hook
Message
0x0008
Station Hook Flash
Message
0x0009
Station Forward
Status Request Message
0x11
Station Media Port
List Message
0x000A
Station Speed Dial
Status Request Message
0x000B
Station Line Status
Request Message
0x000C
Station Configuration
Status Request Message
0x000D
Station Time Date
Request Message
0x000E
Station Button
Template Request Message
0x000F
Station Version
Request Message
0x0010
Station Capabilities
Response Message
0x0012
Station Server
Request Message
0x0020
Station Alarm Message
0x0021
Station Multicast
Media Reception Ack Message
0x0024
Station Off Hook
With Calling Party Number Message
0x22
Station Open Receive
Channel Ack Message
0x23
Station Connection
Statistics Response Message
0x25
Station Soft Key
Template Request Message
0x26
Station Soft Key
Set Request Message
0x27
Station Soft Key
Event Message
0x28
Station Unregister
Message
0x0081
Station Keep Alive
Message
0x0082
Station Start Tone
Message
0x0083
Station Stop Tone
Message
0x0085
Station Set Ringer
Message
0x0086
Station Set Lamp
Message
0x0087
Station Set Hook
Flash Detect Message
0x0088
Station Set Speaker
Mode Message
0x0089
Station Set Microphone
Mode Message
0x008A
Station Start Media
Transmission
0x008B
Station Stop Media
Transmission
0x008F
Station Call Information
Message
0x009D
Station Register
Reject Message
0x009F
Station Reset Message
0x0090
Station Forward
Status Message
0x0091
Station Speed Dial
Status Message
0x0092
Station Line Status
Message
0x0093
Station Configuration
Status Message
0x0094
Station Define
Time & Date Message
0x0095
Station Start Session
Transmission Message
0x0096
Station Stop Session
Transmission Message
0x0097
Station Button
Template Message
0x0098
Station Version
Message
0x0099
Station Display
Text Message
0x009A
Station Clear Display
Message
0x009B
Station Capabilities
Request Message
0x009C
Station Enunciator
Command Message
0x009E
Station Server
Respond Message
0x0101
Station Start Multicast
Media Reception Message
0x0102
Station Start Multicast
Media Transmission Message
