Extending SGCP to support Voice over ATM

SGCP is used to remote control gateways and instruct them to forward the voice signals received on a circuit towards another gateway. SGCP commands (Create Connection and Modify Connection) carry an SDP (Session Description Protocol) payload, where the VoIP parameters such as supported encoding, RTP options, UDP port and IP address are defined. In some network configurations, gateways expect to carry the voice packets over an ATM or a frame relay network. SGCP can easily be extended to provide signalling for these gateways. As indicated in the following picture, the call agent would send commands to the gateways using SGCP over IP, and the voice transmission would be over ATM virtual circuits. The IP network used to carry SGCP can indeed be provisioned by using a set of ATM virtual circuits, using IP over ATM.

(picture showing the roles of SGCP, ISUP and ATM)

The following extensions were proposed by Michael H. Grobelch from Cisco.

Extensions to SDP

for circuit connection using CES soft PVCs, modification to SGCP itself does not appear to be necessary. Rather, enhancement of the Session Description Protocol can provide the needed function. In particular, changes to the media ("m" line), connection ("c" line), and possibly new attributes ("a" lines).

  connection description:
        c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00

This allows the destination ATM NSAP address to be returned in a response when a connection is created, and specified to the source Soft PVC gateway.

  media description:
        m=audio  ces20

here, the "ces20" field indicates that transport over the ATM network is per the ATM Forum CES v.2.0 specification. This uniquely specifies many of the characteristics of the ATM connection used in transport of the bearer channel, including the service category (CBR) and ATM Adaption layer (AAL1).

The VPI/VCI field is the VPI/VCI signalled in the SETUP message for the CES Soft PVC (this is the VPI/VCI used at the destination interface). It is appropriate in the "port" field of the m line.

Reason Code in the Delete Connection

For the Reason code passed by the ATM Gateway when it initiates a DeleteConnection, the following format is proposed:

If the cause is a network release (note that DeleteConnection should not be sent as a result of a release from the connection peer):
```
netrel: location:0xZ, cause:0xZZ, diag:0xZ..Z
```
The above format includes the contents of the Cause Information Element in the RELEASE message. The diag field is optinal, included if present in the RELEASE message.
Other events causing the LS1010 to delete the connections (not all may be implemented in first release):
- intfdown: the T1/E1 interface goes down.
- underrun: persistent underrun occurs on ATM network connection.
- overrun: persistent overrun occurs on ATM network connection.
- overcdv: persistent exceeding of cell delay variation criterion on circuit.

Examples:

        E: netrel: location:0x1, cause:0x1f
        E: overrun

Additional extensions

Some extensions to the above proposal can be made via the use of SDP attribute lines:

The above extensions don't specify echo cancellation and compression. New ATM hardware will have these capabilities. An attribute line could be used to list the types of compression available.
CES features currently statically configured at each circuit could potentially be negotiated between the endpoints (perhaps based on configuration preferences in each switch):
- Cell partial fill. Used to reduce delay at the expense of higher bandwidth over the ATM network. Units are bytes per cell, 0-47.
- Cell delay variation(cdv). This can limit the cdv accumulated over the ATM network connection.

New CES schemes (perhaps VBR and AAL2) can be accomodated by new media description lines.

Back to the SGCP FAQ
Back to the SGCP page