01-Chapter 1 H.248

Technical Manual Signaling & Protocols
HUAWEI MSOFTX3000 Mobile SoftSwitch Center Table of Contents

Huawei Technologies Proprietary
i
Table of Contents
Chapter 1 H.248 ............................................................................................................................. 1-1
1.1 Overview............................................................................................................................ 1-1
1.1.1 Definition and Functions of the Mc Interface........................................................... 1-1
1.1.2 H.248 Implementation in CSCN.............................................................................. 1-1
1.1.3 Structure of the Protocol Stack ............................................................................... 1-2
1.2 Introduction of H.248 Protocol ........................................................................................... 1-3
1.2.1 Overview ................................................................................................................. 1-3
1.2.2 Message Structure.................................................................................................. 1-6
1.3 Signaling Procedures....................................................................................................... 1-14

HUAWEI MSOFTX3000 Mobile SoftSwitch Center Chapter 1 H.248

1-1
Chapter 1 H.248
1.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. Hereinafter, both are called H.248 in
this manual.
H.248 is a media gateway control protocol. In a decomposed gateway model, the
H.248 protocol is used for the communication between a media gateway controller
(MGC) and a media gateway (MG), implementing the function of the MGC controlling
MGs. In UMTS, the H.248 protocol is applied on the Mc interface.
1.1.1 Definition and Functions of the Mc Interface
I. Definition of the Mc Interface
The Mc interface is the standard interface between the MSC Server (GMSC Server)
and the MGW. It is H.248 protocol compliant. Aiming at special requirements of 3GPP,
H.248 extended Transaction and Package are defined. The Mc interface is an
additional interface for 3GPP 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 (GMSC Server) controlling the various transmission modes (IP/ATM/TDM)
in the MGW in the call processing procedure, such as terminal property, terminal
connection switching relationship, MGW borne media streams. The Mc interface also
provides the call independent MGW status maintenance and management capability.
1.1.2 H.248 Implementation in CSCN
The H.248 protocol is utilized on the interface between MSOFTX3000 and UMG8900,
namely Mc interface defined in UMTS. See Figure 1-1.

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 Stack
As shown in Figure 1-2, the H.248 protocol 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 architecture.
H.248
SCTP
IP
MAC
L1
(G)MSC Server
Mc
MGW
a) IP based
Mc
MGW
b) ATM based
(G)MSC Server
H.248
H.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 Server
Mc
MGW
a) IP based
Mc
MGW
b) ATM based
(G)MSC Server
H.248
H.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

1-3
1.2 Introduction of H.248 Protocol
1.2.1 Overview
I. Basic Concepts
Media Gateway (MG): The media gateway converts media provided in one type of
network to the format required in another type of network. For example, a MG
could terminate bearer channels from a switched circuit network (for example,,
PCM) and media streams from a packet network (for example,, media streams in
an IP network). This gateway may be capable of processing audio, video and data
alone, and will be capable of full duplex media translations. The MG may also play
some audio/video signals and perform a number of interactive voice response
(IVR) functions, or may perform media conferencing.
Media Gateway Controller (MGC): Controls the parts of the call state that pertain
to connection control for media channels in a MG.
Multipoint Control Unit: An entity that controls the setup and coordination of a
multi-user conference that typically includes processing of audio, video and data.
Stream: Bidirectional media or control flow received/sent by a media gateway as
part of a call or conference.
II. Connection Model
The connection model for the protocol describes the logical entities, or objects, within
the Media Gateway that can be controlled by the Media Gateway Controller. The main
abstractions used in the connection model are Terminations and Contexts. Figure 1-3
illustrates the connection model:
Termination
SCN Bearer Channel
Termination
SCN Bearer Channel
Termination
RTP Stream
Context
Context
Context
Media Gateway
Null Context
*
Termination
SCN Bearer Channel
Termination
SCN Bearer Channel
Termination
RTP Stream
*
Termination
RTP Stream
*
Context

Figure 1-3 Example of H.248/MEGACO connection model

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) Context
A 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 a MG property.
The attributes of Contexts are:
ContextID: Context identifier, 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 media gateway.
Priority: The priority is used for a Context in order to provide the MG with
information about a certain precedence handling for a Context. 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) Termination
A Termination is a logical entity on a MG that sources and/or sinks media and/or control
streams. A Termination is described by a number of characterizing properties, 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.

1-5
Usually Terminations are grouped into two classes: semi-permanent Terminations and
ephemeral Terminations. Terminations representing physical entities have a
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 usually
exist 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 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 in
a 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 Media Gateway Controller as command initiator in controlling
Media Gateways as command responders. The exceptions are the Notify and
ServiceChange commands: Notify is sent from Media Gateway to Media Gateway
Controller, 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-6
1.2.2 Message Structure
A message is an information unit sent by the H.248 protocol. A message may be
encoded in a binary format or in a text format.
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.
MGCs should support both encoding formats. MGs may support one of or both formats.
Any H.248 message shares the same structure as shown in Figure 1-4.
Megaco/H.248 message
Trans Hdr
Req or
Reply
Req or
Reply
Req or
Reply
Transaction Transaction Transaction
....
Header
Command
Ctx
Properties
Ctx 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.

1-7
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
I. Message
Information units transmitted or accepted by the H.248 protocol 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 Media Gateway Controller and the Media Gateway 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

1-8
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: TransactionReply and TransactionPending.
TransactionRequest
Each 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:
TransactionRequest(TransactionId {
ContextID {Command ... Command},
. . .
ContextID {Command ... Command } })

TransactionReply
TransactionReply 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 } })

TransactionPending
The 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 was lost where the
transaction will take some time to complete.
The structure of TransactionPending is as follows:

1-9
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.
The H.248 protocol supports the transactions as shown in Table 1-2:
Table 1-2 H.248 transactions
Transaction Description
MGW
Communication Up
Message reported by MGW after resumption of MGC-MGW
communication.
MGW Out Of
Service
Reported to MGC when MGW becomes faulty, to indicate
MGW to get out of service.
MGW Restoration
Restoration message reported by MGW after its recovery
from fault.
MGW Register
This function actively sends the Register message to the
MGC to request for registration when the whole system is
powered up. Only after successful registration of MGW can
the MGC use the resources on the MGW.
MGW Re-Register
In some cases, such as MGC handover, MGC may request
the MGW to register again.
(G)MSC Server
Ordered
Re-Register
(G)MSC SERVER requests the MGW to register again, and
the MGW initiates the transaction after it receives the
command.
(G)MSC Server
Restoration
After recovery of (G)MSC SERVER from fault, (G)MSC
SERVER 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.
Termination
Restoration
When the Termination recovers from failure, the MGW sends
this message to notify the MGC to update the resource
status.
Audit Value
To audit the current values of the various attributes
requesting for Termination resources.
Audit Capability
To audit the capability set of the various attributes requesting
for Termination resources.
MGW Capability
Change
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 Out
Of Service
To notify MGW when (G)MSC SERVER becomes faulty.
Change Through
Connection
To change the MODE attribute of Termination. This operation
can be used to control the directions of media flows, including
forward, backward, bi-directional, isolated.

1-10
Change Flow
Direction
To control the direction of the media flow between
Terminations by modifying the topology parameter between
Terminations.
Isolate Bearer
Termination
To isolate one Termination from its media flow relation with
other Terminations, so that it has no media flow relation with
any Termination.
Join Bearer
Termination
To add a Termination in an existing CONTEXT.
Establish Bearer
To establish bearer between MGWs. This operation includes
applying for a Termination resource and establishing the
bearer to the destination MGW.
Prepare Bearer
To apply for Termination resource from MGW. This is an
operation prior to bearer. It may result in the generation of a
new CONTEXT.
Activate
Interworking
Function
To activate the IWF on an MGW.
Release Bearer
To release bearer between MGWs. This operation does not
release the Termination resource.
Release
Termination
To release Termination resource.
Bearer Released
Bearer release completion event reported by MGW. This
event is requested by the MGC.
Bearer Established
Bearer establishment completion event reported by MGW.
This event is requested by the MGC.
Send Tone
Send-tone operation. During a call, the MGC can request the
Termination to send a certain tone to a certain direction, such
as ring-back tone, busy tone, and so on.
Play
Announcement
To play announcement in intelligent or supplementary
services, 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
Completed
Announcement playing completion message reported by
MGW.
Activate Voice
Processing
Function
To activate the voice processing function, including EC,
Reserve Circuit.
Tunnel Information
Up
MGW reports IPBCP frame to MGC, and the MGC sends it to
the peer MGW by means of tunnel.

1-11
Tunnel Information
Down
MGC sends the IPBCP message from another MGC to MGW.
Tone Completed Tone playing completion event reported by MGW.
Stop
Announcement
MGC requests MGW to stop sending ANNOUNCEMENT.
Stop Tone MGC requests MGW to stop sending Tone.
Stop DTMF MGC requests MGW to stop sending DTMF tone.
Stop DTMF
Detection
MGC requests MGW to stop DTMF detection.
Confirm Char MGC requests MGW to confirm the reserved resources.
Modify Char MGC modifies resources previously reserved on MGW.
Reserve Char MGC reserves resources on MGW.
Bearer Modified Bearer modification completion event.
Bearer Modification
Failed
Bearer modification failure event.
TFO Activation MGC activates the TFO function of MGW.
Optimal Codec and
Distant 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 from
the MGC, it returns Command Rejected.
Modify Bearer
Characteristics
MGC requests to modify bearer resource.

III. Action
Actions 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 for
identifying 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 that Context.
CtxHdr is followed by several commands, and these commands are related to the
Context identified by the ContextID.

1-12
IV. Command (CMD)
Commands are the major contents in an H.248 message. They control the Context and
Termination attributes including to specify the event reported by the Termination what
signals and actions can be imposed on the Termination, as well as specifying the
topology structure of the Context. A command is composed of the command header
(CMDHdr) and command parameters. In H.248 protocol, command parameters are
grouped into Descriptors.
H.248 protocol defines eight commands, all of which are sent to MG by MGC
except the command Notify, which is sent to 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:
Table 1-3 H.248 commands
Command
Sending
direction
Meaning
Add MGC?MG
The Add command adds a Termination to a
Context. The Add command on the first
Termination in a Context is used to create a
Context.
Modify MGC?MG
The Modify command modifies the properties,
events and signals of a Termination.
Subtract MGC?MG
The Subtract command disconnects a
Termination from its Context and returns
statistics on the Terminations participation in
the Context. The Subtract command on the
last Termination in a Context deletes the
Context.
Move MGC?MG
The Move command atomically moves a
Termination to another Context.
AuditValue MGC?MG
The AuditValue command returns the current
state of properties, events, signals and
statistics of Terminations.
AuditCapabilities MGC?MG
The AuditCapabilities command returns all the
possible values for Termination properties,
events and signals allowed by the media
gateway.
Notify MG?MGC
The Notify command allows the MG to inform
the MGC of the occurrence of events in the
MG.

1-13
Sending
Command Meaning
direction
ServiceChange MGC?MG
The ServiceChange command allows the MG
to notify the MGC that a Termination or group
of Terminations is about to be taken out of
service or has just been returned to service.
ServiceChange is also used by the MG to
announce its availability to an MGC
(registration), and to notify the MGC of
impending or completed restart of the MG. The
MGC may announce a handover to the MG by
sending it a ServiceChange command.

V. Descriptor
The 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:
DescriptorName=<someID>
{ 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.
Mux
Describes multiplex type for multimedia Terminations (for
example, H.221, H.223, H.225.0) and Terminations forming the
input mux.
Media A list of media stream specifications.
TerminationStat
e
Properties of a Termination (which can be defined in packages)
that are not stream specific.
Stream A list of remote/local/localcontrol descriptors for a single stream.
Local
Contains properties that specify the media flows that the MG
receives from the remote entity.
Remote
Contains properties that specify the media flows that the MG
sends to the remote entity.
Localcontrol
Contains properties that are of interest between the MGC and the
MG.
Events A list of events that the MG is requested to detect and report.

1-14
Descriptor
Name
Description
EventBuffer
A list of events, with their parameters if any, that the MG is
requested to detect and buffer when EventBufferControl equals
LockStep.
Signals
Describes signals and/or actions to be applied (for example,
ringback tone) to the Terminations.
Audit Specifies what information is to be audited.
ServiceChange
In ServiceChange, what, why service change occurred, and so
on.
DigitMap
A dialing plan resident in the MG used for detecting and reporting
digit events received on a Termination.
Statistics In Subtract and Audit, Report of Statistics kept on a Termination.
Packages A AuditValue, returns a list of packages realized by Termination.
ObservedEvent
s
In Notify or AuditValue, report of events observed.
Topology
Specifies flow directions between Terminations in a Context, and
applies to a Context instead of a Termination.

1.3 Signaling Procedures
The following part uses an example to illustrate a typical implementation of the H.248
protocol. The diagrams of the call procedure abstractly display the interaction between
a media gateway and the media gateway controller instead of taking issues like time
graduation into account.
The example is about a call set up between two residential gateways. User A and User
B are respectively connected to two residential gateways RGW1 and RGW2, and the
gateways are under the control of the same media gateway controller. The example
only describes a successful call, and it is assumed that the gateways have registered
on the media gateway controller.
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.

1-15
RGW
1
MGC
RGW
2
USER
A
USER
B
Modify Resp Modify Resp
UserA
offhook
Nodify Resp
Modify SG:dialtone
ED:al/on,dd/ce{Dmap1}
DM:Dmap1 = 2XXX
Notify offhook
Dial Tone
Modify Resp
UserA dials
digits
Nodify Resp
Notify digits
Add TermA SD:ringbacktone
Add $, Local SDP Info -underspecified
RingBack
Tone
Add Resp TermA
Add Resp EphA Local SDP (Specified)
Add TermB SD:Ring ED:offhook
Add $ Local(Underspecified)
Remote SDP (Specified)
UserB Phone
Ringing
Add Resp TermB
Add Resp EphB Local SDP
(Specified)
UserB Goes
Offhook
Nodify Resp
Notify offhook
Modify TermA SendRecv
Modify EphA Remote(Specified) SendRecv
Modify Resp
Modify TermB SendRecv
Modify EphB SendRecv
Modify Resp
RTP MEDIA
Modify to check offhook
Modify to check offhook

Figure 1-6 Call setup process

1-16
1) 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 RGW1 detects the event, it sends to
MGC a Notify message in which the corresponding event information and
detected timestamp are contained. MGC returns a response message.
3) MGC sends a Modify command to RGW1, indicating to RGW1 to send 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) MGC receives the Notify message from RGW1 and begins to analyze the digits. It
is assumed that the called party is connected to RGW2 which is managed by the
same MGC. MGC creates a new context for RGW1 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. RGW1 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, RGW1 returns a corresponding response in which the IP address
and the port number used are indicated.
6) MGC sends a similar transaction to RGW2. RGW2 creates a context whose ID is 2,
then it adds the physical termination TermB in the context; meanwhile, RGW2
creates an ephemeral termination EphB and returns a response message.
7) User B hooks off. RGW2 uses a Notify command requesting to report this event to
MGC. MGC also returns a Notify response.
8) MGC sends to RGW1 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). RGW1
returns a response message indicating the success of the operation.
9) MGC sends a transaction to RGW2, indicating to stop ringing tone on TermB. After
the completion of the processing, RGW2 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 Process
Call backout process is shown in Figure 1-7.

1-17
RGW
1
MGC
RGW
2
USER
A
USER
B
UserA Goes
OnHook
Modify TermB SD:BusyTone
UserB Goes
Onhook
Nodify Resp
Notify OnHook
BusyTone To
UserB
Modify Resp
Subtract TermA
Subtract EphA
Subtract Resp TermA
Subtract Resp EphA Statistics
Nodify Resp
Notify OnHook
Subtract TermB
Subtract EphB
Subtract Resp TermB
Subtract Resp EphB Statistics

Figure 1-7 Call backout process
1) It is assumed that the calling party User A will terminate the call. RGW1 sends a
Notify message to MGC to report this event. MGC returns a response message of
the Notify command.
2) MGC generates a Modify command, indicating to RGW2 to play busy tone to User
B. The mode of both terminations is set to RecvOnly. RGW2 returns a response
indicating the success of the operation.
3) MGC directs RGW1 to remove both terminations from the context 1 and return the
statistics information of the ephemeral termination as the response.
4) User B hears busy tone and then hooks on. RGW2 reports a Notify message to
MGC. MGC returns a corresponding response message.

1-18
5) The gateway sends a Subtract command to delete TermB and EphB from the
context 2. RGW2 also deletes the terminations from the 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 status
and await a new call.

01-Chapter 1 H.248

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

01-Chapter 1 H.248

Uploaded by

Copyright:

Available Formats

Technical Manual Signaling & Protocols

HUAWEI MSOFTX3000 Mobile SoftSwitch Center Table of Contents

You might also like