(only applies to ground-start), the media gateway should emulate the
behavior in the case of loop-start in order to allow the Call Agent a
common interface.
3.4. Blocking CAS Trunks
In addition to the above signals and events, there is the "bl"
signal/event which is used for blocking one-way trunks (does not work
for two way trunks) by providing a continuous off-hook.
3.5. Summary of Hook-State Events
The following summarizes the use of the various events that involve
off-hook and on-hook from call establishment to tear-down. This
applies mainly to "MS", "DT", "MD" and to a lesser extent the "DO"
package.
* The "sup" event represents off-hook origination.
* The "sup" signal with parameters provides off-hook with digit
outpulsing on the terminating side.
* Once outpulsing is completed, an "ans" event indicates off-hook
from the termination side (the called party has answered).
* The call agent can then send an "ans" signal (off-hook) to the
originating end to indicate to the caller that the called party
has answered.
* The Call Agent can send a "rel" to either end at any time to tear
down the call (e.g., to abort the call).
* The media gateway can send "rel" to indicate abnormal termination
of the call (with a reason as a parameter).
* However, under normal operation once a call is established, the
Call Agent can expect a "sus" (suspend) event from the termination
end to indicate that the caller went on-hook and a "res" if the
called party goes off-hook again before the Call Agent tears down
the call. The Call Agent can send these same signals to the
originating end to indicate off-hook and on-hook to the calling
party without tearing down the call.
* During normal operation, once the call is established, on-hook
from the calling party (origination side) would result in a "rel"
signal. The Call Agent would then normally send the "rel" signal
to the terminating end to terminate the call. "rel is normally
followed by "rlc" (e.g., media gateway indicates calling party on-
hook with "rel" and the Call Agent responds with "rlc", which
sends on on-hook back to the calling party to indicated release
complete.
The "MO" package is a bit different in that normally only the
terminating side (the operator) can release the call ("rel" event).
The "sus" and "res" are forward signals to the operator indicating
user hook-status.
4.0. Glare Handling
4.1. Glare on MF Bi-directional Wink-start Trunks
Gateways may have a configurable glare bit on a per-DS0 basis that
can be set to indicate whether the gateway is the controlling or
non-controlling "switch". However, in general, PBXs are either pre-
configured or can be configured to behave as non-controlling
switches. In this case if they see an off-hook that exceeds
allowable wink length, they will attach a receiver, go on-hook, and
await digits for a new call. Meanwhile the PBX will retry its
original call on another trunk.
If the gateway behaves like a controlling switch, when glare is
detected, the gateway will wait for up to some timeout value (default
value of 4 seconds) until the incoming off-hook changes to an on-hook
state at which time it will start out-pulsing in the normal manner.
If the timeout occurs before the state change to on-hook occurs, the
gateway will send a release event to the Call Agent (a "rel(44)"
event - cause code indicating glare).
When "rel(44)" is sent by the gateway, that is an indication to the
Call Agent that the call is in the process of being released and that
the Call Agent should give up on that trunk. However, the gateway
may not actually want to send the on-hook at that time in order to
avoid the possibility that the other end takes the on-hook as a wink.
Instead, it may start a second timer and wait some longer period of
time (e.g., 16 seconds or so) before releasing the trunk. If it
receives an on-hook prior the timeout, it completes the release by
going on-hook. If, on the other hand, the timer expires before the
other end goes on-hook, it will simply go on-hook and wait for the
other end to go on-hook. In any case, once both ends have returned
to the on-hook state, an "rlc" event is sent to the Call Agent.
4.2. Glare Handling - Basic PBX Trunks
In order to reduce the chances of glare, the gateway should try a
ringing pre-trip test prior to sending ringing on a basic ground
start trunk. If glare is detected on an outgoing seizure of a basic
PBX trunk, the request for ringing should be "Nacked" (error code 401
- phone off-hook) to the Call Agent.
5.0. Example Call Flows
5.1. PBX to PBX ("MS", "DT, and "BL" packages).
The following call flows involve a single Call Agent that handles
both sides of the call (i.e., the inter-Call-Agent signaling is
ignored). The components involved in the call are:
* The Call Agent (CA)
* The originating Media Gateway (GW-o) and
* The terminating Media Gateway (GW-t)
5.1.1. Call Setup Flows
The following describes some PBX to PBX call. The table gives an
overview of the initial part of the call flow with details to follow.
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| A1 | NTFY[seizure] -> |
| A2 | <- Ack |
| A3 | <- RQNT[request digits] |
| A4 | Ack -> |
| A5 | NTFY[digits] -> |
| A6 | <- Ack |
| B1 | <- CRCX [M:recvonly, LCO] |
| B2 | Ack[SDP1] -> |
| B3 | CRCX [M:sendrecv, LCO, SDP1] -> |
| B4 | <- Ack [SDP2] |
| B5 | <- MDCX [recvonly,SDP2] |
| B6 | Ack -> |
---------------------------------------------------------------------
Step A1 PBX seizure results in a notify to the Call Agent
indicating the start of a call setup:
NTFY 3001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
O: ms/sup (or dt/sup)
In the case of the "BL" package (basic PBX) the interface looks
like a simplified line interface with the standard "hd" event for
off-hook:
NTFY 3001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
O: bl/hd
Another alternative would have been to use an embedded request in the
RQNT that resulted in this notify and combine that request with step
A3. Example - "ms" package:
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
R: ms/sup(E(R(ms/inf, ms/rel))
Step 3 could also be eliminated by the use of "loop" mode e.g.:
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
Q:loop
R: ms/sup, ms/inf, ms/rel
This would result in both notifies occurring without requiring the
RQNT in step A3.
Step A2 The Call Agent sends an Ack:
200 3001 OK
Step A3 The Call Agent requests that digits be collected. The
approach used here depends on the type of PBX interface. For an MF
interface the Call Agent requests that information digits be
collected as follows:
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
R: ms/inf, ms/rel
The Call Agent also asks to be told if the trunk gets released
for some reason ("rel" event) in the process of call setup
(release event may be due to some signaling error for example).
For DTMF trunks (wink-start, immediate start and Basic PBX), the
request is based on a digit map so looks a bit different:
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
R: d/[0-9*#T](D), dt/rel (bl/hd in the case of Basic PBX)
D: (xxxxxxx | x.[T#])
S: dt/dl
Note: the request to signal dial-tone may or may not be here
depending on PBX interface requirement - bl/dl required for
Basic PBX; dt/dl for some Immediate Start interfaces.
Step A4 The gateway responds with an ack:
200 2001 OK
Step A5 Once the digits are collected the gateway notifies the call
agent. In the case of an MF interface, the resulting notify will
look like the following
NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
O: ms/inf(k0,5,5,5,1,2,3,4,s0)
In the case of a DTMF interface (including Basic PBX), it will
look like the following:
NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
O: d/5,d/5,d/5,d/1,d/2,d/3,d/4
Step A6 The Call Agent responds with an ack:
200 3002 OK
Step B1 The Call Agent now requests that a receive-only connection
be made.
CRCX 2002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
C: A7453949499
L: a:PCMU,s:off,e:on
M: recvonly
X: 0123456789B1
R: ms/rel (or dt/rel or bl/hu).
Step B2 The Gateway acks with a connection ID and provides the SDP
information:
200 2002 OK
I: 23474FE
v=0
o=- A7453949499 0 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m= audio 3456 RTP/AVP 0
Step B3 The Call Agent passes this SDP information to the
terminating gateway (GW-t) as part of the connection request:
CRCX 4001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
C: A7453949499
X: 45375840
L: a:PCMU,s:off,e:on
M: sendrecv
v=0
o=- A7453949499 0 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0
Note that the call setup on the terminating trunk can be done with
this CRCX, although in this call flow - it is shown later (step C1).
Step B4 The terminating gateway, responds with an ack and its SDP
information:
200 4001 OK
I: 34738A
v=0
o=- A7453949499 0 IN IP4 47.123.34.33
s=-
c=IN IP4 47.123.34.33
t=0 0
m= audio 3456 RTP/AVP 0
Step B5 Call Agent sends a modify connection request with
connection mode receive-only to the origination gateway and includes
the SDP information with the selected profile from the termination
gateway.
MDCX 2003 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
C: A7453949499
I: 34738A
M: recvonly
v=0
o=- A7453949499 0 IN IP4 47.123.34.33
s=-
c=IN IP4 47.123.34.33
t=0 0
m= audio 3456 RTP/AVP 0
Step B6 The Gateway Acks the modify connection request
200 2003 OK
The following table shows the remainder of the call flow to set up
the call except for Basic PBX (Basic PBX shown in) with details to
follow.
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| C1 | RQNT [S: ms/sup, R: ms/oc, ms/rel, ms/ans] ->|
| C2 | <- Ack |
| C3 | <- NTFY [O:ms/oc(ms/sup)]|
| C4 | Ack -> |
| C5 | <- NTFY [O: ms/ans] |
| C6 | Ack -> |
| C7 | <- MDCX [M:sendrecv, S: ms/ans, R: ms/rel] |
| C8 | Ack -> |
| C9 | RQNT[R: ms/sus] -> |
| C10 | <- Ack |
---------------------------------------------------------------------
Step C1 The Call Agent does a setup request to the terminating
gateway The setup request for an MF PBX interface (wink start or
immediate start) will be the following:
RQNT 4002 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
Q: loop
S: ms/sup(addr(ko,5,5,5,1,2,3,4,s0))
R: ms/oc, ms/rel, ms/ans
Note that the result of the "sup" signal is the following
sequence on the interface to the PBX:
* off-hook -> PBX
* wink -> PBX (for wink-start trunks; for immediate start this
part of the sequence does is not included)
* Digits sent to PBX
For DTMF PBX interface (except Basic PBX), the only difference is
that the MF start and end delimiters (k0 and s0) are not
included:
RQNT 4002 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
Q: loop
S: dt/sup(addr(5,5,5,1,2,3,4))
R: dt/oc, dt/rel, dt/ans
Basic PBX requires ringing and ring-back instead i.e.:
RQNT 4002 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
Q: loop
S: bl/rg,bl/rt@34738A
R: bl/oc,bl/hd
In this case ringback will come from the gateway and will start
immediately with the signal request for rt@connectionID. It will
end as soon as an event occurs (off-hook representing answer
event) In the case of other PBX's, the ringback tone comes from
the PBX so does not have to be generated by the gateway.
Note that these requests could be done as easily at the same time
as the connection request (B3) saving some post-dial delay time.
Step C2 The gateway responds with an ack:
200 4002 OK
Step C3 Except for the basic PBX, case (where digits are not
outpulsed) when the digits have completed being sent out, the gateway
will notify the fact by indicate that the operation is complete.
NTFY 1001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
O: ms/oc(ms/sup) (or dt/oc(dt/sup))
Step C4 The Call Agent acks the notify
200 1001 OK
In the case of the BL package, steps C3 and C4 will not exist.
Step C5 When an answer is obtained from the other end (off-hook
from the PBX), the gateway sends a notify to indicate:
NTFY 1002 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
O: ms/ans (or dt/ans or bl/hd)
Step C6 The Call Agent acks
200 1002 OK
Step C7 The Call Agent now sends a request to make the connection
full duplex and indicates that the other end has answered the phone.
MDCX 2004 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
C: A7453949499
X: 45375842
I: 34738A
M: sendrecv
S: ms/ans ( or dt/ans but S: not included in the case where the
originating gateway uses the BL package)
Step C8 The Gateway acks the request
200 2004 OK
Step C9 The Call Agent sends a notification request to be told
when the trunk to be released.
RQNT 4003 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375842
R: ms/rel,ms/sus (or R: dt/rel,dt/sus or R: bl/hu)
Step C10 The gateway acks the request
200 4003 OK
The call is now setup.
5.1.2. Call Tear-Down
Two cases are included here, one where the origination end initiates
the release (section 5.1.2.1) and one where the termination end
initiates the release (section 5.1.2.2).
5.1.2.1. Origination End Initiates the Release
The following call flow shows an example where the origination end
initiates the release for the "MS" package (similar for "DT"
Package).
--------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|-------------------------------------------------------------------- |
| A1 | NTFY[O: ms/rel] -> |
| A2 | <- Ack |
| A3 | RQNT [S: ms/rel, R: ms/rlc] -> |
| A4 | <- Ack |
| A5 | <- NTFY [O: ms/rlc] |
| A6 | Ack -> |
| A7 | <- DLCX [S: ms/rlc, R: ms/sup] |
| A8 | Ack [perf info] -> |
| A9 | DLCX [R: ms/sup]-> |
| A10 | <- Ack [perf info] |
---------------------------------------------------------------------
The same call flow for the "BL" package is shown below
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| A1 | NTFY[O: bl/hu] -> |
| A2 | <- Ack |
| A3 | RQNT [S: bl/dl, R: bl/hu] -> |
| A4 | <- Ack |
| A5 | <- NTFY [O: bl/hu] |
| A6 | Ack -> |
| A7 | <- DLCX [R: bl/hd] |
| A8 | Ack [perf info] -> |
| A9 | DLCX [R: bl/hd]-> |
| A10 | <- Ack [perf info] |
---------------------------------------------------------------------
Step A1 The originating user goes on-hook resulting in a Notify
from the gateway to indicate that the trunk is being released (reason
indicating normal release)
NTFY 3005 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 45375842
O: ms/rel(0) (or dt/rel(0) or bl/hu)
Step A2 The Call Agent Acks the Notify
200 3005 OK
Step A3 The Call Agent sends a request to release the trunk. (For
all but Basic PBX.)
RQNT 4004 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375843
S: ms/rel (or dt/rel)
R: ms/rlc (or dt/rlc)
For the Basic PBX ("BL" package), dial-tone is played
RQNT 4004 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375843
S: bl/dl
R: bl/hu
Step A4 The Gateways acks the request
200 4004 OK
Step A5 The other end releases the call by going on-hook and a
Notify is sent to the Call Agent to indicate that release is
complete.
NTFY 1004 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375843
O: ms/rlc (or dt/rlc)
In the case of Basic PBX, this is:
NTFY 1004 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0
X: 45375843
O: bl/hu
Step A6 The Call Agent returns an Ack
200 1004 OK
Step A7 The Call Agent sends a delete connection to the originating
gateway with a request to do a release complete (which results in
sending on-hook to the PBX).
DLCX 4005 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0
X: 45375844
I: 34738A
S: ms/rlc (or dt/rlc)
R: ms/sup (or dt/sup)
Or in the case of Basic PBX ("BL" package):
DLCX 4005 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0
X: 45375844
I: 34738A
R: bl/hd
Step A8 The Gateway Acks and provides performance information.
250 4005 OK
P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48
Step A9 The Call Agent sends a DLCX to the terminating gateway.
DLCX 2004 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 0123456789B3
I: 23474FE
R: ms/sup (or dt/sup or bl/hd)
Step A10 The gateway acks with performance information
250 2004 OK
P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48
5.1.2.2. Termination End Initiates the Release
The following call flow gives an example of the terminating end
releasing a call for all but Basic PBX ("MS" package - "DT" package
is similar).
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| A1 | <- NTFY[O: ms/sus] |
| A2 | Ack -> |
| A3 | <- RQNT [S: ms/sus, R: ms/rel ] |
| A4 | Ack -> |
| A5 | RQNT [R: ms/res] -> |
| A6 | <- Ack |
| A7 | NTFY [O: ms/rel] -> |
| A8 | <- Ack |
| A9 | DLCX [S: ms/rel, R: ms/rlc] -> |
| A10 | <- Ack [perf info] |
| A11 | <- Notify [O: ms/rlc] |
| A12 | Ack -> |
| A13 | <- DLCX [S: ms/rlc, R: ms/sup ] |
| A14 | Ack [perf info] -> |
---------------------------------------------------------------------
The following shows the same call flow but for Basic PBX. There is
no equivalent to steps A3-A6 and A11-A12 - so these are not included.
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| A1 | <- NTFY[O: bl/hu] |
| A2 | Ack -> |
| A7 | NTFY [O: bl/hu] -> |
| A8 | <- Ack |
| A9 | DLCX [R: bl/hd] -> |
| A10 | <- Ack [perf info] |
| A13 | <- DLCX [bl/hd] |
| A14 | Ack [perf info] -> |
---------------------------------------------------------------------
Step A1 An on-hook is received from the PBX. In the case of all
but the "BL" package, this results in a notify with event "sus" for
suspend.
Step A2 The Call Agent returns an acknowledge
The Call Agent starts a timer at this point (typically 10
seconds). If an off-hook is received from the PBX connected to
GW-t before the origination side releases, the call is continued
(this would appear as a "res" event or "hd" in the case of Basic
PBX interface). If the origination side goes on-hook or the
timer expires, then the call is torn down.
Note that for Basic PBX (the "BL" package), steps A3 - A6 are
missing (these steps do not exist for basic PBX).
Step A3 A "sus" signal is sent to the originating side resulting in
a on-hook being sent to the originating PBX.
Step A4 GW-o acks the request.
Step A5 The Call Agent sends a request to see off-hook or resume
("res") events.
Note: this depends on whether the Call Agent wants to do
suspend/resume processing. If not, the Call Agent may simply send
"rel" along with DLCX to both ends.
Step A6 GW-t acks the request.
Step A7 An on-hook is received from the originating PBX resulting
in a notify from GW-o with event "rel" ("hu" for Basic PBX
interface).
Step A8 The Call Agent "acks"
Step A9 A delete connection is sent to the terminating gateway with
signal "rel" which results in on-hook being sent to the terminating
PBX (except for basic PBX - where there is no such signal)
Step A10 GW-t acks the DLCX and provides performance information
Steps A11 and A12 do not exist for the basic PBX case.
Step A11 GW-t returns an "rlc" event
Step A12 The Call Agent "acks" the notify
Step A13 A delete connection is sent to the originating side (with
signal "rlc" except in the case of the "BL" package).
Step A14 GW-o returns an "ack" with performance information.
5.2. Example Call Flows - "DO" package
5.2.1. Call Setup Flows
The following describes some PBX to PBX call. The table gives an
overview of the initial part of the call flow with details to follow.
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| A1 | NTFY[O: do/rg] -> |
| A2 | <- Ack |
| B1 | <- CRCX [S: do/hd, R: do/rel, M:recvonly, LCO] |
| B2 | Ack[SDP1] -> |
| B3 | CRCX [M:sendrecv, LCO, SDP1] -> |
| B4 | <- Ack [SDP2] |
| B5 | <- MDCX [recvonly,SDP2] |
| B6 | Ack -> |
| C1 | RQNT [S: do/sup, R: do/oc] -> |
| C2 | <- Ack |
| C3 | <- NTFY [O:do/oc(do/sup)]|
| C4 | Ack -> |
| C5 | <- MDCX [M:sendrecv, R: do/rel] |
| C6 | Ack -> |
| C7 | RQNT[R: do/rel] -> |
| C8 | <- Ack |
---------------------------------------------------------------------
Step A1 PBX rings results in a notify to the Call Agent indicating
the start of a call setup:
NTFY 3001 aaln/0@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
O: do/rg
Step A2 The Call Agent sends an Ack:
Step B1 The Call Agent now requests that a receive-only connection
be made.
If the endpoint is running FXO ground-start, the call would also
request detection of disconnect supervision from the PBX (R:
do/rel) and should send an off-hook (S: do/hd) in response to
ringing.
Step B2 The Gateway acks with a connection ID and provides the SDP
information.
Step B3 The Call Agent passes this SDP information to the
terminating gateway (GW-t) as part of the connection request.
Step B4 The terminating gateway, responds with an ack and its SDP
information.
Step B5 Call Agent sends a modify connection request with
connection mode receive-only to the origination gateway and includes
the SDP information with the selected profile from the termination
gateway.
Step B6 The Gateway Acks the modify connection request
Step C1 The Call Agent does a setup request to the terminating
gateway The setup request will be the following:
RQNT 4002 aaln/0@gw-t.whatever.net MGCP 1.0
X: 45375841
S: do/sup(addr(5,5,5,1,2,3,4))
R: do/oc
Note that the result of the "sup" signal is the following
sequence on the interface to the PBX:
* off-hook -> PBX
* tip-ground <- PBX (for loop-start this step does not apply)
* digits sent to PBX
Step C2 The gateway responds with an ack:
200 4002 OK
Step C3 When the digits have been completely sent out, the gateway
will notify the fact by indicate that the operation is complete.
NTFY 1001 aaln/0@gw-t.whatever.net MGCP 1.0
X: 45375841
O: do/oc(do/sup)
Step C4 The Call Agent acks the notify
200 1001 OK
Step C5 The Call Agent now sends a request to make the connection
full duplex and indicates that the other end has answered the phone.
If the endpoint is running FXO ground-start, the call would also
requests detection of disconnect supervision from the PBX
(R:do/rel)
Step C6 The Gateway acks the request
Step C7 If the endpoint is running FXO ground-start, the Call Agent
sends a notification request to be told when the trunk to be
released (R: do/rel). This step and step C8 are not needed if the
endpoint is running FXO loop-start.
Step C8 The gateway acks the request and the call is now setup.
5.2.2. Call Tear-Down
If the endpoint is running FXO loop-start, the PBX cannot
initiate call release. In this case, call release is always
initiated by the Media Gateway by going onhook. Disconnect
supervision from the PBX is provided only for FXO ground-start.
However, it does not matter whether the origination end or the
termination end initiates the release. The call flows for either
case are the same. Therefore, only the case where the origination
end initiates the release is illustrated in this section.
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| A1 | NTFY[O: do/rel] -> |
| A2 | <- Ack |
| A3 | RQNT [S: do/hu, R: do/rlc] -> |
| A4 | <- Ack |
| A5 | <- NTFY [O: do/rlc] |
| A6 | Ack -> |
| A7 | <- DLCX [S: hu, R: rg] |
| A8 | Ack [perf info] -> |
| A9 | DLCX [R: do/rg]-> |
| A10 | <- Ack [perf info] |
---------------------------------------------------------------------
Step A1 The originating PBX goes on-hook resulting in a Notify from
the gateway to indicate that the trunk is being released (reason
indicating normal release).
NTFY 3005 aaln/0@gw-o.whatever.net MGCP 1.0
X: 45375842
O: do/rel(0)
Step A2 The Call Agent Acks the Notify
200 3005 OK
Step A3 The Call Agent sends a request to release the trunk.
Step A4 The Gateways acks the request
Step A5 PBX at the terminating end releases the call by releasing
tip-ground and a Notify is then sent to the Call Agent to indicate
that release is complete.
Note that there is no ground signal in case of loop-start.
However, this NTFY message is still generated as soon as hu
signal is applied.
Step A6 The Call Agent returns an Ack
Step A7 The Call Agent sends a delete connection to the originating
gateway with a request to go onhook.
Step A8 The Gateway Acks and provides performance information.
Step A9 The Call Agent sends a DLCX to the terminating gateway.
Step A10 The gateway acks with performance information
5.3. Example Call Setup - "MD" Package
The following describes Feature Group D call setup using the "MD"
package. The table gives an overview of the initial part of the call
flow with details to follow.
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| A1 | NTFY[O:md/sup] -> |
| A2 | <- Ack |
| A3 | NTFY[O:md/inf(<id>)] -> |
| A4 | <- Ack |
| A5 | NTFY[O:md/inf(<addr>)] -> |
| A6 | <- Ack |
| B1 | <- CRCX [M:recvonly, LCO, R: md/rel] |
| B2 | Ack[SDP1] -> |
| B3 | CRCX [M:sendrecv, LCO, SDP1] -> |
| B4 | <- Ack [SDP2] |
| B5 | <- MDCX [recvonly,SDP2] |
| B6 | Ack -> |
---------------------------------------------------------------------
The assumption is that prior to the initial "notify", the Call Agent
has sent a request to be informed of "sup" and "inf" events using
quarantine handling "Q: loop".
Step A1 Trunk seizure results in a notify to the Call Agent
indicating the start of a call setup:
NTFY 3001 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/sup
Step A2 The Call Agent sends an Ack.
Step A3 Once the digits for the identification field are collected
the gateway notifies the call agent:
NTFY 3002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/inf(k0,0,0,4,0,8,5,5,5,1,2,3,4,s0)
Step A4 The Call Agent responds with an ack.
Step A5 When the digits are collected for the address field,
another notify is sent:
NTFY 3003 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/inf(k0,5,1,2,5,5,5,4,5,6,7,s0)
Step A6 The Call Agent "acks"
Step B1 Create connection - receive only:
CRCX 2002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
C: A3C47F21456789F1
L: p:10, a:PCMU
M: sendrecv
X: 0123456789B1
R: md/rel
Step B2 The Gateway "acks" the request and provides connection ID
and SDP information.
Step B3 The Call Agent passes this SDP information to the
terminating gateway (GW-t) as part of the connection request.
Step B4 The terminating gateway, responds with an ack and its SDP
information.
Step B5 Call Agent sends a modify connection request with
connection mode receive-only to the origination gateway and includes
the SDP information with the selected profile from the termination
gateway.
Step B6 The Gateway Acks the modify connection request.
In the case of EAIN signaling there is some additional information
provided so that this initial part of the call setup looks slightly
different:
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| A1 | NTFY[O:md/sup] -> |
| A2 | <- Ack |
| A3 | NTFY[O:md/inf(<ca>)] -> |
| A4 | <- Ack |
| A5 | <- RQNT[S:md/cwk, R:md/inf,md/rel] |
| A6 | <- Ack |
| A7 | NTFY[O:md/inf(<id>)] -> |
| A8 | <- Ack |
| A9 | NTFY[O:md/inf(<addr>)] -> |
| A10 | <- Ack |
| B1 | <- CRCX [M:recvonly, LCO, R: md/rel] |
| B2 | Ack[SDP1] -> |
| B3 | CRCX [M:sendrecv, LCO, SDP1] -> |
| B4 | <- Ack [SDP2] |
| B5 | <- MDCX [recvonly,SDP2] |
| B6 | Ack -> |
---------------------------------------------------------------------
The assumption is that prior to the initial "notify", the Call Agent
has sent a request to be informed of "sup" and "inf" events using
quarantine handling "Q: loop".
Step A1 Trunk seizure results in a notify to the Call Agent
indicating the start of a call setup:
NTFY 3001 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/sup
Step A2 The Call Agent sends an Ack
Step A3 The initial digit string contains the country address
field:
NTFY 3002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/inf(k0,1,3,8,9,9,0,0,1,9,s0)
Step A4 The Call Agent responds with an ack
Step A5 The Call Agent does processing on the country address field
and sends a request to initiate further input (sends a continue
wink):
RQNT 2002 ds/*@mgw45.whatever.net MGCP 1.0
X: 0123456789B1
Q: loop
R: md/inf,md/rel
S: md/cwk
Step A6 The Gateway "acks" the request.
Step A7 Once the digits for the identification field are collected
the gateway notifies the call agent:
NTFY 3003 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/inf(k0,0,0,4,0,8,5,5,5,1,2,3,4,s0)
Step A8 The Call Agent responds with an ack
Step A9 When the digits are collected for the address field,
another notify is sent:
NTFY 3004 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/inf(k0,5,1,2,5,5,5,4,5,6,7,s0)
Step A10 The Call Agent "acks"
Step B1 Create connection - receive only:
CRCX 2002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
C: A3C47F21456789F1
L: p:10, a:PCMU
M: sendrecv
X: 0123456789B1
R: md/rel
Step B2 The Gateway "acks" the request and provides connection ID
and SDP information
Step B3 The Call Agent passes this SDP information to the
terminating gateway (GW-t) as part of the connection request.
Step B4 The terminating gateway, responds with an ack and its SDP
information
Step B5 Call Agent sends a modify connection request with
connection mode receive-only to the origination gateway and includes
the SDP information with the selected profile from the termination
gateway.
Step B6 The Gateway Acks the modify connection request
The following table shows the remainder of the call flow to set up
the call for FGD EANA.
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| C1 | RQNT [S:sup, R:md/swk,md/oc, md/rel,md/awk, md/ans] ->|
| C2 | <- Ack |
| C3 | <- NTFY [O:md/swk)] |
| C4 | Ack -> |
| C5 | <- NTFY [O:md/oc(md/sup)]|
| C6 | Ack -> |
| C7 | <- NTFY [O:md/awk)] |
| C8 | Ack -> |
| C9 | <- RQNT[S:md/awk] |
| C10 | Ack -> |
| C11 | <- NTFY [O: md/ans] |
| C12 | Ack -> |
| C13 | <- MDCX [M:sendrecv, S: md/ans, R: md/rel] |
| C14 | Ack -> |
| C15 | RQNT [R: md/sus, md/rel] -> |
| C16 | <- Ack |
---------------------------------------------------------------------
Step C1 The Call Agent does a setup request to the terminating
gateway The setup request for an MF EANA FGD interface will be the
following:
RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
Q: loop
S:
md/sup(ct(nda),addr(k0,5,5,5,5,2,2,1,2,3,4,s0),id(k0,0,5,5,5,1,
2,3,4,s2))
R: md/swk,md/oc,md/rel,md/awk,md/ans
Note that the result of the "sup" signal is the following
sequence on the interface to the PBX:
* off-hook -> SCN
* wink <- SCN
* caller ID digits sent to SCN
* address digits sent to SCN
Step C2 The gateway responds with an ack
Step C3 "Notify" the CA that the start of signaling has occurred
(incoming wink start has occurred) i.e.:
NTFY 3000 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/swk
Step C4 The Call Agent "acks".
Step C5 "Notify" that out-pulsing is complete:
NTFY 3001 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/oc(md/sup)
Step C6 The Call Agent "acks".
Step C7 "Notify" that the acknowledgement wink has been received:
NTFY 3002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/awk
Step C8 The Call Agent "acks".
Step C9 The acknowledge wink is passed to the originating gateway:
RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375842
S: md/awk
R: md/rel
Step C10 GW-o "acks".
Step C11 "Notify" off-hook event (the person at the other end has
answered):
NTFY 3003 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/ans
Step C12 The Call Agent "acks".
Step C13 The Call Agent now sends a request to make the connection
full duplex and indicates that the other end has answered the phone
(S: ans sent)
Step C14 The Gateway acks the request
In the case of FGD EAIN, there is an additional digits string
(country address and/or carrier access code that has to be
included so that step C1 looks like the following in a case where
there is no overlapped sending:
RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
Q: loop
S:md/sup(ct(nta),ca(k0,1,3,8,9,9,0,0,1,0,s0),id(k0,
0,5,5,5,1,2,3,4,s0),addr(ko,0,1,1,3,8,1,2,3,4,7,6,5,s0))
R: md/swk,md/oc,md/rel,md/awk,md/ans
If overlapped sending is done, only the country address and
caller ID digit strings are sent out in step C1:
RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
Q: loop
S:md/sup(ct(nta),ca(k0,1,3,8,9,9,0,0,1,0,s0),id(k0,0,
5,5,5,1,2,3,4,s0))
R: md/swk,md/oc,md/rel,md/ans
Then after these digits go out indicated by event "oc(sup)" in
step C5, and as soon as the Call Agent has the address
information, it sends it out using the "inf" signal:
RQNT 2002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B1
Q: loop
R: md/oc,md/rel,md/awk,md/ans
S: md/inf(ko,0,1,1,3,8,1,2,3,4,7,6,5,s0)
The Call Agent will then get a further "md/oc(md/sup)" event when
these digits have gone out.
Step C15 The Call Agent requests to be told of on-hook ("sus")
events
or abnormal release ("rel") events.
Step C16 The gateway "acks" the request.
5.4. Example Call Setup - "MO" Package
The following describes Feature Group D operator services signaling
call setup (911 call) using the "MO" package. The table gives an
overview of the initial part of the call flow with details to follow.
In this case GW-o is a residential gateway using the line package and
GW-t connects to the E911 tandem.
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| A1 | NTFY[O:hd] -> |
| A2 | <- Ack |
| A3 | <- RQNT S: dl, R: [0-9*#T](D) |
| A4 | Ack -> |
| A5 | NTFY[O: 9,1,1] -> |
| A6 | <- Ack |
| B1 | <- CRCX [M:recvonly, R: hu] |
| B2 | Ack[SDP1] -> |
| B3 | CRCX [M:sendrecv, LCO, SDP1, S: mo/sup] -> |
| B4 | <- Ack [SDP2] |
| B5 | <- NTFY [O: oc(sup)] |
| B6 | Ack -> |
| B5 | <- MDCX [sendrecv,SDP2] |
| B6 | Ack -> |
---------------------------------------------------------------------
Note: the originating side in this case is a line-side gateway.
Step A1 The user goes off-hook:
NTFY 3001 aaln/1@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
O: l/hd
Step A2 The Call Agent sends an Ack:
200 3001 OK
Step A3 The Call Agent sends dial-tone and requests that digits be
collected:
RQNT 2001 aaln/1@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
S: l/dl
R: d/[0-9#*T](D), hu
Step A4 The gateway responds with an ack:
200 2001 OK
Step A5 Once the digits are collected the gateway notifies the Call
Agent. In this case, it is a 911 call
NTFY 3002 aaln/1@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
O: d/9,d/1,d/1
Step A6 The Call Agent responds with an ack:
200 3002 OK
Step B1 The Call Agent now requests that a receive-only connection
be made.
CRCX 2002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
C: A7453949499
L: a:PCMU,s:off,e:on
M: recvonly
X: 0123456789B1
R: l/hu.
Step B2 The Gateway acks with a connection ID and provides the SDP
information:
200 2002 OK
I: 23474FE
v=0
o=- A7453949499 0 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m= audio 3456 RTP/AVP 0
Step B3 The Call Agent passes this SDP information to the
terminating gateway (GW-t) as part of the connection request and does
a call setup request at the same time:
CRCX 4001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
C: A7453949499
X: 45375840
L: a:PCMU,s:off,e:on
M: sendrecv
Q: loop
R: oc, rel, orbk
S: sup(addr(k0,9,1,1,s2),id(k0,0,8,3,4,5,6,7,8,s0))
v=0
o=- A7453949499 0 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0
As a result of this request, the following signaling interactions
will occur between GW-t and the Switched Circuit Network (SCN - in
this case, the E911 tandem):
* Off-hook -> SCN
* Wink <- SCN
* k0,9,1,1,s2 -> SCN
* Off-hook <- SCN
* k0,0,8,3,4,5,6,7,8,s0
Note that off-hook from the SCN is part of the protocol (a
request for the caller ID) and does not provide an indication of
whether the operator answered or not.
Step B4 The terminating gateway, responds with an ack and its SDP
information:
200 4001 OK
I: 34738A
v=0
o=- A7453949499 0 IN IP4 47.123.34.33
s=-
c=IN IP4 47.123.34.33
t=0 0
m= audio 3456 RTP/AVP 0
Step B5 The Call Agent will get a further notify when outpulsing of
all of the digits is complete.
NTFY 3003 aaln/1@gw-o.whatever.net MGCP 1.0
X: 45375840
O: oc(sup)
Step B6 The Call Agent returns an "ack"
200 3003 OK
Step B7 Call Agent sends a modify connection request with
connection mode receive-only to the origination gateway and includes
the SDP information with the selected profile from the termination
gateway.
MDCX 2003 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
C: A7453949499
I: 34738A
M: sendrecv
v=0
o=- A7453949499 0 IN IP4 47.123.34.33
s=-
c=IN IP4 47.123.34.33
t=0 0
m= audio 3456 RTP/AVP 0
Step B8 The Gateway Acks the modify connection request
200 2003 OK
The call is now established between the user and the operator.
Acknowledgements
The source for some these packages are Flemming Andreasen, Wai-Tak
Siu - Cisco Systems, and Don Stanwyck - IP Unity. Special thanks to
Joe Clark, Telcordia Technologies for his CAS interface expertise.
Also thanks to all the reviewers for all their comments, including
but not limited to the following people: Charles Eckel, Cisco
Systems; Jerry Kamitses, Sonus Networks.
References
[1] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett,
"Media Gateway Control Protocol (MGCP) Version 1.0", RFC2705,
October 1999.
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
RFC2327, April 1998.
[3] Bellcore, Compatibility Information for Feature Group D Switched
Access Service, TR-NPL-000258, Issue 1, October 1985.
[4] Bellcore, Interoffice LATA Switching Systems Generic Requirements
(LSSGR): Verification Connections (25-05-0903), TR-TSY-000531,
Issue 2, July 1987.
[5] Bellcore, LSSGR: Signaling for Analog Interfaces, GR-506-CORE,
Issue 1, June 1996.
[6] PacketCableTM PSTN Gateway Call Signaling Protocol Specification,
Pkt-SP-TGCP-I01-991201
Author's Address
Bill Foster
170 West Tasman Dr
San Jose, CA, 95134
Phone: 408-527-8791
EMail: bfoster@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.