Call Processing Flow

MG register towards MGC

To make H.248 support the designed service, the first thing it should do after the power up
is to register towards ZXSS10 ss1A/ss1B. Currently the version ZTE supported is 1.0, if the
version in the MG does not match the peer device, there will come back a 406 error “version
not supported” and fails to register. The general registration process is showing below:

FIGURE 1 REGISTRATION PROCESS

Processing flow analysis

 Transaction 1: H.258 send SVC_CHG_REQ message towards ZXSS10 SS1a/SS1 as
following:
（1）MEGACO/1 [10.66.100.12]:2944
（2）T = 3{
（3）C = －{
（4）SC = ROOT {
（5）SV {
（6）MT = RS, RE = 902 }}}
Line (1): MEGACO protocol version number:1. Sent by MG towards MGC, IP address of
MG is [10.66.100.12]，port number is 2944.
Line (2): Transaction ID is 3.
Line (3): Context has not been created, using “-“ indicating it is a null context.
Line (4): servicechange command. Termination ID is Root, indicating this command
affects the entire media gateway.
 Line (5): Descriptors in ServiceChange command.
Line (6): ServiceChange descriptors’ parameter indicating servicechange method is
restart, service change reason is warm boot.
 Transaction 2: ZXSS10 SS1A/SS1B sends response back to MG after receiving the
ServiceChange request as following:
（1）MEGACO/1 [10.66.100.2]:2944
（2）P=3{C= - {SC=ROOT{SV{}}}}
Line (1): MEGACO protocol version number:1. Sent by MG towards MGC, IP address of
MGC is [10.66.100.2]，port number is 2944.
Line (2): Transaction ID is 3, null context, servicechange command affects the entire
media gateway and registration succeeds.

MG Deregister towards MGC

H.248 media gateway quit service, deregistering towards MGC or SS1A/SS1B, the
processing flow is showing below:

FIGURE 2 DEREGISTRATION PROCESS

Processing flow analysis

 Transaction 1: H.258 send SVC_CHG_REQ message towards ZXSS10 SS1a/SS1 as
following:
（1）MEGACO/1 10.66.100.12]:2944
（2）T= 9998
（3）{C= - {
（4）SC = ROOT {
（5）SV {
（6）MT= FO, RE = 905}}}}
Line (1): MEGACO protocol version number:1. Sent by MG towards MGC, IP address of
MG is [10.66.100.12]，port number is 2944.
Line (2): Transaction ID is 9998.
Line (3): Context has not been created, using “-“ indicating it is a null context.
 Line (4): ServiceChange command. Termination ID is Root, indicating this command
affects the entire media gateway.
Line (5): Descriptors in ServiceChange command.
Line (6): ServiceChange descriptors’ parameter indicating servicechange method is
restart, service change reason is Termination taken out of service.
 Transaction 2: ZXSS10 SS1A/SS1B sends response back to MG after receiving the
ServiceChange request as following:
（1）MEGACO/1 [10.66.100.2]:2944
（2）P=9998{C= - {SC=ROOT{ER=505}}}
Line (1): MEGACO protocol version number:1. Sent by MG towards MGC, IP address of
MGC is [10.66.100.2]，port number is 2944.
Line (2): Transaction ID is 9998, null context, servicechange command affects the entire
media gateway error descriptor is 505 indicating media gateway has not registered.

Two IAD subscribers Calling each other in one SS

domain
In I503, there are two kinds of terminations, physical termination and ephemeral
terminations. The Physical termination ranges from AG58900 to AG58902, connecting with
three different subscriber ports respectively. Ephemeral termination name ranges from
RTP/00000 to RTP/00002. Following example shows how the subscribers in two I503 will
make phone call. Following is the simulated example scenarios

FIGURE 3 IAD CALL PROCESSING EXAMPLE SCENARIOS

Processing flow analysis

The simulated call processing flow is showing below:
Figure 4 IAD Call Processing Flow
 Transaction 1: Left-hand side IAD subscriber pick up the phone, MG inform ss1a/ss1b
via NTFY_REQ command, ss1a/ss1b respond this message after receiving the request
NTFY_REQ message includes:
（1）MEGACO/1 [10.66.100.12]:2944
（2）Transaction = 49414
（3）{ Context = -{
（4）Notify = AG58900 {
（5）ObservedEvents = 2000{ 20020403T08131100：al/of }}}
Line (1): MEGACO protocol version number:1. Sent by MG towards MGC, IP address of
MGC is [10.66.100.12]，port number is 2944.
Line (2): Transaction ID is 49414
Line (3): Context has not been created, using “-“ indicating it is a null context.
Line (4): Notify command indicates the affected termination is AG58900
Line (5): Descriptor “ObservedEvents” in Notify command, indicating Event no. is 2000,
al/of indicating a hook off event, and the happening time is year 2002, April 3rd,
8:13:11 in the morning.
NTFY_REPLY includes:
（1）MEGACO/1 [10.66.100.2]:2944
（2）P=49414{
（3）C=-{
（4）N=AG58900}}
 Transaction 2: ss1a/ss1b commands the MG to send dialing tone to the subscriber via
MOD_REQ knowing the fact that the subscriber picked up the phone. And MGC also send
out the dialing regulation Digitalmap to H.248 MG requesting the MG collect the number
strictly according to such plan, in the mean time, detecting the hook up and fork events.
MG receives this command and responses.
MOD_REQ includes:
（1）MEGACO/1 [10.66.100.2]:2944
（2）T=25218{ C=-{
（3）MF=AG58900{
（4）M=DM999264604954{(([2-9]xxxxxx|13xxxxxxxxx|0xxxxxxxxx|9xxxx|1[0124-9]x|
F025xxxxx|FF)},E=2002{dd/ce{ DM=DM999264604954 },al/on,al/fl},SG{cg/dt}}}}
Line (1): MEGACO protocol version number:1. Sent by MG towards MGC, IP address of
MGC is [10.66.100.2]，port number is 2944.
Line (2): Transaction ID is 25218.
Line (3): Modify command, modifying the termination AG58900 properties, event and
signals
Line (4): Digitmap descriptor, sent by SS. ‘[2-9]xxxxx’ indicates that subscriber could
dial any 7-digit number start from [2-9]; ‘9xxxx’ indicates that subscriber could dial any
5-diigit number start with 9; ‘1[0124-9]x’ indicates that subscriber could dial any 3-digit
number, with 1 as its start number, any number except 3 as its second number; MGC
requires MG monitor the following events: 1) collect number according to digitmap,
2)detect all events defined in (al) package.
MOD_REPLY includes:
（1）MEGACO/1 [10.66.100.12]:2944
（2）Reply = 25218 { Context = - {
（3）Modify = AG58900} }
 Transaction 3: subscriber dials the number, IAD collects it, matching with the Digitmap
regulations, sends to MGC if no violations. SS responses towards the message.
NTFY_REQ includes:
（1）MEGACO/1 [10.66.100.12]:2944
（2）Transaction = 49415{Context = -
（3）{ Notify = AG58900{ ObservedEvents = 2002 {20020403T08131500 : dd/ce
{ ds = "F02582325" , (#02582325) Meth = UM } } } } }
Line (1): Line (1): MEGACO protocol version number:1. Sent by MG towards MGC, IP
address of MG is [10.66.100.12]，port number is 2944.
Line (2): Transaction ID is 49415.
Line (3): Notify AG58900 in I503, reporting the event in Digimap. ‘20020403T08131500’
represents 2005, April 3rd, 8:13:15 in the morning. I503 detects Digitmap completion
event with its two parameters: Meth and ds.
Meth could have three possible values:
‘UM”: Entirely Match
‘PM’: Partially Match
‘FM”: Full match
NTFY_REPLY includes:
（1）MEGACO/1 [10.66.100.2]:2944
 （2）Rply=49415{
（3）Context=-{Notify=AG58900}}
 Transaction 4: MGC creates a new context in MG, adding TDM termination and RTP
termination. MG returns ADD_REPLY, analyzing connection and RTP descriptor.
ADD_REQ includes:
（1）MEGACO/1 [10.66.100.2]:2944
（2）Transaction = 10003 {Context = $ {
（3）Add = AG58900,
（4）Add = $ {
（5）Media {Stream = 1 {LocalControl {Mode = ReceiveOnly,nt/jit=40 ; in ms},
（6）Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 4 a=ptime:30}}}}}}
Line (1): MEGACO protocol version number:1. Sent by MG towards MGC, IP address of
MGC is [10.66.100.2]，port number is 2944.
Line (2): Transaction ID is 10003, ‘$’ indicates that MGC requests MG to create a new
context, as for now the context has not yet been created.
Line (3): Add command, putting AG58900 into the new context.
Line (4): ADD command, putting a certain RTP termination into the new context,
indicated by ‘$’ as yet not been created.
Line (5): Media descriptor, stream number is 1, localControl gives the associating
parameters about this media stream. For now AG58900 is under receive only mode,
nt/jtt represents the maximum network jitter rate value is 40 ms.
Line (6): local descriptor, MGC suggests a series of local parameters for RTP
termination. ‘v=0’ represents the SDP version is 0; ‘c=IN IP4 $’ represents the
connection information for RTP termination, representing it’s an IP network, and
unknown Ip address. ‘m=audio $ RTP/AVP 8’ represents RTP termination port
information. ‘audio’ means RTP media type is audio, ‘$’ represents unknown port
number, ‘RTP/AVP’ suggests the transportation protocols, connecting with the ‘c’
address. G.711U = 0；G.726 = 2；G.723，G.7231 = 4；G.711A = 8；G.729，G.729A=
18
ADD_REPLY includes:
（1）MEGACO/1 [10.66.100.12]:2944
（2）Reply = 10003 {
（3）Context=2000 {Add = AG58900,Add=RTP/00000{
（4）Media {
Stream = 1 {
Local {
v=0
c=IN IP4 10.66.100.12
m=audio 2222 RTP/AVP 4
a=ptime:30
a=recvonly}}}}}}
 Line: In the reply message, context has been created, id=2000, the selected
terminations are AG58900 and RTP/00000. MG reports its SDP templates to SS,
including its IP address (c=IN IP4 10.66.100.12), RTP port number and coding schema
(m=audio 2222 RTP/AVP 4) and other info.
 Transaction 5: MGC analysis the number, confirming the calling party status and
parameter
ADD_REQ
（1）MEGACO/1 [10.66.100.2]:2944
（2）Transaction = 50003 {Context = $ {
Add = AG58901 {
（3）Media {Stream = 1 {LocalControl
{Mode=SendReceive} }},
（4）Events={1234{al/of},Signals {al/ri}},
（5）Add = ${
Media {Stream =1
{LocalControl
{Mode=SendReceive,
nt/jit=40 ; in ms}, Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 4
a=ptime:30},
Remote {
v=0
c=IN IP4 10.66.100.12
m=audio 2222 RTP/AVP 4
a=ptime:30} ;}}}}}
Line (1): MEGACO protocol version number:1. Sent by MGC towards MG, IP address of
MGC is [10.66.100.2]，port number is 2944.
Line (2): Transaction ID is 10003, ‘$’ indicates that MGC requests MG to create a new
context, as for now the context has not yet been created.
Line (3): Media descriptor, id is 1. LocalControl is local descriptor, indicating the
parameters. For now, AG58901 is working in receive only mode.
Line (4): event id is 1234, detecting if there is any hook up events, playing ring tone.
Line (5): Add RTP termination in Calling party, media defines the media parameters,
‘mode=sendreceive’ represents the calling party can both receive and send. SS sends
out SDP templates to calling party and let it know about the caller.
ADD_REPLY
（1）MEGACO/1 [10.66.100.13]:2944
Reply = 50003 {
Context = 5000 {
Add = AG58901,
Add = RTP/00001{
 Media {
Stream = 1 {
Local {
v=0
c=IN IP4 10.66.100.13
m=audio 1111 RTP/AVP 4
}} ; }}}}
Line : In this replay message, context has been created, putting AG58901 and
RTP/00001 in it.
 Transaction 6: MGC sends MODIFY to caller, modifying caller termination property and
playing ring back tone. Caller party MG confirms it
MOD_REQ
（1）MEGACO/1 [10.66.100.2]:2944
Transaction = 10005 {
Context = 2000 {
Modify = AG58900 {
Signals {cg/rt}},
Modify = RTP/00000 {
Media {
Stream =1 {Remote {
v=0
c=IN IP4 10.66.100.13
m=audio 1111 RTP/AVP 4}} ;}}}}
MOD_REPLY
（1）MEGACO/1 [10.66.100.12]:2944
Reply = 10005
{ Context = 2000{Modify = AG58900, Modify = RTP/00000}}
 Transaction 7: calling party subscriber picks up the phone, the MG notifies such event to
MGC via NTFY. MGC confirms it.
NTFY_REQ
（1）MEGACO/1 [10.66.100.13]:2944
Transaction = 50005 {Context = 5000 {
Notify = AG58901 {ObservedEvents =1234 {
19990729T22020002:al/of}}}}
NTFY_REPLY
（1）MEGACO/1 [10.66.100.2]:2944
Reply = 50005 {
Context = - {
Notify = AG58901}}
 Transaction 8:MGC modifies the calling party termination property, setup detected
events, stop any signaling tones.
 MOD_REQ
（1）MEGACO/1 [10.66.100.2]:2944
Transaction = 10006 {
Context = 5000 {
Modify = AG58901 {
Events = 1235 {al/on},
Signals { } ; to turn off ringing }}
MOD_REPLY
（1）MEGACO/1 [10.66.100.13]:2944
Reply = 10006 {
Context = 5000
{Modify = AG58901,
Modify = RTP/00001}}
 Transaction 9: MGC modifies caller party termination
MOD_REQ
（1）MEGACO/1 [10.66.100.2]:2944
Transaction = 10006 {
Context = 2000 {
Modify = RTP/00000 {
Media {
Stream = 1 {
LocalControl {
Mode=SendReceive}}}},
Modify = AG58900 {
Signals { }}}}
MOD_REPLY
（ 1 ） MEGACO/1 [10.66.100.12]:2944 ,Reply = 10006 {Context = 2000 {Modify =
RTP/00000,
Modify = AG58900}}