01-chapter 1 h

8/3/2019 01-Chapter 1 H

1/19

8/3/2019 01-Chapter 1 H

2/19

Technical Manual Signaling & ProtocolsHUAWEI MSOFTX3000 Mobile SoftSwitch Center Chapter 1 H.248

Huawei Technologies Proprietary

1-1

Chapter 1 H.2481.1 Overview

H.248/MEGACO has been jointly developed within the ITU-T and the IETF. It is named

H.248 by the ITU-T and MEGACO by the IETF. In the following, both are called H.248 in

this manual.H.248 is a MG control protocol. In a decomposed gateway model, H.248 is used for the

communication between a media gateway controller (MGC) and an MG (MG),

implementing the function of the MGC controlling MGs. In UMTS, H.248 is applied on

the Mc interface.1.1.1 Definition and Functions of the Mc Interface

I. Definition of the Mc InterfaceThe Mc interface is a standard one between the MSC Server (GMSC Server) and the

MGW. It complies with H.248 . Aiming at special demands of 3GPP, H.248 extended

Transaction and Package are defined. The Mc interface is an additional interface for3GPP R4. The physical interface mode may be ATM or IP.Protocol messages through the Mc interface may be encoded in a binary format or in a

text format. The underlying transmission mechanism provides protocol bearer for it by

using MTP3b (ATM based signaling transfer) or SCTP (IP based signaling transfer). II. Functions Provided by the Mc Interface

The Mc interface provides

The capabilities of the static and dynamic resources for the MSC Server (GMSCServer) controlling the various transmission modes (IP/ATM/TDM) in the MGW in

the call processing procedure.

Such capabilities include terminal property, terminal connection switching

relationship, MGW borne media streams

The call independent MGW status maintenance and management capability.1.1.2 H.248 Implementation in CSCN

H.248 is utilized on the interface between MSOFTX3000 and UMG8900, namely Mc

interface defined in UMTS. See Figure 1-1.

8/3/2019 01-Chapter 1 H

3/19



1-2

Nc

MSC Server(MSOFTX3000)

Mc Mc

MWG(UMG8900)

MWG(UMG8900)

H.248 H.248

GMSC Server(MSOFTX3000)

Nc

MSC Server(MSOFTX3000)

Mc Mc

MWG(UMG8900)

MWG(UMG8900)

H.248 H.248

GMSC Server(MSOFTX3000)

Figure 1-1 H.248 protocol implementation in CSCN

1.1.3 Structure of the Protocol StackAs shown in Figure 1-2, H.248 is applied to the Mc interface. Protocol transmission may

be based on IP (figure a) or based on ATM (figure b). IP based transmission is typically

used due to the current networking structure.

H.248

SCTP

IP

MAC

L1

(G)MSC ServerMc

MGW

a) IP based

McMGW

b) ATM based

(G)MSC Server

H.248H.248

SCTP

IP

MAC

L1

STC

SAAL

AAL5

MTP3B

ATM

PL

H.248

STC

SAAL

AAL5

MTP3B

ATM

PL

H.248

SCTP

IP

MAC

L1

(G)MSC ServerMc

MGW

a) IP based

McMGW

b) ATM based

(G)MSC Server

H.248H.248

SCTP

IP

MAC

L1

STC

SAAL

AAL5

MTP3B

ATM

PL

H.248

STC

SAAL

AAL5

MTP3B

ATM

PL

Figure 1-2 Structure of H.248 protocol

8/3/2019 01-Chapter 1 H

4/19

8/3/2019 01-Chapter 1 H

5/19



1-4

In the connection model defined by the H.248/MEGACO, two entities, namely Context

and Termination, are included. A Context shall contain one or more Terminations;

otherwise, the Context will be deleted. A Termination shall exist in only one Context at a

single time point.

1) ContextA Context is an association between a number of Terminations. The Context describes

the topology and the media mixing/switching parameters if more than two Terminations

are involved in the association.There is a special Context called the null Context. It contains Terminations that

Terminations that are not associated to any other Termination. Terminations in the null

Context can have their parameters examined or modified, and may have events

detected on them.The maximum number of Terminations in a Context is an MG property.The attribute of Contexts is : Context identifier (ContextID), which is 32-bit and uniquely

identifies a Context within the scope of the MG.Some special contextIDs are coded as shown in Table 1-1:Table 1-1 Codes of special Contexts

Context Binary code Text code

NULL Context

0 -

CHOOSE Context 0xFFFFFFFE $ALL Context 0xFFFFFFFF *

Topology: The topology of a Context describes the flow of media between the

Terminations within a Context. In contrast, the mode of a Termination describes

the flow of the media at the ingress/egress of the MG. Priority: It indicates the priority given to a Context from the MG. The value range is

0~15. The less the value is, the higher the priority is. Emergency indicator: An indicator for an emergency call is also provided to allow a

preference handling in the MG.2) TerminationA Termination is a logical entity on an MG that sources and/or sinks media and/or

control streams. A Termination is described by a number of attributes, which are

grouped in a set of descriptors that are included in commands. Terminations have

unique identifies (TerminationIDs), assigned by the MG at the time of their creation.Usually Terminations are grouped into two classes: semi-permanent Terminations and

ephemeral Terminations. Terminations representing physical entities have a

8/3/2019 01-Chapter 1 H

6/19



1-5

semi-permanent existence. For example, a Termination representing a TDM channel

might exist for as long as it is provisioned in the gateway. Only if the configuration

information is deleted, the corresponding Termination disappears. Ephemeral

Terminations represent ephemeral information flows, such as RTP flows, would usuallyexist only for the duration of their use. Ephemeral Terminations are created by means

of an Add command. They are destroyed by means of a Subtract command. In contrast,

when a physical Termination is added to or subtracted from a Context, it is taken from or

to the null Context, respectively. Termination dynamics: The protocol can be used to create new Terminations and

to modify the property values of existing Terminations. TerminationIDs: Terminations are referenced by a TerminationID, which is an

arbitrary schema by the MG. A wildcarding mechanism using two types of

wildcards can be used with TerminationsIDs. The two wildcards are ALL and

CHOOSE. Packages: Different types of gateways may implement Terminations that have

widely differing characteristics. In order to achieve the MG/MGC interoperability,

optional properties of the Termination are grouped into Packages, and a

Termination realizes a set of such Packages. Termination properties and descriptors: Terminations have properties. The

properties have unique PropertyID. ROOT Termination: The ROOT Termination is typically used to refer to the entire

gateway. Packages may be defined on ROOT. Root thus may have properties,

events, signals, statistics and parameters. The ROOT Termination may appear ina Modify, Notify, AuditValue, AuditCapability and ServiceChange commands. Any

other use of the ROOT TerminationID is an error. Commands: The protocol provides commands for manipulating the logical entities

of the connection model, Contexts and Terminations. Most commands are for the

specific use of the MGC as command initiator in controlling MGs as command

responders. The exceptions are the Notify and ServiceChange commands: Notify

is sent from the MG to the MGC, and ServiceChange may be sent by either entity.

For the meanings of the commands, please reference the following section about

command explanation. Descriptors: The parameters to a command are termed Descriptors. A Descriptor

consists of a name and a list of items. Descriptors may be returned in the response

as output from a command. In any such return of descriptor contents, an empty

descriptor is represented by its name unaccompanied by any list.1.2.2 Message Structure

A message is an information unit sent by H.248. A message may be encoded in a

binary format or in a text format.

8/3/2019 01-Chapter 1 H

7/19



1-6

In the case of binary codes, specifications defined in ITU-T X.680 (ASN.1) are

used for description, and BER rules defined in X.690 for encoding;

In the case of text format, RFC 2234 ABNF specifications are followed.

THE MGCs should support both encoding formats. MGs may support one of or bothformats. Any H.248 message shares the same structure as shown in Figure 1-4.

Megaco/H.248 message

Trans Hdr

Req orReply

Req orReply

Req orReply

Transaction Transaction Transaction....Header

CommandCtx

PropertiesCtx Hdr Command....

Trans Hdr

Action Action....

....Descriptor Descriptor Figure 1-4 H.248 message structure

A message contains multiple transactions that have nothing to do with each other and

can be handled separately; a transaction is composed of several actions and actions

correspond to Contexts; an action constitutes a series of commands restricted by a

Context. In this way, H.248 message mechanism is shown in Figure 1-5.

H.248 message

Transaction1

ContextID1

Command1

Des-1 Des-n

Commandn

ContextIDn

TransactionIDn

H.248 message

Transaction1

ContextID1

Command1

Des-1 Des-n

Commandn

ContextIDn

TransactionIDn

Figure 1-5 Message mechanism

8/3/2019 01-Chapter 1 H

8/19



1-7

I. Message

Information units transmitted or accepted by H.248 are called messages. A message

begins with the Header followed by several transactions.

The message Header contains the Message Identifier (MID) and the Version Number:

The MID identifies the message sender, and may be set to a provisioned name

(for example, domain address/domain name/device name). Domain name is a

suggested default.

The Version Number identifies the version of the protocol the message conforms

to. Versions consist of one or two digits, beginning with version 1 for the present

version of the protocol.

The transactions in a message are treated independently. There is no order implied.

II. Transaction

Commands between the MGC and the MG are grouped into Transactions, each of

which is identified by a TransactionID. Transactions consist of one or more Actions. An

Action consists of a series of Commands that are limited to operating within a single

Context.A Transaction begins with a Transaction Header (TransHdr), in which TransactionID is

contained. TransactionID is assigned by the sender of the Transaction, and it is unique

within the scope of the sender.TransHdr is followed by the Actions of the Transaction. The Actions must be executed

in order. At the first failing command in an Action, processing of the remaining

commands in that Transaction stops except Optional Command. Transactions

guarantee ordered commands processing, which is one significant function to

introduce Transactions.Commands may be marked as Optional which can override this behavior. If a

command marked as Optional results in an error, subsequent commands in the

Transaction will be executed.Transactions include requests and responses, and responses are divided into two

types:.

TransactionRequestEach TransactionRequest requests to activate one Transaction. One Transaction

contains one or more Actions and each Action includes one or more commands related

to one single Context.The structure of TransactionRequest is as follows:

8/3/2019 01-Chapter 1 H

9/19



1-8

TransactionRequest(TransactionId {

ContextID {Command ... Command},

. . .

ContextID {Command ... Command } })

TransactionReplyTransactionReply is a response of the Transaction receiver to the TransactionRequest,

indicating that the receiver completes the executing of the TransactionRequest

command. Every transaction should have its Reply. The following cases indicate the

completion of the executing of a TransactionRequest:

1) All the commands in the TransactionRequest are successfully executed;

2) A non-optional command in the TransactionRequest fails to be executed.

The structure of TransactionReply is as follows:

TransactionReply(TransactionID {

ContextID { Response ...Response },

. . .

ContextID { Response ...Response } })

TransactionPendingThe receiver invokes the TransactionPending. A TransactionPending indicates that the

Transaction is actively being processed, but has not been completed. It is used to

prevent the sender from assuming the TransactionRequest which was lost where the

transaction will take some time to complete.

The structure of TransactionPending is as follows:TransactionPending (TransactionID { } )

Transactions are presented as TransactionRequests. Corresponding response to a

TransactionRequest is received in a single reply, possibly preceded by a number of

TransactionPending messages.

H.248 supports the transactions as shown in Table 1-2:Table 1-2 H.248 transactions

Transaction DescriptionMGWCommunication Up

Message reported by MGW after resumption of MGC-MGWcommunication.

MGW Out OfService

Reported to the MGC when MGW becomes faulty, to indicateMGW to get out of service.

MGW RestorationRestoration message reported by MGW after its recoveryfrom fault.

8/3/2019 01-Chapter 1 H

10/19



1-9

Transaction Description

MGW Register

This function actively sends the Register message to theMGC to request for registration when the whole system is

powered up. Only after successful registration of MGW canthe MGC use the resources on the MGW.MGW Re-Register

In some cases, such as MGC handover, the MGC mayrequest the MGW to register again.

(G)MSC ServerOrderedRe-Register

(G)MSC SERVER requests the MGW to register again, andthe MGW initiates the transaction after it receives thecommand.

(G)MSC ServerRestoration

After recovery of (G)MSC SERVER from fault, (G)MSCSERVER sends this message to the MGW.

Termination Out Of

Service

After a Termination fails, the MGW sends this message to the

MGC so that the MGC will no longer use this resource.

TerminationRestoration

When the Termination recovers from failure, the MGW sendsthis message to notify the MGC to update the resourcestatus.

Audit ValueTo audit the current values of the various attributesrequesting for Termination resources.

Audit CapabilityTo audit the capability set of the various attributes requestingfor Termination resources.

MGW CapabilityChange

In case of change of MGW due to fault or OMC configuration,the MGW uses this transaction to notify the MGC, so that the

MGC will update the capability status of the MGW.

(G)MSC Server OutOf Service

To notify MGW when (G)MSC SERVER becomes faulty.Change ThroughConnection

To change the MODE attribute of Termination. This operationcan be used to control the directions of media flows, includingforward, backward, bi-directional, isolated.

Change FlowDirection

To control the direction of the media flow betweenTerminations by modifying the topology parameter betweenTerminations.

Isolate Bearer

Termination

To isolate one Termination from its media flow relation with

other Terminations, so that it has no media flow relation withany Termination.Join BearerTermination

To add a Termination in an existing CONTEXT.

Establish Bearer To establish bearer between MGWs. This operation includesapplying for a Termination resource and establishing thebearer to the destination MGW.

Prepare BearerTo apply for Termination resource from MGW. This is anoperation prior to bearer. It may result in the generation of anew CONTEXT.

8/3/2019 01-Chapter 1 H

11/19



1-10

Transaction DescriptionActivateInterworking

Function

To activate the IWF on an MGW.

Release BearerTo release bearer between MGWs. This operation does notrelease the Termination resource.

ReleaseTermination

To release Termination resource.Bearer Released

Bearer release completion event reported by MGW. Thisevent is requested by the MGC.

Bearer EstablishedBearer establishment completion event reported by MGW.This event is requested by the MGC.

Send ToneSend-tone operation. During a call, the MGC can request theTermination to send a certain tone to a certain direction, suchas ring-back tone, busy tone, and so on.

PlayAnnouncement

To play announcement in intelligent or supplementaryservices, and so on.

Send DTMF To send DTMF tone.Detect DTMF To request MGW to detect DTMF tones.Report DTMF MGW reports to the MGC about the completion of DTMF tone

detection.Announcement

CompletedAnnouncement playing completion message reported by

MGW.Activate VoiceProcessingFunction

To activate the voice processing function, including EC,Reserve Circuit.

Tunnel InformationUp MGW reports IPBCP frame to the MGC, and the MGC sendsit to the peer MGW by means of tunnel.Tunnel InformationDown The MGC sends the IPBCP message from another MGC toMGW.Tone Completed Tone playing completion event reported by MGW.StopAnnouncement The MGC requests MGW to stop sendingANNOUNCEMENT.Stop Tone The MGC requests MGW to stop sending Tone.Stop DTMF The MGC requests MGW to stop sending DTMF tone.Stop DTMFDetection

The MGC requests MGW to stop DTMF detection.Confirm Char The MGC requests MGW to confirm the reserved resources.

Modify Char The MGC modifies resources previously reserved on MGW.Reserve Char The MGC reserves resources on MGW.

8/3/2019 01-Chapter 1 H

12/19



1-11

Transaction DescriptionBearer Modified Bearer modification completion event.Bearer Modification

Failed Bearer modification failure event.TFO Activation The MGC activates the TFO function of MGW.Optimal Codec andDistant List Notify

MGW reports Codec List of Codec negotiation during TFO.Codec Modify MGW reports Codec modification result.Distant Codec List MGW reports remote Codec negotiation result.Command Rejected

When MGW detects an illegal or inexecutable command fromthe MGC, it returns Command Rejected.

Modify BearerCharacteristics The MGC requests to modify bearer resource.

III. ActionActions are related to Contexts. An action consists of a series of commands that are

limited to operate within one Context. Actions are identified by a ContextID. In an action,

commands should be processed in order.An action begins with the Context header (CtxHdr) in which ContextID is contained to

identify the Context this action corresponds to. ContextID is assigned by the MG and is

unique within the scope of the MG. The MGC shall use the ContextID in all subsequent

transactions relating to that Context.CtxHdr is followed by several commands, and these commands are related to the

Context identified by the ContextID.IV. Command (CMD)

Commands are the major contents in an H.248 message. They control the Context and

Termination attributes. Concretely, it specifies the event reported by the Terminationwhat signals and actions can be imposed on the Termination, as well as the topology

structure of the Context. A command is composed of the command header (CMDHdr)

and command parameters. In H.248, command parameters are grouped into

Descriptors.H.248 defines eight commands, all of which are sent to the MG by the MGC except the

command Notify, which is sent to the MGC by MG. The command ServiceChange

can be sent by either the MG or the MGC.

The meanings of H.248 commands are as follows:

8/3/2019 01-Chapter 1 H

13/19



1-12

Table 1-3 H.248 commandsCommand Sending

direction Meaning

Add MGC?MG

The Add command adds a Termination to aContext. The Add command on the firstTermination in a Context is used to create aContext.

Modify MGC?MGThe Modify command modifies the properties,events and signals of a Termination.

Subtract MGC?MG

The Subtract command disconnects aTermination from its Context and returnsstatistics on the Terminations participation inthe Context. The Subtract command on thelast Termination in a Context deletes the

Context.Move MGC?MG

The Move command atomically moves aTermination to another Context.

AuditValue MGC?MGThe AuditValue command returns the currentstate of properties, events, signals andstatistics of Terminations.

AuditCapabilities MGC?MGThe AuditCapabilities command returns all thepossible values for Termination properties,events and signals allowed by the MG.

Notify MG?MGC

The Notify command allows the MG to inform

the MGC of the occurrence of events in theMG.

ServiceChange MGC?MG

The ServiceChange command allows the MGto notify the MGC that a Termination or groupof Terminations is about to be taken out ofservice or has just been returned to service.ServiceChange is also used by the MG toannounce its availability to an MGC(registration), and to notify the MGC ofimpending or completed restart of the MG. TheMGC may announce a handover to the MG bysending it a ServiceChange command.

V. DescriptorThe parameters to a command are termed Descriptors. A descriptor consists of a name

and a list of items. Some items may have values. Many commands share common

descriptors.

In general, the text format of descriptors is as follows:

8/3/2019 01-Chapter 1 H

14/19



1-13

DescriptorName={ parm = value, parm = value ...... }

H.248 protocol defines 18 types of descriptors, as shown in Table 1-4.Table 1-4 Descriptors

Descriptor Name Description

Modem Identifies modem type and properties

MuxDescribes multiplex type for multimedia Terminations (forexample, H.221, H.223, H.225.0) and Terminations formingthe input mux

Media A list of media stream specifications

TerminationStateProperties of a Termination (which can be defined inpackages) that are not stream specific

StreamA list of remote/local/localcontrol descriptors for a singlestream

LocalContains properties that specify the media flows that the MGreceives from the remote entity

RemoteContains properties that specify the media flows that the MGsends to the remote entity

LocalcontrolContains properties that are of interest between the MGC andthe MG

Events A list of events that the MG is requested to detect and report

EventBufferA list of events, with their parameters if any, that the MG isrequested to detect and buffer when EventBufferControlequals LockStep

SignalsDescribes signals and/or actions to be applied (for example,ringback tone) to the Terminations

Audit Specifies what information is to be audited

ServiceChangeIn ServiceChange, what, why service change occurred, andso on

DigitMap A dialing plan resident in the MG used for detecting andreporting digit events received on a Termination

StatisticsIn Subtract and Audit, Report of Statistics kept on aTermination

PackagesA AuditValue, returns a list of packages realized byTermination

ObservedEvents In Notify or AuditValue, report of events observed

TopologySpecifies flow directions between Terminations in a Context,and applies to a Context instead of a Termination

8/3/2019 01-Chapter 1 H

15/19



1-14

1.3 Signaling ProceduresThe following part uses an example to describe a typical implementation of H.248. The

diagrams of the call procedure abstractly display the interaction between an MG andthe MGC instead of taking issues like time graduation into account.The example is about a call setup between two residential gateways. User A and User

B are respectively connected to two residential gateways: RGW 1 and RGW 2, and the

gateways are under the control of the same MGC. The example only describes a

successful call, and it is assumed that the gateways have registered on the MGC.The procedure is divided into two processes, namely call setup process and call

backout process.I. Call Setup Process

H.248 call setup process is shown in Figure 1-6.

8/3/2019 01-Chapter 1 H

16/19



1-15

RGW1

MGCRGW

2USER

AUSER

B

Modify RespModify Resp

UserAoffhook

Nodify Resp

Modify SG:dialtoneED:al/on,dd/ce{Dmap1}DM:Dmap1 = 2XXX

Notify offhook

Dial Tone

Modify Resp

UserA dialsdigits

Nodify Resp

Notify digits

Add TermA SD:ringbacktoneAdd $, Local SDP Info -underspecified

RingBackTone

Add Resp TermAAdd Resp EphA Local SDP (Specified)

Add TermB SD:Ring ED:offhookAdd $ Local(Underspecified)

Remote SDP (Specified)

UserB PhoneRinging

Add Resp TermBAdd Resp EphB Local SDP

(Specified)

UserB GoesOffhook

Nodify Resp

Notify offhook

Modify TermA SendRecvModify EphA Remote(Specified) SendRecv

Modify Resp

Modify TermB SendRecvModify EphB SendRecv

Modify Resp

RTP MEDIA

Modify to check offhook

Modify to check offhook

Figure 1-6 Call setup process

8/3/2019 01-Chapter 1 H

17/19



1-16

1) The MGC sends a Modify message to both gateways to detect the offhook event

on the terminations.

2) It is assumed that User A hooks off first. After RGW 1 detects the event, it sends

the MGC a Notify message in which the corresponding event information anddetected timestamp are contained. The MGC returns a response message.

3) The MGC sends a Modify command to RGW 1, indicating that RGW 1 sends dial

tone to User A. RGW sends dial tone to the user and meanwhile returns a

response message.

4) User A hears the dial tone and begins to dial.

5) The MGC receives the Notify message from RGW 1 and begins to analyze the

digits. It is assumed that the called party is connected to RGW 2 which is managed

by the same MGC. The MGC creates a new context for RGW 1 and adds a

physical termination TermA in it. If User B is idle, ringback tone is sent to User A. At

the same time, an ephemeral termination is created and then added in the

preceding context. The connection domain IP address and the media domain port

number of the ephemeral termination are not specified. RGW 1 creates a context

whose ID is 1. The physical termination TermA is added in the context. Meanwhile,

an ephemeral termination EphA is created and its IP address and port number are

assigned. Then, RGW 1 returns a corresponding response in which the IP address

and the port number used are indicated.

6) The MGC sends a similar transaction to RGW 2. RGW 2 creates a context whose

ID is 2, then it adds the physical termination TermB in the context; meanwhile,

RGW 2 creates an ephemeral termination EphB and returns a response message.7) User B hooks off. RGW 2 uses a Notify command requesting to report this event to

the MGC. The MGC also returns a Notify response.

8) The MGC sends RGW 1 a message to stop sending ringback tone to User A, and

sets the remote SDP information of EphA. The mode of both terminations is

modified to SendRecv (previously both created as RecvOnly mode). RGW 1

returns a response message indicating the success of the operation.

9) The MGC sends a transaction to RGW 2, indicating that ringing tone on TermB

should be stopped. After the processing completes, RGW 2 returns a response.

10) The users can have a conversation. Once the call is terminated by either party, the

other party will hear busy tone.

II. Call Backout ProcessCall backout process is shown in Figure 1-7.

8/3/2019 01-Chapter 1 H

18/19



1-17

RGW1

MGCRGW

2USER

AUSER

B

UserA GoesOnHook

Modify TermB SD:BusyTone

UserB GoesOnhook

Nodify Resp

Notify OnHook

BusyTone ToUserB

Modify Resp

Subtract TermA

Subtract EphA

Subtract Resp TermASubtract Resp EphA Statistics

Nodify Resp

Notify OnHook

Subtract TermBSubtract EphB

Subtract Resp TermBSubtract Resp EphB Statistics

Figure 1-7 Call backout process

1) It is assumed that the calling party User A will terminate the call. RGW 1 sends aNotify message to the MGC to report this event. The MGC returns a response

message of the Notify command.

2) The MGC generates a Modify command, indicating that RGW 2 should play busy

tone for User B. The mode of both terminations is set to RecvOnly. RGW 2 returns

a response indicating the success of the operation.

3) The MGC directs RGW 1 to remove both terminations from context 1 and return

the statistics information of the ephemeral termination as the response.

4) User B hears busy tone and then hooks on. RGW 2 reports a Notify message to

the MGC. The MGC returns a corresponding response message.

8/3/2019 01-Chapter 1 H

19/19



1-18

5) The gateway sends a Subtract command to delete TermB and EphB from context

2. RGW 2 also deletes the terminations from context 2 and then returns a

response in which the statistics information of the ephemeral termination is

contained. Here, a call procedure ends. The terminations return to the initial statusand waits for a new call.

01-chapter 1 h

Documents