1. Introduction

The SGCP assumes a connection model where the basic constructs are endpoints 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

1.2 Relation with the IETF standards

• 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 distributed gateway systems and SGCP will enable telephony users to access these sessions. The call agent will provide for signaling conversion, according to the following table:
 

Functional Plane	Phone switch	Terminating Entity	IETF conforming systems
Signaling Plane	Signaling exchanges through SS7/ISUP	Call agent	Signaling exchanges with the call agent through SAP, SIP or 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 Data Transport Plane	Connection through high speed trunk groups	Telephony gateways	Transmission of VoIP data using RTP, directly between the remote system and the 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

2.1 Model and naming conventions.

2.1.1 Names of endpoints

• the domain name of the gateway that is managing the end point,
• a local name within that gateway.

• In the ISUP protocol, circuits are grouped in trunk groups, identified by the SS7 point codes of the switches that the group connects. Circuit within a group are identified by a circuit number.
• In the gateway configuration files, physical interfaces are typically identified by the name of the interface, an arbitrary text string. When the interface multiplexes several circuits, individual circuits are typically identified by a circuit number.
• In SGCP, the endpoints are identified by an end point name.

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.
 

2.1.2 Names of calls

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 identifier. This identifier can then be used by accounting or management procedures, which are outside the scope of SGCP.
 

2.1.3 Names of connections

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 reliability. 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.

2.1.5 Numbering plans

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 procedure 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)

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 numbering 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.

2.2 Usage of SDP

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

• 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 sustained.

• A specific trunk circuit, within a trunk group terminating in a gateway,
• A specific announcement handled by an announcement server.

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 "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

NotificationRequest( EndpointId,
NotifiedEntity,
RequestedEvents,
RequestIdentifier,
DigitMap,
SignalRequests)

NotifiedEntity is an optional parameter that specifies where the notifications 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 notifications 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).

• Notify the event immediately, together with the accumulated list of observed events,
• Swap audio,
• Accumulate according to Digit Map,
• Ignore the event.

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 connection is attached to the audio functions of the endpoint, the notification 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.

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 provision the gateways with a digit map according to which digits will be accumulated. This parameter must be present if the requested events contain an request to "accumulate according to the digit map." The collection 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 collected 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).

The specific definition of actions which are requested via these signal requests, such as the duration of and frequency of a DTMF digit, is outside the scope of SGC. This definition may vary from location to location 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

NotifiedEntity is an optional parameter that identifies the entity to which the notifications is sent. This parameter is equal to the NotifiedEntity 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 parameter 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 identification of events that were requested in the RequestedEvents parameter 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.
 

2.3.3 CreateConnection

ConnectionId,
LocalConnectionDescriptor <--- CreateConnection(
CallId,
EndpointId,
NotifiedEntity,
LocalConnectionOptions,
Mode,
RemoteConnectionDescriptor,
RequestedEvents,
RequestIdentifier,
DigitMap,
SignalRequests)  

CallId is a global unique parameter that identifies the call (or session) 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 LocalConnectionDescriptor 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 executing CreateConnection. The fields contained by LocalConnectionOptions are the following:

• Encoding Method
• Packetization period
• Bandwidth
• Type of Service,
• Usage of echo cancellation

• 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 gateway.

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 LocalConnectionDescriptor, 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 connection. 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 Loopback

• 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 endpoint.
• 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.

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 potentially 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 announcements or listening to insane data. The behavior of the gateway is determined 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.

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 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.

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

[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 function, as part of the local connection descriptor. It uniquely identifies the connection within the call.

The ModifyConnection command can be used to affect parameters of a connection 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.

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 modification 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.

Connection-parameters <-- DeleteConnection(CallId,
EndpointId,
ConnectionId,
NotifiedEntity,
RequestedEvents,
RequestIdentifier,
DigitMap,
SignalRequests)

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 parameters that describe the status of the connection. These parameters are:

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)

2.3.7 DeleteConnection (multiple connections, from the call agent)

DeleteConnection( CallId,
                    EndpointId)

DeleteConnection( EndpointId)

This command does not return any individual statistics or call parameters.
 

2.4 Race conditions

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.

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.

• 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.

3. Simple Gateway Control Protocol

• CreateConnection
• ModifyConnection
• DeleteConnection
• NotificationRequest
• Notify

3.1 General 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 completion of the previous request in which the identifier was used.
 

3.2 Request Header

• 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.

3.2.1 Request line

• The name of the requested verb,
• The identification of the transaction,
• The name of the endpoint that should execute the request (in notifications, the name of the endpoint that is issuing the notification),
• The protocol version.

3.2.1.1 Coding of the requested verb

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 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.2.1 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.2.2 Coding of the protocol version

3.2.3 Parameter lines

3.2.3.1 Local connection options

• The length in time in milliseconds, encoded as the keyword "p", 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 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", followed by a colon and the value "on" or "off".

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.3.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:
 

Connection parameter name	Parameter   Code	Connection parameter value
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 received	PR	The number of packets that were received on the connection.
Octets received	RO	The number of octets that were 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.3.3 Connection mode

3.2.3.4 RequestedEvents

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 keywords, 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 map	D
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.3.5 Signal Requests

3.2.3.6 ObservedEvent

The observed event parameters provides the list of events that have been 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 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 followed by a Connection-Id parameter.

In the case of a delete connection message, the response line is followed 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 modification of the session parameters.
 

3.4 Encoding of the session description

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.

• 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 duration of the packet
• Optionally, an attribute defining the type of connection (sendonly, 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 session level.

3.5 Transmission over UDP

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 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 connections, 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:

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 descriptions 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 trunking 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) 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 miscellaneous errors and imprecisions.
 

5.1 Basic call, RGW to TGW

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:

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 gateway:

• 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".

The trunking gateway will acknowledge the connection request, sending in the session description its own parameters such as address, ports and RTP profile:

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 notification request:

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:

5.2 Basic call, TGW to RGW

Upon reception of the IAM message, the call agent will immediately seize the incoming trunk, creating a connection:

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:

• 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".

The trunking gateway will acknowledge the connection request, sending in the session description its own parameters such as address, ports and RTP profile:

When the off hook event is noticed, the gateway initiates a notification request to the call agent:

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:

200 1242 OK

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:

        200 2005 OK

It will then send to both gateways a delete connection request:

6. 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 Progress.
• 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 SIGNALS 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 EQUIPMENT 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.