Internet Engineering Task Force Mauricio Arango
INTERNET DRAFT Christian Huitema
Bellcore
<draft-huitema-sgcp-v1-00.txt> May 15, 1998
Simple Gateway Control Protocol (SGCP)
Mauricio Arango, Christian Huitema
Version 1.0
May 15, 1998
Status of this document
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
This document describes an application programming interface (SGCI) and
a corresponding protocol (SGCP) for controlling Voice over IP (VoIP)
Gateways from external call control elements. The SGCP assumes a call
control architecture where the call control 'intelligence' is outside
the gateways and handled by external call control elements.
The document is structured in 5 main sections:
* The introduction presents the basic assumptions and the relation to
other protocols such as H.323, RTSP, SAP or SIP.
* The interface section presents a conceptual overview of the SGCP,
Arango, Huitema [Page 1]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
presenting
the naming conventions, the usage of the session description proto-
col SDP, and the five procedurs that compose SGCP: Notifications
Request, Notification, Create Connection, Modify Connection and
Delete Connection.
* The protocol description section presents the SGCP encodings, which
are based on simple text formats, and the transmission procedure
over UDP.
* The security section presents the security requirement of SGCP, and
its usage of IP security services (IPSEC).
* An example section presents two detailed examples of call set up
procedures using SGCP.
1. Introduction
This document describes an application programming interface (SGCI) and
a corresponding protocol (SGCP) for controlling Voice over IP (VoIP)
Gateways from external call control elements. The SGCP assumes a call
control architecture where the call control "intelligence" is outside
the gateways and handled by external call control elements. The SGCP
assumes that these call controls, or call agents, will synchronize them-
selves to send coherent commands to the gateways. The SGC does not pro-
vide any mechanism for synchronizing these agents.
The SGCP assumes a connection model where the basic constructs are end-
points and connections. Endpoints are sources or sinks of data and could
be physical or virtual. A physical endpoint is, for example, a trunk
circuit. An example of a virtual endpoint is an audio source in an
audio-content server. Creation of physical endpoints requires hardware
installation, while creation of virtual endpoints can be done by
software.
Connections may be either point to point or multipoint. A point to point
connection is an association between two endpoints with the purpose of
transmitting data between these endpoints. Once this association is
established for both endpoints, data transfer between these endpoints
can take place. A multipoint connection is established by connecting the
end point to a multipoint session.
1.1. Relation with the H.323 standards
The SGCP is designed as an internal protocol within a distributed system
Arango, Huitema [Page 2]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
that appears to the outside as a single VoIP gateway. This system is
composed of a call agent, that may or may not be distributed over
several computer platforms, and of a set of gateways. In a typical con-
figuration, this distributed gateway system will interface on one side
with one or several telephony switches, and on the other side with H.323
conformant systems, as indicated in the following table:
____________________________________________________________________
| Functional| Phone | Terminating | H.323 conformant |
| Plane | switch | Entity | systems |
|____________|____________|_________________|_______________________|
| Signaling | Signaling | Call agent | Signaling exchanges |
| Plane | exchanges | | with the call agent |
| | through | | through H.225/RAS and|
| | SS7/ISUP | | H.225/Q.931. |
|____________|____________|_________________|_______________________|
| | | | Possible negotiation |
| | | | of logical channels |
| | | | and transmission |
| | | | parameters through |
| | | | H.245 with the call |
| | | | agent. |
|____________|____________|_________________|_______________________|
| | | Internal | |
| | | synchronization| |
| | | through SGCP | |
|____________|____________|_________________|_______________________|
| Bearer | Connection| Telephony | Optional negotiation |
| Data | through | gateways | of logical channels |
| Transport | high speed| | and transmission |
| Plane | trunk | | parameters through |
| | groups | | H.245 directly with |
| | | | the telephony |
| | | | gateway. |
| | | | |
| | | | Transmission of VoIP |
| | | | data using RTP, |
| | | | directly between the |
| | | | H.323 station and the|
| | | | gateway. |
|____________|____________|_________________|_______________________|
In the SGCP model, the gateways focus on the audio signal translation
function, while the call agent handles the signaling functions. As a
consequence, the call agent implements the "signaling" layers of the
H.323 standard, and presents itself as a "Gatekeeper" to the H.323 sys-
tems. Calls are established using the "Gatekeeper Routed" call model.
Arango, Huitema [Page 3]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
1.2. Relation with the IETF standards
While H.323 is the recognized standard for VoIP terminals, the IETF has
also produced standards for other types of multi-media applications.
These other standards include:
* the Session Description Protocol (SDP), RFC 2327,
* the Session Announcement Protocol (SAP),
* the Session Initiation Protocol (SIP),
* the Real Time Streaming Protocol (RTSP), RFC 2326.
The latter three standards are in fact alternative signaling standards
that allow for the transmission of a session description to an
interested party. SAP is used by multicast session managers to distri-
bute a multicast session description to a large group of recipients, SIP
is used to invite an individual user to take part in a point-to-point or
unicast session, RTSP is used to interface a server that will provide
real time data. In all three cases, the session description is described
according to SDP; when audio is transmitted, it is transmitted through
the Real-time Transport Protocol, RTP.
The distributed gateway systems and SGCP will enable telephony users to
access these sessions. The call agent will provide for signaling conver-
sion, according to the following table:
Arango, Huitema [Page 4]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
______________________________________________________________________
| Functional| Phone | Terminating | IETF conforming systems|
| Plane | switch | Entity | |
|____________|____________|_________________|_________________________|
| Signaling | Signaling | Call agent | Signaling exchanges |
| Plane | exchanges | | with the call agent |
| | through | | through SAP, SIP or |
| | SS7/ISUP | | RTSP. |
|____________|____________|_________________|_________________________|
| | | | Negotiation of session |
| | | | description parameters |
| | | | through SDP (telephony |
| | | | gateway terminated but |
| | | | passed via the call |
| | | | agent to and from the |
| | | | IETF conforming system)|
|____________|____________|_________________|_________________________|
| | | Internal | |
| | | synchronization| |
| | | through SGCP | |
|____________|____________|_________________|_________________________|
| Bearer | Connection| Telephony | Transmission of VoIP |
| Data | through | gateways | data using RTP, |
| Transport | high speed| | directly between the |
| Plane | trunk | | remote system and the |
| | groups | | gateway. |
|____________|____________|_________________|_________________________|
The SDP standard has a pivotal status in this architecture. We will see
in the following description that we also use it to carry session
descriptions in SGCP.
2. Simple Gateway Control Interface
The interface functions are grouped in two logical sets, connection con-
trol and end point control. Both use the same system model and the same
naming conventions.
2.1. Model and naming conventions
The SGCP assumes a connection model where the basic constructs are end-
points and connections. Connections are grouped in calls. Connections
and calls are set up at the initiative of one or several call agents.
Arango, Huitema [Page 5]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
2.1.1. Names of endpoints
Endpoints names have two components:
* the domain name of the gateway that is managing the end point,
* a local name within that gateway.
The vast majority of endpoints, in our systems, are trunk circuits link-
ing a gateway to a telephone switch. These circuits are typically
grouped in digital multiplex, which is connected to the gateway by a
physical interface. Such circuits will have to be named in three con-
texts:
* In the ISUP protocol, circuits are grouped in trunk groups, identi-
fied by the SS7 point codes of the switches that the group con-
nects. Circuit within a group are identified by a circuit number.
* In the gateway configuration files, physical interfaces are typi-
cally identified by the name of the interface, an arbitrary text
string. When the interface multiplexes several circuits, indivi-
dual circuits are typically identified by a circuit number.
* In SGCP, the endpoints are identified by an end point name.
The call agents will use configuration data bases to map ranges of cir-
cuits within a trunk group to another range of circuits in a multiplex
connected to a gateway through a physical interface. The gateway will be
identified, in SGCP, by a domain name. The local name will be structured
to encode both the name of the physical interface, for example X35V3+A4,
and the circuit number within the multiplex connected to the interface,
for example 13. The circuit number will be separated from the name of
the interface by a fraction bar, as in:
X35V3+A4/13
The circuit number can be omitted when the physical interface only
includes one circuit, or if the call agent requests the gateway to
choose one available circuit within a multiplex.
Other types of endpoints will use different conventions. For example, an
end point that produces an "all lines busy" announcement could be named:
all-lines-busy/loop@announce-23.whatever.net
The exact syntax of such names should be specified in the corresponding
server specification.
Arango, Huitema [Page 6]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
2.1.2. Names of calls
Calls are identified by unique identifiers, independent of the underly-
ing platforms or agents. These identifiers are created by the call
agent. They are treated in SGCP as unstructured octet strings.
Call identifiers are expected to be unique within the system. When a
call agent builds several connections that pertain to the same call,
either on the same gateway or in different gateways, these connections
will all be linked to the same call through the globally unique identif-
ier. This identifier can then be used by accounting or management pro-
cedures, which are outside the scope of SGCP.
2.1.3. Names of connections
Connection identifiers are created by the gateway when it is requested
to create a connection. They identify the connection within the context
of an endpoint and a call. They are treated in SGCP as unstructured
octet strings. The gateway should make sure that a proper waiting
period, at least 3 minutes, elapses between the end of a connection that
used this identifier and its use in a new connection.
2.1.4. Names of call agents and other entities
The simple gateway control protocol has been designed to allow the
implementation of redundant call agents, for enhanced network reliabil-
ity. This means that there is no fixed binding between entities and
hardware platforms or network interfaces.
Reliability can be improved by the following precautions:
* Entities such as endpoints or call agents are identified by their
domain name, not their network addresses. Several addresses can be
associated with a domain name. If a request or a response cannot be
forwarded to one of the network addresses, implementations should
retry the transmission using another address.
* Entities may move to another platform. The association between a
logical name (domain name) and the actual platform are kept in the
domain name service. Call agents and Gateways should keep track of
the time-to-live of the record they read from the DNS. They should
query the DNS to refresh the information if the time to live has
expired.
Arango, Huitema [Page 7]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
2.1.5. Numbering plans
Through the interface, the call agent can ask the gateway to collect
digits dialed by the user. This facility is intended to be used with
access gateways to collect the numbers that a user dials; it may also be
used with trunking gateways and access gateways alike, to collect the
access codes, credit card numbers and other numbers requested by call
control services.
An alternative procedure would ask the gateway to notify the call agent
of the dialed digits, as soon as they are dialed. However, such a pro-
cedure generates a large number of interactions. It is preferable to
accumulate the dialed numbers in a buffer, and to transmit them in a
single message.
The problem with this accumulation approach, however, is that it is hard
for the gateway to predict how many numbers it needs to accumulate
before transmission. For example, using the phone on our desk, we can
dial the following numbers:
_______________________________________________________
| 0 | Local operator |
| 00 | Long distance operator |
| xxxx | Local extension number |
| 8xxxxxxx | Local number |
| #xxxxxxx | Shortcut to local number at|
| | other corporate sites |
| *xx | Star services |
| 91xxxxxxxxxx | Long distance number |
| 9011 + up to 14 digits| International number |
|________________________|_____________________________|
The solution to this problem is to load the gateway with a digit map
that correspond to the dial plan. This digit map is expressed using a
syntax derived from the Unix system command, egrep. For example, the
dial plan described above would be simply result in the following digit
map:
(0T | 00T | [1-7]xxx | 8xxxxxxx | #xxxxxxx | *xx | 91xxxxxxxxxx |
9011x.T)
The formal syntax of the digit map is described by the following BNF
notation:
Arango, Huitema [Page 8]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
Digit ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
Timer ::= "T" -- matches the detection of a timer
Letter ::= Digit | Timer | "#" | "*" | "A" | "B" | "C" | "D"
Range ::= "x" -- matches any digit
| "[" Letters "]" -- matches any of the specified letters
Letters ::= Subrange | Subrange Letters
Subrange ::= Letter -- matches the specified letter
| Digit "-" Digit -- matches any digit between first and last
Position ::= Letter
| Range
StringElement ::= Position -- matches an occurrence of the position
| Position "." -- matches an arbitrary number of occurrence
-- of the position, including 0
String ::= StringElement | StringElement String
StringList ::= String | String "|" StringList
DigitMap ::= String | "(" StringList ")"
A DigitMap, according to this syntax, is defined either by a "string" or
by a list of strings. Each string in the list is an alternative number-
ing scheme. A gateway that detects digits, letters or timers will:
1. Add the event parameter code as a token to the end of an internal
state variable called the "current dial string"
2. Apply the current dial string to the digit map table, attempting
a match to each regular expression in the Digit Map in
lexical
order
3. If the result is under-qualified (partially matches at least one
entry in the digit map), do nothing further.
4. If the result matches, or is over-qualified (i.e. no further
digits could possibly produce a match), send the current
digit
string to the call agent.
Arango, Huitema [Page 9]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
Digit maps are provided to the gateway by the call agent, whenever the
call agent instructs the gateway to listen for digits.
2.2. Usage of SDP
The call agent uses the SGCP to provision the gateways with the descrip-
tion of connection parameters such as IP addresses, UDP port and RTP
profiles. These descriptions will follow the conventions delineated in
the Session Description Protocol which is now an IETF proposed standard,
documented in RFC 2327.
SDP allows for description of multimedia conferences. In the first
implementations of SGCP, we limit the SDP usage to the setting of audio
circuits. The initial session descriptions contain the description of
exactly one media, of type audio.
2.3. Gateway Control Functions
This section describes the primitives of the SGCP. The service consists
of connection handling and end-point handling primitives. There are five
primitives in the protocol:
* The call agent can issue a NotificationRequest to a gateway,
instructing the gateway to watch for specific events such as hook
actions or DTMF tones on a specified end point.
* The gateway will then use the Notify command to inform the call
agent when the requested events occur.
* The call agent can use the CreateConnection command to create a
connection that terminates in an "endpoint" inside the gateway.
* The call agent can use the ModifyConnection command to change the
parameters associated to a previously established connection.
* The call agent can use the DeleteConnection command to delete an
existing connection. The DeleteConnection command may also be used
by a gateway to indicate that a connection can no longer be sus-
tained.
These services allow a controller (normally, the Call Agent) to instruct
a gateway on the creation of connections that terminate in an "endpoint"
inside the gateway, and to be informed about events occurring in the
gateway. An end point may be for example:
* A specific trunk circuit, within a trunk group terminating in a
Arango, Huitema [Page 10]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
gateway,
* A specific announcement handled by an announcement server.
Connections are grouped into "calls". Several connections may belong to
the same call, terminating in the same end-point. Each connection is
qualified by a "mode" parameter, which can be set to "send", "receive",
"send/receive", "inactive", "loopback" or "continuity test."
The handling of the audio signals received on these connections is
determined by the parameters:
* Audio signals incoming from connections in "receive" or
"send/receive" mode are mixed and sent to endpoint.
* Audio signals originating from the endpoint are transmitted over
all the connections whose mode is "send" or "send/receive."
If the mode is set to "loopback", the gateway is expected to return the
incoming signal from the endpoint back into that same endpoint. This
procedure will be used, typically, during maintenance operations.
If the mode is set to "continuity test", the gateway is informed that
the other end of the circuit has initiated a continuity test procedure.
It is expected to follow the procedure specified for that end point,
which may require either that the circuit be placed in loopback mode, or
to wait for a specific tone and return an appropriate signal.
2.3.1. Notifications Request
Notification functions are used to request the gateway to send notifica-
tions upon the occurrence of specified events in an endpoint. For exam-
ple, a notification may be requested when a gateway detects that an end-
point is receiving, from its corresponding circuit, tones associated
with fax communication. The entity receiving this notification may
decide to use a different type of encoding method in the connections
bound to this endpoint.
NotificationRequest( EndpointId,
NotifiedEntity,
RequestedEvents,
RequestIdentifier,
DigitMap,
SignalRequests)
EndpointId is the identifier for the endpoint in the gateway where Noti-
ficationRequest executes.
Arango, Huitema [Page 11]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
NotifiedEntity is an optional parameter that specifies where the notifi-
cations should be sent. When this parameter is absent, the notifications
should be sent to the originator of the notification request.
RequestIdentifier is used to correlate this request with the notifica-
tions that it triggers.
RequestedEvents is a list of events that the gateway is requested to
detect and report. Such events include:
* fax tones,
* modem tones,
* continuity tone,
* continuity detection (as a result of a continuity test),
* on-hook transition,
* off-hook transition,
* flash hook,
* DTMF digits (or pulse digits).
To each event is associated an action, which can be:
* Notify the event immediately, together with the accumulated list of
observed events,
* Swap audio,
* Accumulate according to Digit Map,
* Ignore the event.
Events that are not specified in the list will, by default, be ignored.
The Swap Audio action can be used when a gateway handles more than one
active connection on an endpoint. This will be the case for three-way
calling, call waiting, and possibly other feature scenarios. In order to
avoid the round-trip to the call agent when just changing which connec-
tion is attached to the audio functions of the endpoint, the notifica-
tion request can map an event (usually hook flash, but could be some
other event) to a local function swap audio, which selects the "next"
connection in a round robin fashion. If there is only one connection,
this action is effectively a no-op.
Arango, Huitema [Page 12]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
Hook transition events are normally observed only by access gateways.
Tone detection can be done by any gateway, including trunking gateways
and PBX gateways. The call agent can send a Notification Request whose
requested event list is empty. It will do so, for example, to an access
gateway when it does not want to collect any more DTMF digits.
DigitMap is an optional parameter that allows the call agent to provi-
sion the gateways with a digit map according to which digits will be
accumulated. This parameter must be present if the requested events con-
tain an request to "accumulate according to the digit map." The collec-
tion of these digits will result in a digit string. The digit string is
initialized to a null string upon reception of the notification request,
so that a subsequent notification only returns the digits that were col-
lected after this request.
SignalRequests is a parameter that contains the set of actions that the
gateway is asked to perform on the end point, such as:
* Ringing,
* Distinctive ringing, which can occur in 8 variants numbered 0 to 7,
* Ring back tone,
* Dial tones,
* Intercept tone,
* Network Congestion tone,
* Busy tone,
* Confirm tone,
* Answer tone,
* Call waiting tone,
* Off hook warning tone,
* Preemption tone,
* Continuity tones,
* Continuity test,
* ASDI display (and string to be displayed).
Arango, Huitema [Page 13]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
The action triggered by the SignalRequests is synchronized with the col-
lection of events specified in the RequestedEvents parameter. For exam-
ple, if the notification request mandates "ringing" and the event
request ask to look for an "off-hook" event, the ringing should stop as
soon as the phone goes off hook.
The specific definition of actions which are requested via these signal
requests, such as the duration of and frequency of a DTMF digit, is out-
side the scope of SGC. This definition may vary from location to loca-
tion and hence from gateway to gateway.
The call agent can send a Notification Request whose requested signal
list is empty. It will do so for example when tone generation should
stop.
2.3.2. Notifications
Notifications messages are sent by the gateway when the observed events
occur.
Notify( EndpointId,
NotifiedEntity,
RequestIdentifier,
ObservedEvents)
EndpointId is the identifier for the endpoint in the gateway which is
issuing the Notify command.
NotifiedEntity is an optional parameter that identifies the entity to
which the notifications is sent. This parameter is equal to the Noti-
fiedEntity parameter of the notification request that triggered this
notification. The parameter is absent if there was no such parameter in
the triggering request. In this case, the notification is sent to the
entity from which the request was received.
RequestIdentifier is parameter that repeats the RequestIdentifier param-
eter of the notification request that triggered this notification. It is
used to correlate this notifications with the request that triggered it.
ObservedEvents is a list of events that the gateway detected. A single
notification may report a list of events that will be reported in the
order in which they were detected. The list may only contain the iden-
tification of events that were requested in the RequestedEvents parame-
ter of the triggering request. It will contain the events that were
either accumulated (but not notified) or treated according to digit map
(but no match yet), and the final event that triggered the detectection
or provided a final match in the digit map.
Arango, Huitema [Page 14]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
2.3.3. CreateConnection
This function is used to create a connection.
ConnectionId,
LocalConnectionDescriptor <--- CreateConnection(
CallId,
EndpointId,
NotifiedEntity,
LocalConnectionOptions,
Mode,
RemoteConnectionDescriptor,
RequestedEvents,
RequestIdentifier,
DigitMap,
SignalRequests)
This function creates a connection between two endpoints. A connection
is defined by its endpoints. The input parameters in CreateConnection
provide the data necessary to build a gateway's "view" of a connection.
CallId is a global unique parameter that identifies the call (or ses-
sion) to which this connection belongs. This parameter is unique within
the whole network of gateways; connections that belong to the same call
share the same call-id. The call-id can be used to identify calls for
reporting and accounting purposes.
EndpointId is the identifier for the connection endpoint in the gateway
where CreateConnection executes. The endpoint identifier can be fully-
specified by assigning a value to parameter EndpointId in the function
call or it may be under-specified and the full value will be assigned by
the gateway and its complete value returned as a field in the LocalCon-
nectionDescriptor structure returned by CreateConnection.
The Notified Entity is an optional parameter that specifies where the
notifications should be sent. An example of notification may be a
disconnection request at the initiative of the gateway.
LocalConnectionOptions is a structure that describes the characteristics
of the data communications from the point of view of the gateway execut-
ing CreateConnection. The fields contained by LocalConnectionOptions are
the following:
* Encoding Method
* Packetization period
* Bandwidth
Arango, Huitema [Page 15]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
* Type of Service,
* Usage of echo cancellation
The values of these fields are defined in the SDP standard. For each of
the first three fields, the call agent has three options:
* It may state exactly one value, which the gateway will then use
for the connection,
* It may provide a loose specification, such as a list of allowed
encoding methods or a range of packetization periods,
* It may simply provide a bandwidth indication, leaving the choice
of encoding method and packetization period to the gate-
way.
The bandwidth specification shall not contradict the specification of
encoding methods and packetization period. If an encoding method is
specified, then the gateway is authorized to use it, even if this
results in the usage of a larger bandwidth than specified.
The Type of Service specifies the class of service that will be used for
the connection. When the connection is transmitted over an IP network,
the parameters encodes the 8-bit type of service value parameter of the
IP header. When the Type of Service is not specified, the gateway shall
used a default configured value.
By default, the telephony gateways always perform echo cancellation.
However, it is necessary, for some calls, to turn off these operations.
The echo cancellation parameter can have two values, "on" (when the echo
cancellation is requested) and "off" (when it is turned off.)
RemoteConnectionDescriptor is the connection descriptor for the remote
side of a connection. It includes the same fields as in the LocalConnec-
tionDescriptor, i.e. the fields that describe a session according to the
SDP standard. This parameter may have a null value when the information
for the remote end is not known yet. This occurs because the entity that
builds a connection starts by sending a CreateConnection to one of the
two gateways involved in it. For the first CreateConnection issued,
there is no information available about the other side of the connec-
tion. This information may be provided later via a ModifyConnection
call.
Mode indicates the mode of operation for this side of the connection.
The options are: FullDuplex, ReceiveOnly, SendOnly, Inactive and Loop-
back
Arango, Huitema [Page 16]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
* FullDuplex indicates that this side of the connection sends data
generated by the associated endpoint and can receive data
from
the remote end and feed it to the endpoint.
* ReceiveOnly indicates this connection end can only receive data
form the remote end and feed it to the associated end-
point.
* SendOnly indicates that this connection end can only send data
from its endpoint to the other end of the connection.
* Inactive indicates that this connection end does not send or
receive any data. The connection exists but is not
active. It has
to be explicitly activated by a ModifyConnection command.
* Loopback indicates that the circuit to which the end point refers
should be placed in loopback mode, so that signals
received from
the phone circuit are sent back on this same circuit.
The gateway returns a ConnectionId, which uniquely identifies the con-
nection within one end point, and a LocalConnectionDescriptor, which is
a session description that contains information about addresses and RTP
ports, as defined in SDP.
After receiving a "create connection" request that did not include a
remote session descriptor, a gateway is in an ambiguous situation.
Because it has exported a session description parameter, it can poten-
tially receive packets. Because it has not yet received the session
description parameter of the other gateway, it does not know whether the
packets that it receives have been authorized by the call agent. It must
thus navigate between two risks, i.e. clipping some important announce-
ments or listening to insane data. The behavior of the gateway is deter-
mined by the value of the Mode parameter:
* If the mode was set to ReceiveOnly, the gateway should accept the
voice signals and transmit them through the end point.
* If the mode was set to Inactive or Loopback, the gateway should
refuse the voice signals.
Note that the mode values FullDuplex and SendOnly don't make sense in
this situation. They should be treated as ReceiveOnly and Inactive.
The RequestedEvents, RequestIdentifier, DigitMap, and SignalRequests
parameters are optional. They can be used by the call agent to transmit
Arango, Huitema [Page 17]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
a notification request that is executed simultaneously with the creation
of the connection. For example, when the call agent wants to initiate a
call to an access gateway, it should:
* ask the gateway to prepare a connection, in order to be sure that
the user can start speaking as soon as the phone goes off hook,
* ask the gateway to start ringing,
* ask the gateway to notify the call agent when the phone goes off-
hook.
This can be accomplished in a single create connection request, by also
transmitting the requested event parameters, for the off hook event, and
the signal request parameter, for the ringing signal.
When these parameters are present, the creation and the notification
requests should be synchronized, which means that both should be
accepted, or both refused. In our example, the create connection may be
refused if the gateway does not have sufficient resources, or cannot get
adequate resources from the local network access, and the off-hook
notification request can be refused in the glare condition, if the user
is already off-hook. In this example, the phone should not ring if the
circuit cannot be established, and the circuit should not be established
if the user is already off hook.
2.3.4. ModifyConnection
This function is used to modify the characteristics of a gateway's
"view" of a connection. This "view" of the call includes both the local
connection descriptors as well as the remote connection descriptor.
[LocalConnectionDescriptor] <--- ModifyConnection(CallId,
EndpointId,
ConnectionId,
NotifiedEntity,
LocalConnectionOptions,
Mode,
RemoteConnectionDescriptor,
RequestedEvents,
RequestIdentifier,
DigitMap,
SignalRequests)
The parameters used are the same as in the CreateConnection function,
with the addition of a ConnectionId that identifies the connection
within the call. This parameter is returned by the CreateConnection
Arango, Huitema [Page 18]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
function, as part of the local connection descriptor. It uniquely iden-
tifies the connection within the call.
The ModifyConnection command can be used to affect parameters of a con-
nection in the following ways:
* Provide information on the other end of the connection, through the
RemoteConnectionDescriptor. This can only occur once in the life-
time of the connection.
* Activate or deactivate the connection, by changing the value of the
Mode parameter. This can occur at any time during the connection,
with arbitrary parameter values.
* Change the sending parameters of the connection, for example by
switching to a different coding scheme, changing the packetization
period, or modifying the handling of echo cancellation.
Connections can only be activated if the remote connection descriptor
has been provided to the gateway.
The command will only return a LocalConnectionDescriptor if the local
connection parameters, such as RTP ports, were modified. (Usage of this
feature is actually for further study.)
The RequestedEvents, RequestIdentifier, DigitMap, and SignalRequests
parameters are optional. They can be used by the call agent to transmit
a notification request that is executed simultaneously with the modifi-
cation of the connection. For example, when a connection is accepted,
the calling gateway should be instructed to place the circuit in send-
receive mode and to stop providing ringing tones.
This can be accomplished in a single modify connection request, by also
transmitting the requested event parameters, for the on hook event, and
an empty signal request parameter, to stop the provision of ringing
tones.
When these parameters are present, the modification and the notification
requests should be synchronized, which means that both should be
accepted, or both refused.
2.3.5. DeleteConnection (from the call agent)
This function is used to terminate a connection. As a side effect, it
collects statistics on the execution of the connection.
Arango, Huitema [Page 19]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
Connection-parameters <-- DeleteConnection(CallId,
EndpointId,
ConnectionId,
NotifiedEntity,
RequestedEvents,
RequestIdentifier,
DigitMap,
SignalRequests)
In the general case where a connection has two ends, this command has to
be sent to both gateways involved in the connection. Some connections,
however, may use IP multicast. In this case, they can be deleted indivi-
dually.
After the connection has been deleted, the end point should be placed in
inactive mode. Any loopback that has been requested for the connection
should be cancelled.
In response to the Delete request, the gateway returns a list of parame-
ters that describe the status of the connection. These parameters are:
Number of packets sent:
The total number of RTP data packets transmitted by the sender
since starting transmission on this connection. The count is
not reset if the sender changes its SSRC identifier, for exam-
ple as a result of a Modify command. The value is zero if the
connection was set in "receive only" mode.
Number of octets sent:
The total number of payload octets (i.e., not including header
or padding) transmitted in RTP data packets by the sender
since starting transmission on this connection. The count is
not reset if the sender changes its SSRC identifier, for exam-
ple as a result of a Modify command. The value is zero if the
connection was set in "receive only" mode.
Number of packets received:
The total number of RTP data packets received by the sender
since starting reception on this connection. The count
includes packets received from different SSRC, if the sender
used several values. The value is zero if the connection was
set in "send only" mode.
Number of octets received:
Arango, Huitema [Page 20]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
The total number of payload octets (i.e., not including header
or padding) transmitted in RTP data packets by the sender
since starting transmission on this connection. The count
includes packets received from different SSRC, if the sender
used several values. The value is zero if the connection was
set in "send only" mode.
Number of packets lost:
The total number of RTP data packets that have been lost since
the beginning of reception. This number is defined to be the
number of packets expected less the number of packets actually
received, where the number of packets received includes any
which are late or duplicates. The count includes packets
received from different SSRC, if the sender used several
values. Thus packets that arrive late are not counted as lost,
and the loss may be negative if there are duplicates. The
count includes packets received from different SSRC, if the
sender used several values. The number of packets expected is
defined to be the extended last sequence number received, as
defined next, less the initial sequence number received. The
count includes packets received from different SSRC, if the
sender used several values. The value is zero if the connec-
tion was set in "send only" mode.
Interarrival jitter:
An estimate of the statistical variance of the RTP data packet
interarrival time, measured in milliseconds and expressed as
an unsigned integer. The interarrival jitter J is defined to
be the mean deviation (smoothed absolute value) of the differ-
ence D in packet spacing at the receiver compared to the
sender for a pair of packets. Detailed computation algorithms
are found in RFC 1889. The count includes packets received
from different SSRC, if the sender used several values. The
value is zero if the connection was set in "send only" mode.
Average transmission delay:
An estimate of the network latency, expressed in milliseconds.
This is the average value of the difference between the NTP
timestamp indicated by the senders of the RTCP messages and
the NTP timestamp of the receivers, measured when this mes-
sages are received. The average is obtained by summing all the
estimates, then dividing by the number of RTCP messages that
have been received.
For a detailed definition of these variables, refer to RFC 1889.
Arango, Huitema [Page 21]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
The NotifiedEntity, RequestedEvents, RequestIdentifier, DigitMap, and
SignalRequests parameters are optional. They can be used by the call
agent to transmit a notification request that is executed simultaneously
with the deletion of the connection. For example, when a user hangs up
is accepted, the gateway should be instructed to delete the connection
and to start looking for an off hook event.
This can be accomplished in a single delete connection request, by also
transmitting the requested event parameters, for the off hook event, and
an empty signal request parameter.
When these parameters are present, the deletion and the notification
requests should be synchronized, which means that both should be
accepted, or both refused.
2.3.6 DeleteConnection (from the VoIP gateway)
In some circumstances, a gateway may have to clear a connection, for
example because it has lost the resource associated with the connection,
or because it has detected that the end point no longer is capable or
willing to send or receive voice. The gateway terminates the connection
by using a variant of the Delete Connection request:
DeleteConnection( CallId,
EndpointId,
ConnectionId,
Reason-code,
Connection-parameters)
In addition to the call, endpoint and connection identifiers, the gate-
way will also send the call's parameters that would have been returned
to the call agent in response to a Delete Connection request. The reason
code indicates the cause of the disconnection.
2.3.6. DeleteConnection (multiple connections, from the call agent)
A variation of the Delete Connection function can be used by the call
agent to delete multiple connections at the same time. The command can
be used to delete all connections that relate to a Call for an end
point:
DeleteConnection( CallId,
EndpointId)
It can also be used to delete all connections that terminate in a given
end point:
Arango, Huitema [Page 22]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
DeleteConnection( EndpointId)
After the connections have been deleted, the end point should be placed
in inactive mode. Any loopback that has been requested for the connec-
tions should be cancelled.
This command does not return any individual statistics or call parame-
ters.
2.4. Race conditions
In order to implement proper call signalling, the Call Agent must keep
track of the state of the gateway. A key element of this state is the
position of the hook. A race condition may occur when the user decides
to go off-hook before the call agent has the time to ask the gateway to
notify an off hook event (the "glare" condition well known in
telephony), or if the user goes on-hook before the call agent has the
time to request the event's notification.
To avoid this race condition, the gateway should check the condition of
the end point before acknowledging a notification request. It should
return an error:
1. If the gateway is requested to notify an "off hook" transition
while the phone is already off hook,
2. If the gateway is requested to notify an "on hook" or "flash hook"
condition while the phone is already on hook.
The other state variables of the gateway, such as the list of requested
event or list of requested signals, are entirely replaced after each
successful notification request, which prevents any long term
discrepancy between the call agent and the gateway.
When a notification request is unsuccessful, the list of requested
events and requested signals are emptied. They must be reinstated by a
new request.
Another race condition may occur when a notification is issued shortly
before the reception by the gateway of a notification request. The
request identifier is used to correlate responses with notifications.
2.5. Return codes and error codes
All SGCP requests are acknowledged. The acknowledgment carries a return
Arango, Huitema [Page 23]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
code, which indicates the status of the request. The return code is an
integer number, for which three ranges of values have been defined:
* values between 200 and 299 indicate a successful completion,
* values between 400 and 499 indicate a transient error,
* values between 500 and 599 indicate a permanent error.
The values that have been already defined are listed in the following
table:
____________________________________________________________
| Code| Meaning |
|______|____________________________________________________|
| 200 | The requested transaction was executed normally. |
| | |
| 250 | The connection was deleted. |
| | |
| 400 | The transaction could not be executed, due to a |
| | transient error. |
| | |
| 401 | The phone is already off hook |
| | |
| 402 | The phone is already on hook |
| | |
| 500 | The transaction could not be executed, because the|
| | end-point is unknown. |
| | |
| 501 | The transaction could not be executed, because the|
| | end-point is not ready. |
| | |
| 502 | The transaction could not be executed, because the|
| | end-point does not have sufficient resources |
| | |
| 510 | The transaction could not be executed, because a |
| | protocol error was detected. |
|______|____________________________________________________|
3. Simple Gateway Control Protocol
The SGCP implements the simple gateway control interface as a set of
transactions. The transactions are composed of a request and a mandatory
response. There are five types of request:
Arango, Huitema [Page 24]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
* CreateConnection
* ModifyConnection
* DeleteConnection
* NotificationRequest
* Notify
The first four requests are sent by the call agent to a gateway. The
Notify request is sent by the gateway to the call agent. The gateway may
also send a DeleteConnection as defined in 2.3.6.
3.1. General description
All requests are composed of a Request 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.
SGCP uses a transaction identifier to correlate requests and responses.
The transaction identifier is encoded as a component of the request
header and repeated as a component of the response header (see section
3.2.1, 3.2.1.2 and 3.3).
Transaction identifiers have values between 1 and 999999999. An SGCP
entity shall not reuse an identifier sooner than 3 minutes after comple-
tion of the previous request in which the identifier was used.
3.2. Request Header
The request header is composed of:
* A request line, identifying the requested action or verb, the end
point towards which the action is requested, and the SGC protocol
version,
* A set of parameter lines, composed of a parameter name followed by
a parameter value.
Arango, Huitema [Page 25]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
3.2.1. Request line
The request line is composed of:
* The name of the requested verb,
* The identification of the transaction,
* The name of the endpoint that should execute the request (in notif-
ications, the name of the endpoint that is issuing the notifica-
tion),
* The 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.
3.2.1.1. Coding of the requested verb
The five verbs that can be requested are encoded as four letter upper or
lower case ASCII codes (comparisons should be case insensitive) as
defined in the following table:
______________________
| Verb | Code|
|______________|______|
| Create | CRCX|
| Connection | |
| | |
| Modify | MDCX|
| Connection | |
| | |
| Delete | DLCX|
| Connection | |
| | |
| Notification| RQNT|
| Request | |
| | |
| Notify | NTFY|
|______________|______|
The transaction identifier is encoded as a string of up to 9 decimal
digits. In the request lines, it immediately follows the coding of the
verb.
New verbs may be defined in further versions of the protocol. It may be
Arango, Huitema [Page 26]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
necessary, for experimentation purposes, to use new verbs before they
are sanctioned in a published version of this protocol. Experimental
verbs should be identified by a four letter code starting by the letter
X, such as for example XPER.
3.2.1.2. Coding of the endpoint names
The end point names are encoded as e-mail addresses, as defined in RFC
821. In these addresses, the domain name identifies the system where
the end point is located, while the left side identifies a specific end
point on that system.
Examples of such addresses can be:
123456@gw23.whatever.net Circuit number 123456 in the
Gateway 23 of the "Whatever"
network
Call-agent@ca.whatever.net Call agent for the whatever
network
Busy-signal@ann12.whatever.net The "busy signal" virtual end
point in the announcement server
number 12.
The name of notified entities is expressed with the same syntax, with
the possible addition of a port number as in:
Call-agent@ca.whatever.net:5234
3.2.1.3. Coding of the protocol version
The protocol version is coded as the key word SGCP followed by a white
space and the version number. The version number is composed of a major
version, coded by a decimal number, a dot, and a minor version number,
coded as a decimal number. In the initial messages, the version will be
coded as:
SGCP 1.0
3.2.2. Parameter lines
Parameter lines are composed of a parameter name, which in most cases is
Arango, Huitema [Page 27]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
composed of a single upper case character, followed by a colon, a white
space and the parameter value. The parameter that can be present in
requests are defined in the following table:
______________________________________________________________________
| Parameter | Parameter| Parameter value |
| name | code | |
|_____________|___________|___________________________________________|
| Call | C | Hexadecimal string, at most 32 characters|
| identifier | | |
| | | |
| Connection | I | Hexadecimal string, at most 32 characters|
| identifier | | |
| | | |
| Notified | N | An identifier, in RFC 821 format, |
| Entity | | composed of an arbitrary string and of |
| | | the domain name of the requesting entity,|
| | | possibly completed by a port number, as |
| | | in: |
| | | Call-agent@ca.whatever.net:5234 |
| | | |
| Request | X | Hexadecimal string, at most 32 characters|
| identifier | | |
| | | |
| Local | L | See description |
| Connection | | |
| Options | | |
| | | |
| Connection | M | See description |
| mode | | |
| | | |
| Requested | R | See description |
| Events | | |
| | | |
| Signal | S | See description |
| Requests | | |
| | | |
| Digit map | D | A text encoding of a digit map |
| | | |
| Observed | O | See description |
| Events | | |
| | | |
| Connection | P | See description |
| parameters | | |
| | | |
| Reason Code| E | An arbitrary character string |
|_____________|___________|___________________________________________|
Arango, Huitema [Page 28]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
The parameters are not necessarily present in all requests. The follow-
ing table provides the association between parameters and requests. The
letter M stands for mandatory, O for optional and F for forbidden.
________________________________________________________
| Parameter name | CRCX| MDCX| DLCX| RQNT| NTFY|
|____________________|______|______|______|______|______|
| Call identifier | M | M | O | F | F |
| | | | | | |
| Connection | F | M | O | F | F |
| identifier | | | | | |
| | | | | | |
| Request identifier| O | O | O | M | M |
| | | | | | |
| Local connection | O | M | F | F | F |
| options | | | | | |
| | | | | | |
| Connection mode | M | M | F | F | F |
| | | | | | |
| Requested Events | O | O | O | O* | F |
| | | | | | |
| Signal Requests | O | O | O | O* | F |
| | | | | | |
| Notified Entity | O | O | O | O | O |
| | | | | | |
| ObservedEvent | F | F | F | F | M |
| | | | | | |
| Digit map | O | O | O | O | F |
| | | | | | |
| Reason Code | F | F | O | F | F |
| | | | | | |
| Connection | F | F | O | F | F |
| parameters | | | | | |
|____________________|______|______|______|______|______|
Note (*) that the Requested Events and Signal Requests parameters are
optional in the notification request. If these parameters are omitted,
the corresponding lists will be considered empty.
3.2.2.1. Local connection options
The local connection options describe the operational parameters that
the call agent suggests to the gateway. These parameters are:
* The length in time in milliseconds, encoded as the keyword "p",
followed by a colon and a decimal number. If the call agent speci-
fies a range of values, the range will be specified as two decimal
Arango, Huitema [Page 29]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
numbers separated by an hyphen.
* The preferred type of compression algorithm, encoded as the keyword
"a", followed by a character string. If the call agent specifies a
list of values, these values will be separated by a semicolon.
* The bandwidth in kilobits, encoded as the keyword "b", followed by
a colon and a decimal number. If the call agent specifies a range
of values, the range will be specified as two decimal numbers
separated by an hyphen.
* The echo cancellation parameter, encoded as the keyword "e", fol-
lowed by a colon and the value "on" or "off".
Each of the parameters is optional. When several parameters are present,
the values are separated by a comma.
Examples of connection descriptors are:
L: p:10, a:G.711
L: p:10, a:G.711;G.726-32
L: p:10-20, b: 64
L: b:32-64, e:off
3.2.2.2. Connection parameters
Connection parameters are encoded as a string of type and value pairs,
where the type is a two letter identifier of the parameter, and the
value a decimal integer. Types are separated from value by an '=' sign.
Parameters are encoded from each other by a comma.
The connection parameter types are specified in the following table:
Arango, Huitema [Page 30]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
________________________________________________________________
| Connection | Parameter| Connection parameter value |
| parameter | Code | |
| name | | |
|______________|___________|____________________________________|
| Packets sent| PS | The number of packets that were |
| | | sent on the connection. |
| | | |
| Octets sent | OS | The number of octets that were |
| | | sent on the connection. |
| | | |
| Packets | PR | The number of packets that were |
| received | | received on the connection. |
| | | |
| Octets | RO | The number of octets that were |
| received | | received on the connection. |
| | | |
| Packets lost| PL | The number of packets that were |
| | | not received on the connection, as|
| | | deduced from gaps in the sequence |
| | | number. |
| | | |
| Jitter | JI | The average inter-packet arrival |
| | | jitter, in milliseconds, expressed|
| | | as an integer number. |
| | | |
| Latency | LA | Average latency, in milliseconds, |
| | | expressed as an integer number. |
|______________|___________|____________________________________|
An example of connection parameter encoding is:
P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48
3.2.2.3. Connection mode
The connection mode describes the mode of operation of the connection.
The possible values are:
Arango, Huitema [Page 31]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
_______________________________________________________________________
| Mode | Meaning |
|____________|________________________________________________________|
| M: sendonly| The gateway should only send packets |
| | |
| M: recvonly| The gateway should only receive packets |
| | |
| M: sendrecv| The gateway should only send and receive packets |
| | |
| M: inactive| The gateway should neither send nor receive packets |
| | |
| M: loopback| The gateway should place the circuit in loopback mode.|
| | |
| M: conttest| The gateway should place the circuit in test mode. |
|____________|________________________________________________________|
3.2.2.4. RequestedEvents
The requested event parameter provides the list of events that have been
requested. Each event is identified by a code, as indicated in the fol-
lowing table. These ASCII encodings are not case sensitive. Values such
as "hu", "Hu", "HU" or "hU" should be considered equal.
_______________________________________________________________
| Event | Code |
|_____________________|________________________________________|
| Fax tones | Ft |
| | |
| Modem tones | Mt |
| | |
| Continuity tone | Co |
| | |
| Continuity detected| Cv |
| (verified) | |
| | |
| On-hook transition | Hu |
| | |
| Off-hook transition| Hd |
| | |
| Flash hook | Hf |
| | |
| Digit collection | Individual digits (e.g. "#"), timers |
| | ("T") |
| | or ranges (e.g. "[0-9]" or "[0-9*#T]")|
|_____________________|________________________________________|
Arango, Huitema [Page 32]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
Each event can be qualified by a requested action, or by a list of
actions. The actions, when specified, are encoded as a list of key-
words, enclosed in parenthesis and separated by commas. The codes for
the various events are:
__________________________________
| Action | Code|
|__________________________|______|
| Notify immediately | N |
| | |
| Accumulate | A |
| | |
| Treat according to digit| D |
| map | |
| | |
| Swap | S |
| | |
| Ignore | I |
|__________________________|______|
When no action is specified, the default action is to notify the event.
This means that, for example, ft and ft(N) are equivalent. Events that
are not listed are ignored.
The digit-map action can only be specified for the digits, letters and
timers.
The requested list is encoded on a single line, with event/action groups
separated by commas. Examples of requested events encoding are:
R: hu(N), hf(S,N)
R: hu(N), [0-9#T](D)
3.2.2.5. Signal Requests
The Signal Requests parameter provides the name of the signals that have
been requested. Each signal is identified by a code, as indicated in the
following table.
Arango, Huitema [Page 33]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
___________________________________________________________________
| Signal | Code |
|_____________________|____________________________________________|
| Ringing | rg |
| | |
| Distinctive ringing| r0, r1,r2, r3, r4, r5, r6 or r7 |
| (0 .. 7) | |
| | |
| Ring back tone | rt |
| | |
| Dial tone | dt |
| | |
| Intercept tone | it |
| | |
| Network Congestion | ct |
| tone | |
| | |
| Busy tone | bt |
| | |
| Confirm tone | ft |
| | |
| Answer tone | at |
| | |
| Call waiting tone | wt |
| | |
| Off hook warning | ot |
| tone | |
| | |
| Preemption tone | pt |
| | |
| Continuity tone | ct |
| | |
| Continuity test | co |
| | |
| DTMF tones | A string composed of the individual digits|
| | that should be played on the end point. |
| | |
| ASDI display | The keyword "ad", followed by the string |
| | that should be displayed, encapsulated |
| | between parentheses as in: |
| | Ad(123456 Your friend) |
|_____________________|____________________________________________|
3.2.2.6. ObservedEvent
The observed event parameters provides the list of events that have been
Arango, Huitema [Page 34]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
observed. The event codes are the same as those used in the notification
request. Events that have been accumulated according to the digit map
are grouped in a single string. Examples of observed actions are:
O: hu
O: 8295555T
O: hf, hf, hu
3.3. Format of response headers
The response header is composed of a response line, optionally followed
by headers that encode the response parameters.
The response line starts with the response code, which is a three digit
numeric value. The code is followed by a white space, the transaction
identifier, and an optional commentary.
In the case of a create connection message, the response line is fol-
lowed by a Connection-Id parameter.
In the case of a delete connection message, the response line is fol-
lowed by a Connection Parameters parameter, as defined in section
3.2.3.2.
A session description should be transmitted with a positive response
(code 200) to a create connection. It may be transmitted in response to
a modify connection request, if the modification resulted in a modifica-
tion of the session parameters.
3.4. Encoding of the session description
The session description is encoded in conformance with the session
description protocol, SDP. SGCP implementations are expected to be fully
capable of parsing any conformant SDP message, and should send session
descriptions that strictly conform to the SDP standard. However, in a
telephony gateway, we only have to describe sessions that use exactly
one media, audio. The parameters of SDP that are relevant for our appli-
cation are:
At the session description level:
* The IP address of the remote gateway (in requests) or of the
local gateway (in queries), or multicast address of the audio
conference, encoded as an SDP "connection data" parameter.
This parameter specifies the IP address that will be used to
exchange RTP packets.
Arango, Huitema [Page 35]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
For the audio media:
* Media description field (m) specifying the audio media, the
transport port used for receiving RTP packets by the remote
gateway (requests) or by the local gateway (responses) , the
RTP/AVP transport, and the list of formats that the gateway
will accept. This list should normally always include the code
0 (reserved for G.711).
* Optionally, RTPMAP attributes that define the encoding of
dynamic audio formats,
* Optionally, a packet time attribute (Ptime) defining the dura-
tion of the packet
* Optionally, an attribute defining the type of connection (sen-
donly, recvonly, sendrecv, inactive)
* The IP address of the remote gateway (in requests) or of the
local gateway (in queries), if it is not present at the ses-
sion level.
There is a request, in some environments, to use the SGCP to negotiate
connections that will use other transmission channels than RTP over UDP
and IP. This will be detailed in an extension to this document.
3.5. Transmission over UDP
SGCP messages are transmitted over UDP. Requests are sent to one of the
IP addresses defined in the DNS for the specified end point. The
responses are sent back to the source address of the requests.
SGCP messages, being carried over UDP, may be subject to losses. In the
absence of a timely response, requests are repeated. SGCP entities are
expected to keep in memory a list of the responses that they sent to
recent transactions, i.e. a list of all the responses they sent over the
last 30 seconds, and a list of the transactions that are currently being
executed. The transaction identifiers of incoming requests are compared
to the transaction identifiers of the recent responses. If a match is
found, the SGCP entity does not execute the transaction, but simply
repeats the response. The remaining requests will be compared to the
list of current transaction. If a match is found, the SGCP entity does
not execute the transaction, which is simply ignored.
It is the responsibility of the requesting entity to provide suitable
time outs for all outstanding requests, and to retry requests when time
outs have been exceeded. Furthermore, when repeated requests fail to be
Arango, Huitema [Page 36]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
acknowledged, it is the responsibility of the requesting entity to seek
redundant services and/or clear existing or pending connections.
4. Security requirements
If unauthorized entities could use the SGCP, they would be able to set-
up unauthorized calls, or to interfere with authorized calls. We expect
that SGCP messages will always be carried over secure Internet connec-
tions, as defined in the IP security architecture as defined in RFC
1825, using either the IP Authentication Header, defined in RFC 1826, or
the IP Encapsulating Security Payload, defined in RFC 1827. The complete
SGCP protocol stack would thus include the following layers:
________________________________
| SGCP |
|_______________________________|
| UDP |
|_______________________________|
| IP security (authentication or|
| encryption) |
|_______________________________|
| IP |
|_______________________________|
| transmission media |
|_______________________________|
Adequate protection of the connections will be achieved if the gateways
and the call agents only accept messages for which IP security provided
an authentication service. An encryption service will provide additional
protection against eavesdropping, thus forbidding third parties from
monitoring the connections set up by a given end point.
The encryption service will also be requested if the session descrip-
tions are used to carry session keys, as defined in SDP.
5. Example of call flows
In order to understand the way the SGCP interface will be used, we have
described here two possible call flows between a TGW, which is a trunk-
ing gateway that implements SGCP, and an RGW, which is a residential
gateway that implements SGCP.
The diagrams also show a Common Data Base (CDB) that can be queried for
authorization and routing information, and an Accounting Gateway (ACC)
Arango, Huitema [Page 37]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
that collects accounting information at the start and the end of calls.
These diagrams are solely meant to exhibit the behavior of the SGCP, and
to help understanding this protocol. They are not meant as a tutorial on
the implementation of a call agent. They may very well include miscel-
laneous errors and imprecisions.
5.1. Basic call, RGW to TGW
Arango, Huitema [Page 38]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
Usr RGW CA CDB ACC TGW SS7/ISUP CO
<- Notification
Request
Ack ->
Off-hook Notify ->
<- Ack
(Dial-tone) <- Notification
Request
Ack ->
Digit Notify ->
<- Ack
(progress) <- Notification
Request
Ack ->
<- Create
Connection
Ack ->
Query ->
(E.164 S,D)
<- IP
Create - - - - ->
Connection (cut
in)
<- - - - - ack
IAM - - - - - - ->
<- Modify IAM ->
Connection
Ack -> <- ACM
<- - - - - - - ACM
<- Notification
Request
Ack ->
<- ANM
<- - - - - - - ANM
<- Notification
Request
Ack ->
Arango, Huitema [Page 39]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
<- Modify
Connection
Ack ->
(cut Call start - - - >
in)
<- REL
<- - - - - - - REL
<- Delete
Connection
Delete - - - - ->
Connection
Perf ->
Data
<- - - - - perf
data
Call end - - ->
On-hook Notify ->
<- Ack
<- Notification
Request
Ack ->
During these exchanges the SGCP is used by the call agent to control
both the TGW and the residential gateway. The exchanges occur on two
sides.
The first command is a notification request, sent by the call agent to
the residential gateway. The request will consist of the following
lines:
RQNT 1201 endpoint-1@rgw-2567.whatever.net SGCP 1.0
N: ca@ca1.whatever.net:5678
X: 0123456789AB
R: hd
The gateway, at that point, is instructed to look for an off-hook event,
and to report it. It will first acknowledge the request, repeating in
the acknowledgement message the transaction id that the call agent
attached to the query.
200 1201 OK
Arango, Huitema [Page 40]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
When the off hook event is noticed, the gateway initiates a notification
request to the call agent:
NTFY 2001 endpoint-1@rgw-2567.whatever.net SGCP 1.0
N: ca@ca1.whatever.net:5678
X: 0123456789AB
O: hd
The call agent immediately acknowledges that notification.
200 2001 OK
The call agent examines the services associated to an off hook action
(it could take special actions in the case of a direct line). In most
cases, it will send a notification request, asking for more digits. The
current example provides the gateway with a permanent digit map, and
request the gateway to play a dialtone:
RQNT 1202 endpoint-1@rgw-2567.whatever.net SGCP 1.0
N: ca@ca1.whatever.net:5678
X: 0123456789AC
R: hu, [0-9#*T](D)
D: (0T | 00T | [1-7]xxx | 8xxxxxxx | #xxxxxxx | *xx |
91xxxxxxxxxx | 9011x.T)
S: dt
The gateway immediately acknowledges that request.
200 1202 OK
The gateway will start accumulating digits according to that digit map.
When it has noticed a sufficient set of values, it will notify the
observed string to the call agent:
NTFY 2002 endpoint-1@rgw-2567.whatever.net SGCP 1.0
N: ca@ca1.whatever.net:5678
X: 0123456789AC
O: 912018294266
The call agent immediately acknowledges that notification.
200 2002 OK
At this stage, the call agent will send a notification request, to stop
collecting digits yet continue watch for an on-hook transition:
Arango, Huitema [Page 41]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
RQNT 1203 endpoint-1@rgw-2567.whatever.net SGCP 1.0
X: 0123456789AD
R: hu
The call agent immediately acknowledges that request.
200 1203 OK
The call agent will then seize the incoming circuit, creating a connec-
tion:
CRCX 1204 endpoint-1@rgw-2567.whatever.net SGCP 1.0
C: A3C47F21456789F0
L: p:10, a:G.711;G.726-32
M: recvonly
The gateway immediately acknowledges the creation, sending back the
identification of the newly created connection and the session descrip-
tion used to receive audio data:
200 1204 OK
I:FDE234C8
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The SDP announcement, in our example, specifies the address at which the
gateway is ready to receive audio data (128.96.41.1), the transport pro-
tocol (RTP), the RTP port (3456) and the audio profile (AVP). The audio
profile refers to RFC 1890, which defines that the payload type 0 has
been assigned for G.711 transmission. The gateway is also ready to use
ADPCM encoding at 32 kbps (G.726 4). There is no standard payload type
associated to ADPCM, so the gateway mentions its readiness to use a non
standard payload associated to the dynamic type 96. The "rtpmap" attri-
bute entry associates the payload type 96 to G726-32.
The call agent, having seized the incoming trunk and completed a routing
look up to identify the outgoing gateway, must now seize the outgoing
trunk. It does so by sending a connection request to the e-gress gate-
way:
Arango, Huitema [Page 42]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
CRCX 1205 card23/21@trgw-7.whatever.net SGCP 1.0
C: A3C47F21456789F0
L: p:10, a:G.711;G.726-32
M: sendrecv
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The create connection command has the same parameters as the command
sent to the ingress gateway, with two differences:
* The endpoint identifier points towards the outgoing trunk,
* The message carries the session description returned by the ingress
gateway,
* Because the session description is present, the "mode" parameter is
set to "send/receive".
We observe that the call identifier is identical for the two connec-
tions. This is normal: the two connections belong to the same call,
which has a global identifier in our system.
The trunking gateway will acknowledge the connection request, sending in
the session description its own parameters such as address, ports and
RTP profile:
200 1205 OK
I:32F345E2
v=0
c=IN IP4 128.96.63.25
m=audio 1297 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The call agent will relay the information to the ingress gateway, using
a Modify Connection request:
Arango, Huitema [Page 43]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
MDCX 1206 endpoint-1@rgw-2567.whatever.net SGCP 1.0
C: A3C47F21456789F0
I:FDE234C8
M: recvonly
v=0
c=IN IP4 128.96.63.25
m=audio 1297 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The gateway immediately acknowledges the modification:
200 1206 OK
At that stage, we have established a half duplex transmission path. The
phone attached to the RGW will be able to receive the signals, such as
tones or announcements, that the remote switch may send through the
trunking gateway.
When the call progresses, the call agent will receive from the remote
switch progress messages, for example an "address complete" message
(ACM). The call agent will analyze the message to determine whether
signal are transmitted in band. If this is not the case, the call agent
will instruct the RGW to generate ringing tones by sending a notifica-
tion request:
RQNT 1207 endpoint-1@rgw-2567.whatever.net SGCP 1.0
X: 0123456789AE
R: hu
S: rt
The gateway immediately acknowledges the request:
200 1207 OK
After the remote user goes off hook, the call agent will receive an
answering message (ANM) from the remote switch. At that point, it will
send a notification request to the gateway, to stop the ringing tones,
and a modification message, to place the connection in full duplex mode:
Arango, Huitema [Page 44]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
RQNT 1208 endpoint-1@rgw-2567.whatever.net SGCP 1.0
X: 0123456789AF
R: hu
MDCX 1209 endpoint-1@rgw-2567.whatever.net SGCP 1.0
C: A3C47F21456789F0
I:FDE234C8
M: sendrecv
The gateway will acknowledge these two requests:
200 1208 OK
200 1209 OK
At this point, the connection is established.
After some time, the call agent will have to tear down the call. It will
do so by sending to both gateways a delete connection request:
DLCX 1210 endpoint-1@rgw-2567.whatever.net SGCP 1.0
C: A3C47F21456789F0
I:FDE234C8
DLCX 1211 card23/21@trgw-7.whatever.net SGCP 1.0
C: A3C47F21456789F0
I:32F345E2
The gateways will respond with a message that should include a "call
parameters" header fields:
250 1210 OK
P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48
250 1211 OK
P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27, LA=48
At this point, the user, in our scenario, hangs up the call. This event
is notified to the call agent, according to the policy received in the
last notification request:
NTFY 2005 endpoint-1@rgw-2567.whatever.net SGCP 1.0
X: 0123456789AF
O: hu
Arango, Huitema [Page 45]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
After this notification, the call agent should send an acknowledgement:
200 2005 OK
It should then issue a new notification request, to be ready to detect
the next call issued by the residential gateway:
RQNT 1212 endpoint-1@rgw-2567.whatever.net SGCP 1.0
X: 0123456789B0
R: hd
The gateway will acknowledge this message:
200 1212 OK
Both gateways, at this point, are ready for the next call.
5.2. Basic call, TGW to RGW
Arango, Huitema [Page 46]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
CO SS7/ISUP TGW CA CDB ACC RGW Usr
IAM ->
IAM - - - ->
Check ->
<- IP
<- Create
Connection
Ack ->
Create - - - - ->
Connection
<- - - - - Ack
<- Modify
Connection
Ack ->
Notification - - - - -> ring
Request
<- - - - - Ack
<- - - - ACM
<- ACM
off
hook
<- - - - - Notify
Ack - - - - ->
Notification - - - - ->
Request
<- - - - - Ack
<- Modify
Connection
Ack ->
(cut-in) Call start - - - >
<- - - - ANM
<- ANM
on
hook
Arango, Huitema [Page 47]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
<- - - - - Notify
Ack - - - - ->
Delete - - - - ->
Connection
<- Delete
Connection
<- - - - REL
<- REL
Perf ->
data
<- - - - - perf
data
Call end - - - >
Notification - - - - ->
Request
<- - - - - Ack
This diagram shows the various exchange of messages during a call from a
telephone user to a residential user. During these exchanges the SGCP is
used by the call agent to control both the TGW and the residential gate-
way. The exchanges occur on two sides.
Upon reception of the IAM message, the call agent will immediately seize
the incoming trunk, creating a connection:
CRCX 1237 card23/21@trgw-7.whatever.net SGCP 1.0
C: A3C47F21456789F0
L: p:10, a:G.711;G.726-32
M: recvonly
The gateway immediately acknowledges the creation, sending back the
identification of the newly created connection and the session descrip-
tion used to receive audio data:
200 1237 OK
I: FDE234C8
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The SDP announcement, in our example, specifies the address at which the
gateway is ready to receive audio data (128.96.41.1), the transport pro-
tocol (RTP), the RTP port (3456) and the audio profile (AVP). The audio
profile refers to RFC 1890, which defines that the payload type 0 has
Arango, Huitema [Page 48]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
been assigned for G.711 transmission. The gateway is also ready to use
ADPCM encoding at 32 kbps (G.726 4). There is no standard payload type
associated to ADPCM, so the gateway mentions its readiness to use a non
standard payload associated to the dynamic type 96. The "rtpmap" attri-
bute entry associates the payload type 96 to G726/4.
The call agent, having seized the incoming trunk, must now reserve the
outgoing circuit. It does so by sending a connection request to the
residential gateway:
CRCX 1238 endpoint-1@rgw-2567.whatever.net SGCP 1.0
C: A3C47F21456789F0
L: p:10, a:G.711;G.726-32
M: sendrecv
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The create connection command has the same parameters as the command
sent to the ingress gateway, with two differences:
* The endpoint identifier points towards the outgoing trunk,
* The message carries the session description returned by the ingress
gateway,
* Because the session description is present, the "mode" parameter is
set to "send/receive".
We observe that the call identifier is identical for the two connec-
tions. This is normal: the two connection belong to the same call,
which has a global identifier in our system.
The trunking gateway will acknowledge the connection request, sending in
the session description its own parameters such as address, ports and
RTP profile:
200 1238 OK
I:32F345E2
v=0
c=IN IP4 128.96.63.25
m=audio 1297 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The call agent will relay the information to the ingress gateway, using
Arango, Huitema [Page 49]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
a Modify Connection request:
MDCX 1239 card23/21@trgw-7.whatever.net SGCP 1.0
C: A3C47F21456789F0
I:FDE234C8
M: recvonly
v=0
c=IN IP4 128.96.63.25
m=audio 1297 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The gateway immediately acknowledges the modification:
200 1239 OK
At that stage, we have established a half-duplex transmission path. The
call agent must now ring the residential gateway. It will send a notifi-
cation request, which will consist of the following lines:
RQNT 1240 endpoint-1@rgw-2567.whatever.net SGCP 1.0
X: 0123456789B1
R: hd
S: rg
The gateway, at that point, is instructed to look for an off-hook event,
and to report it. It will first acknowledge the request, repeating in
the acknowledgement message the transaction id that the call agent
attached to the query.
200 1240 OK
Upon reception of this message, the call agent sends an address complete
message (ACM) to the calling switch, which will generate ringing tones
for the calling user.
When the off hook event is noticed, the gateway initiates a notification
request to the call agent:
NTFY 2001 endpoint-1@rgw-2567.whatever.net SGCP 1.0
X: 0123456789B0
O: hd
The call agent immediately acknowledges that notification.
200 2001 OK
The call agent must now ask the residential gateway to notify the
Arango, Huitema [Page 50]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
occurrence of an on-hook event. It does so by sending a notification
request to the residential gateway:
RQNT 1241 endpoint-1@rgw-2567.whatever.net SGCP 1.0
X: 0123456789B1
R: hu
The gateway acknowledges that request:
200 1241 OK
In parallel, the call agent will send a modification request to the
trunking gateway, to place the connection in full duplex mode:
MDCX 1242 card23/21@trgw-7.whatever.net SGCP 1.0
C: A3C47F21456789F0
I:FDE234C8
M: sendrecv
The trunking gateway will acknowledge that request:
200 1242 OK
The call agent can now send an answer message (ANM) to the calling
switch.
After some time, the call agent will have to tear down the call. In our
example, this is triggered by the residential user, who hangs up. The
notify request is sent to the call agent:
NTFY 2005 endpoint-1@rgw-2567.whatever.net SGCP 1.0
X: 0123456789B1
O: hu
The call agent acknowledges the notification.
200 2005 OK
It will then send to both gateways a delete connection request:
DLCX 1243 endpoint-1@rgw-2567.whatever.net SGCP 1.0
C: A3C47F21456789F0
I:FDE234C8
DLCX 1244 card23/21@trgw-7.whatever.net SGCP 1.0
C: A3C47F21456789F0
I:32F345E2
Arango, Huitema [Page 51]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
The gateways will respond with a message that should include a "call
parameters" header fields:
200 1243 OK
P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48
200 1244 OK
P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27, LA=48
The gateway should now issue a new notification request, to be ready to
detect the next call issued by the residential gateway:
RQNT 1245 endpoint-1@rgw-2567.whatever.net SGCP 1.0
X: 0123456789B2
R: hd
The call agent will acknowledge this request:
200 1245 OK
Both gateways, at this point, are ready for the next call.
Acknowledgements
We want to thank here the many reviewers who provided us with advice on
the design of SGCP, notably Flemming Andreasen, David Auerbach, Bob
Biskner, Barry Hoffner, Dave Oran, Lou Rubin and Joe Stone.
References
* Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", RFC 1889, January
1996.
* Schulzrinne, H., "RTP Profile for Audio and Video Conferences with
Minimal Control", RFC 1890, January 1996
* Handley, M, Jacobson, V., "SDP: Session Description Protocol", RFC
2327, April 1998.
* Handley, M., "SAP - Session Announcement Protocol", Work in Pro-
gress.
Arango, Huitema [Page 52]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
* Handley, M., Schooler, E., and H. Schulzrinne, "Session Initiation
Protocol (SIP)", Work in Progress.
* Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
* ITU-T, Recommendation Q.761, "FUNCTIONAL DESCRIPTION OF THE ISDN
USER PART OF SIGNALLING SYSTEM No. 7", (Malaga-Torremolinos, 1984;
modified at Helsinki, 1993)
* ITU-T, Recommendation Q.762, "GENERAL FUNCTION OF MESSAGES AND SIG-
NALS OF THE ISDN USER PART OF SIGNALLING SYSTEM No. 7", (Malaga-
Torremolinos, 1984; modified at Helsinki, 1993)
* ITU-T, Recommendation H.323, "VISUAL TELEPHONE SYSTEMS AND EQUIP-
MENT FOR LOCAL AREA NETWORKS WHICH PROVIDE A NON-GUARANTEED QUALITY
OF SERVICE."
* ITU-T, Recommendation H.225, "Call Signaling Protocols and Media
Stream Packetization for Packet Based Multimedia Communications
Systems."
* ITU-T, Recommendation H.245, "LINE TRANSMISSION OF NON-TELEPHONE
SIGNALS."
* Atkinson, R., "Security Architecture for the Internet Protocol."
RFC 1825, August 1995.
* Atkinson, R., "IP Authentication Header." RFC 1826, August 1995.
* Atkinson, R., "IP Encapsulating Security Payload (ESP)." RFC 1827,
August 1995.
Authors' Addresses
Arango, Huitema [Page 53]
Internet draft Simple Gateway Control Protocol (SGCP) 15 May 1998
Mauricio Arango
Bellcore
MCC 1A266B
445 South Street
Morristown, NJ 07960
U.S.A.
Phone: +1 973-829-4409
EMail: arango@bellcore.com
Christian Huitema
Bellcore
MCC 1J236B
445 South Street
Morristown, NJ 07960
U.S.A.
Phone: +1 973-829-4266
EMail: huitema@bellcore.com
Arango, Huitema [Page 54]