RFC 3064
MGCP CAS Packages
RFC 3064: MGCP CAS Packages 🎀 (part 1 of 10)
Okay bestie, let's get into RFC 3064 ✨ It's called "MGCP CAS Packages," it was written by B. Foster from Cisco Systems, and it dropped in February 2001 in the Network Working Group's Request for Comments series. Its category is Informational, so it's giving "here's some info for the community," not an Internet standard 💅 The header doesn't list anything it obsoletes or updates, so it's a solo act 🦋
Status of This Memo
Ngl, the official vibe is that this memo provides information for the Internet community 💖 It does not specify an Internet standard of any kind. Distribution is unlimited, so share it with everyone 🌸
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. 🔒✨
Abstract
Okay so this doc is a collection of media gateway Channel Associated Signaling (CAS) packages for R1 CAS, North American CAS, CAS PBX interconnect as well as basic FXO support. There are six packages in total 👑
The "MS" package covers MF single stage dialing trunks. That includes wink start and immediate start PBX DID/DOD trunks, plus basic R1 and Feature Group D (FGD) Terminating protocol [3]. The "DT "package covers immediate start and basic DTMF and dial-pulse trunks, and the "BL" package covers the interface to a basic PBX (digital or FXS interface). 🌈
Besides the Terminating protocol, there are three other FGD protocols described in [3]. These include EAIN and EANA, which are covered by the enclosed "MD" package, and the Operator Service Signaling protocol, which is handled by the "MO" package. Support for basic FXO interconnect is provided by "DO" package 🧚
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. These are the official requirement words, so they matter a lot 🫶
IESG Note
Heads up, this one's important 🙈
This document is being published for the information of the community. It describes a protocol that is currently being deployed in a number of products. Implementers should be aware of developments in the IETF Megaco Working Group and ITU SG16, who are currently working on a potential successor to this protocol 💜
Table of Contents
1.0.Introduction ................................................ 3
1.1. Functional Partitioning .................................... 3
1.2. CAS Trunk Types ............................................ 4
1.2.1. "MS" Package ............................................. 5
1.2.2. "DT" Package ............................................. 5
1.2.3. "BL" Package ............................................. 6
1.2.4. "DO" Package ............................................. 6
1.2.5. "MD" Package ............................................. 6
1.2.6. "MO" Package ............................................. 7
2.0. Event Packages ............................................. 7
2.1. Events and Signals for the "MS" package .................... 9
2.2. Events and Signals for the "DT" package .................... 10
2.3. Events and Signals for the "BL" package (Basic PBX) ........ 10
2.4. Events and Signals for the "DO" package .................... 11
2.5. Events and Signals for the "MD" package .................... 12
2.6. Events and Signals for the "MO" package .................... 13
2.7. Event and Signal Descriptions .............................. 13
3.0. Hook-State Signals and Events .............................. 23
3.1. Overview of Approach ....................................... 23
3.2. Suspend/Resume Processing .................................. 23
3.3. Control over Disconnect for E911 ........................... 24
3.3. Release and Release Complete ............................... 24
3.4. Blocking CAS Trunks ........................................ 26
3.5. Summary of Hook-State Events ............................... 26
4.0. Glare Handling ............................................. 27
4.1. Glare on MF Bi-directional Wink-start Trunks ............... 27
4.2. Glare Handling - Basic PBX Trunks .......................... 27
5.0. Example Call Flows ......................................... 28
5.1. PBX to PBX ("MS", "DT, and "BL" packages)................... 28
5.1.1. Call Setup Flows ......................................... 28
5.1.2. Call Tear-Down ........................................... 34
5.1.2.1. Origination End Initiates the Release .................. 35
5.1.2.2. Termination End Initiates the Release .................. 38
5.2. Example Call Flows - "DO" package .......................... 40
5.2.1. Call Setup Flows ......................................... 40
5.2.2. Call Tear-Down ........................................... 42
5.3. Example Call Setup - "MD" Package .......................... 44
5.4. Example Call Setup - "MO" Package .......................... 51
Acknowledgements ................................................ 54
References ...................................................... 55
Author's Address ................................................ 55
Full Copyright Statement ........................................ 561.0. Introduction ✨
1.1. Functional Partitioning
There are a number of different possible approaches for partitioning the functional responsibility between the Call Agent and the Media Gateway 🦋
- The Call Agent takes all of the responsibility for the CAS state machine giving the media gateway detailed commands
- The media gateway contains the CAS state machine and provides an abstract interface to the Call Agent
Timing requirements of CAS protocols often involve reacting within time intervals measured in tens of milliseconds, which makes direct control of timing impossible. So the approach used here is to let the media gateway handle low level CAS protocol and timing details wherever possible, and have the Call Agent get involved only whenever higher level processing is required 💅
Taking this approach, the ideal situation would be to allow the Call Agent to treat as many CAS protocols in a similar way, leaving the details to the media gateway. Example: for an incoming MF trunk that involves a single incoming digit string, the Call Agent should not care whether this is a wink start trunk or an immediate start trunk (media gateway should not have to provide the wink-start signal) 🌸
Some goals in partitioning responsibility between the media gateway and media gateway:
- Minimize the number of interactions between the Call Agent and the media gateway.
- The media gateway should not have to do digit analysis (e.g., to determine that the incoming digits contain carrier access information). This is a Call Agent's responsibility.
- Provide some reasonable level of abstraction for the Call Agent so that it can reuse call flows when possible (e.g., Call Agent should not have to differentiate between wink start and immediate start interfaces when only one digit string is involved).
- The media gateway should take care of the CAS protocol (and timeouts) where possible with the Call Agent taking over responsibility where the media gateway leaves off.
Use of Embedded Notifications: Rather than depending on the use of embedded notifications, signals and events were defined that had the specific semantics required. There are two reasons for this:
a) It allows an abstract interface for the Call Agent, so that for example, the same incoming call-setup event can be used in the case of MF wink start and MF immediate start trunks, presenting a common interface to the Call Agent even though the semantics at the CAS state-machine level are slightly different (i.e., in the MF wink start case, a wink-start signal is provided reflexively as a result of an incoming seizure, whereas in the immediate start case, this is not required). 🎀
b) Potential events that might trigger an embedded notification (e.g., the incoming seizure mentioned above) typically needed to be visible to the Call Agent for billing anyway. 💰
This does not say that embedded notifications cannot be used. It simply does not necessitate their use 🧚
Out-pulsing Approach: In order to provide the semantics for outpulsing, special higher level signals (e.g., "sup" for call set-up and "inf" for information) are included that contain the necessary semantics. 📞
Off-hook and On-hook Signals and Events: A higher level view of off-hook and on-hook events is taken in order to make the interface Q.931-like. This provides the advantage that:
- Similar call flows result when dealing with Q.931-based interfaces (e.g., PRI)
- It's more evident (for ease in debug) when looking at message as to exactly what is going on without having to refer to previous events
1.2. CAS Trunk Types
The following describes the types of trunks supported by the various packages. Configuration of the specific trunk type (e.g., wink start versus immediate start) is done within the Media Gateway (MG) via provisioning facilities outside the scope of MGCP. The Call Agent's responsibility is to support the particular package (i.e., in general the Call Agent does not have to differentiate between wink start and immediate start, since those differences are taken care of by the MG). However, the Call Agent needs to know which trunks are incoming, outgoing or bi-directional. 🍓
1.2.1. "MS" Package
The "MS" package is used for PBX DID/DOD trunks as indicated in the following table. It is also used for incoming or outgoing MF wink start trunks (R1 and FGD Terminating protocol [6]). 💖
Table 1 MF PBX Trunks
--------------------------------------------------
| Trunk Type | Direction (w.r.t. the gateway) |
--------------------------------------------------
|MF, wink start |Incoming - originate from PBX |
| |(the same as FGD terminating |
| | protocol) |
|MF, wink start |Outgoing - terminate on PBX |
|MF, wink start |Bi-directional |
|MF, Immediate |Incoming (originate from PBX) |
| start | |
|MF, Immediate |Outgoing (terminate on PBX) |
| start | |
--------------------------------------------------1.2.2. "DT" Package
DTMF and dial-pulse (DP) trunks (except basic PBX) are covered by the "DT" package along with the DTMF "D" package: 🌈
Table 2 DTMF and DP Wink Start and Immediate Start Trunks
--------------------------------------------------
| Trunk Type | Direction (w.r.t. the gateway) |
--------------------------------------------------
|DTMF, Immediate |Incoming (originate from PBX) |
| start, wink | |
| start | |
|DTMF, Immediate |Outgoing (terminate on PBX) |
| start, wink | |
| start | |
--------------------------------------------------1.2.3. "BL" Package ✨
Okay bestie, the "BL" package is for DTMF and dial-pulse (DP) basic PBX trunks 📞🎀. There's also the DTMF "D" package, which is basically a "basic line with no features" 💅. Both of them can run on either a digital or an FXS trunk interface 🌸:
Table 3 Basic FXS Interface
--------------------------------------
| Trunk Type | Direction |
| | (w.r.t. the gateway) |
--------------------------------------
|Basic, DTMF and |Bi-directional |
|DP, Loop Start | |
|Basic, DTMF and |Bi-directional |
|DP, Ground Start| |
--------------------------------------1.2.4. "DO" Package 🦋
The "DO" package is for analog FXO trunks, both loop-start and ground-start 🔌. Here's the lineup:
Table 4 FXO analog PBX Trunks
--------------------------------------
| Trunk Type | Direction |
| | (w.r.t. the gateway) |
--------------------------------------
|FXO, loop-start|Bi-directional |
|FXO, ground- |Bi-directional |
| start | |
--------------------------------------1.2.5. "MD" Package 🌈
The MD package supports North American MF Feature Group D EANA and EAIN [3] 🇺🇸✨. It's giving flexibility, because the Media Gateway can sit at the end office, the carrier, or the tandem side of the circuit 💜. The CAS Signaling Type column in the tables below is there to show signaling differences that both the Call Agent and the Media Gateway care about 🫶. Any config info that only matters to the Media Gateway just isn't listed, so don't go looking for it 🙈.
Table 4 Feature Group D MF Trunks Supported
--------------------------------------------------
| Trunk Type | Direction (w.r.t. the gateway) |
--------------------------------------------------
|FGD, EANA |Outgoing (End Office to Carrier) |
|FGD, EANA |Incoming (Carrier to End Office) |
|FGD, EAIN |Outgoing (End Office to Carrier) |
|FGD, EAIN |Incoming (Carrier to End Office) |
--------------------------------------------------Also, EANA and EAIN signaling can both be requested on the same trunk, call by call 🔥.
1.2.6. "MO" Package 💖
The "MO" package is for FGD Operator Services Signaling, and it only does outgoing trunks 📤. Feature Group C can run over that same interface too 🧚.
2.0. Event Packages 👑
This section is where the event packages live 💅. Quick vocab check: a "signal" is a command the Call Agent sends to the Media Gateway, while an "event" is something the Media Gateway detects and then "Notifies" back to the Call Agent 📣.
Each package has a name, the event name codes, and a definition for every event in it 🍓. Every package table has five columns:
- Code: the package-unique event code for the event or signal 🔢.
- Description: a short description of the event or signal 📝.
- Event: an "x" shows up here if the Call Agent can Request the event. Otherwise you might see one or more of these symbols:
- "P" means the event is persistent 💜.
- "S" means the event is an event-state that can be audited 🔍.
- "C" means the event or signal can be detected or applied on a connection 🎧. For an event, that means it can happen on the media stream. If "C" shows up with a signal in the signal column, that signal can be requested to be sent over a connection.
- Signal: if this column is empty, the Call Agent can't request the event as a signal. If it isn't empty, one of these symbols tells you the signal type:
- "OO" is an On/Off signal. It stays on until the Call Agent turns it off, and the other way around too 🔛.
- "TO" is a Timeout signal. It lasts for a set duration unless a new signal replaces it or an event ends it. Default time-out values are provided, and the provisioning process may change them. A value of zero means the time-out is infinite ♾️.
- "BR" is a Brief signal, with a short, known duration ⚡.
- Additional info: extra details about the event or signal, like the default duration of TO signals 📌.
Now, the "S" audit thing is a big deal, so pay attention 🧐. The point of auditing state ("S") in the packages below is to answer one of two questions:
- Has a call been started on this line or trunk? In the packages below, call setup starts with either a "sup" event or an "hd" event (for the FXS "BL" packages). For the "DO" package (FXO), it starts with the "rg" event instead. Those events have an "S" in the event column, so they're auditable 👀.
- Is the telephony leg of the call idle, so a new call can start? That's shown by the "rlc" (release complete) event-state, for packages that have that event 🧹.
Unless it says otherwise, events and signals are detected or applied on endpoints, and any audio they generate isn't forwarded on any connection the endpoint might have 🤐. Audio generated by events or signals that are detected or applied on a connection gets forwarded on that connection no matter what the connection mode is 🎶.
2.1. Events and Signals for the "MS" package: 💜
These are the codes for the "MS" package events and signals:
Table 5 "MS" Package Events and Signals
---------------------------------------------------------------------
|Code|Description |Event|Signal |Additional Info |
|---------------------------------------------------------------------|
|ans |Call Answer | P | BR | |
| bl |Block | S | BR | |
| bz |Busy tone | - | TO |Time-out = 30 seconds |
|inf |Information Digits| x | - | |
| oc |Operation Complete| x | - | |
| of |Operation Fail | x | - | |
|rel |Release Call | P | BR | |
|res |Resume call | P | BR | |
|rlc |Release complete | P,S | BR | |
| ro |Reorder tone | - | TO |Time-out = 30 seconds |
| rt |Ringback tone | - | TO |Time-out = 180 seconds |
|sup |Call Setup | P,S | TO |Time-out when signal completes |
| | | | |out-pulsing |
|sus |Suspend call | P | BR | |
---------------------------------------------------------------------2.2. Events and Signals for the "DT" package: 🎀
These are the codes for the "DT" package events and signals:
Table 6 "DT" Package Events and Signals
---------------------------------------------------------------------
|Code|Description |Event|Signal |Additional Info |
|---------------------------------------------------------------------|
|ans |Call Answer | P | BR | |
| bl |Block | S | BR | |
| bz |Busy tone | - | TO |Time-out = 30 seconds |
| dl |Dial tone | - | TO |Time-out = 16 seconds |
| oc |Operation Complete| x | - | |
| of |Operation Fail | x | - | |
|rel |Release Call | P | BR | |
|res |Resume call | P | BR | |
|rlc |Release complete | P,S | BR | |
| ro |Reorder tone | - | TO |Time-out = 30 seconds |
| rt |Ringback tone | - | TO |Time-out = 180 seconds |
|sup |Call Setup | P,S | TO |Time-out when signals completed|
| | | | |out-pulsing |
|sus |Suspend call | P | BR | |
---------------------------------------------------------------------2.3. Events and Signals for the "BL" package (Basic PBX) 🌸
This one is basically a simplified line package, so it'll feel familiar ✨. Here are its codes:
Table 7 "BL" Package Events and Signals
---------------------------------------------------------------------
|Code|Description |Event|Signal |Additional Info |
|---------------------------------------------------------------------|
| bz |Busy tone | - | TO |Time-out = 30 seconds |
| dl |Dial tone | - | TO |Time-out = 16 seconds |
| hd |Off-hook | P,S | - | |
| hf |Flash hook | P | - | |
| hu |On-hook | P,S | - | |
| oc |Operation Complete| x | - | |
| of |Operation Fail | x | - | |
| rel|Release | - | BR | |
| rg |Ringing | - | TO |Time-out = 180 seconds |
| ro |Reorder tone | - | TO |Time-out = 30 seconds |
| rt |Ringback tone | - | C,TO |Time-out = 180 seconds |
---------------------------------------------------------------------2.4. Events and Signals for the "DO" package: 🦋
Last but not least, the codes for the "DO" package events and signals 💖:
Table 8 "DO" Package Events and Signals
---------------------------------------------------------------------
|Code|Description |Event|Signal |Additional Info |
|---------------------------------------------------------------------|
| ci |Caller id | x | - | |
| hd |Offhook | - | BR | |
| hf |Hook flash | - | BR | |
| hu |Onhook | - | BR | |
| oc |Operation Complete| x | - | |
| of |Operation Fail | x | - | |
|rel |Release call | P | - | |
| rg |Ringing | P,S | - | |
|rlc |Release complete | P,S | - | |
|sup |Call Setup | - | TO |Time-out when signal completes |
| | | | | out-pulsing |
---------------------------------------------------------------------2.5. Events and Signals for the "MD" package:
okay so the "MD" package has its own list of codes for events and signals, and they're all right here 💅 🎀
Table 9 "MD" Package Events and Signals
---------------------------------------------------------------------
|Code|Description |Event|Signal |Additional Info |
|---------------------------------------------------------------------|
|ans |Call Answer | P | BR | |
|awk |Acknowledge wink | P | BR | |
| bl |Call Block | S | BR | |
| bz |Busy tone | - | TO |Time-out = 30 seconds |
|cwk |Continue Wink | - | BR | |
|inf |Information Digits| x | TO |Time-out when signals completed|
| | | | | out-pulsing |
| oc |Operation Complete| x | - | |
| of |Operation Fail | x | - | |
|rel |Release Call | P | BR | |
|res |Resume call | P | BR | |
|rlc |Release complete | P,S | BR | |
| ro |Reorder tone | - | TO |Time-out = 30 seconds |
| rt |Ringback tone | - | TO |Time-out = 180 seconds |
|sup |Call Setup | P,S | TO |Time-out when signals completed|
| | | | | out-pulsing |
|sus |Suspend call | P | BR | |
|swk |Start Wink | x | - | |
---------------------------------------------------------------------2.6. Events and Signals for the "MO" package:
next up is the "MO" package, which has its own little cast of codes 🧚 🌸
Table 10 "MO" Package Events and Signals
---------------------------------------------------------------------
|Code|Description |Event|Signal |Additional Info |
|---------------------------------------------------------------------|
|ans |Call Answer !Note | P | - | |
| oc |Operation Complete| x | - | |
| of |Operation Fail | x | - | |
|orbk|Operator Ringback | x | - | |
|rbz |Reverse make busy | P,S | - | |
|rcl |Operator Recall | - | BR | |
|rel |Release Call | P | BR | |
|res |Resume Call | - | BR | |
|rlc |Release complete | P,S | BR | |
|sup |Call Setup | - | TO | |
|sus |Suspend Call | - | BR | |
|swk |Start Wink | x | - | |
---------------------------------------------------------------------!Note: There is no indication that the operator answered the call. The "ans" event is an indication that off-hook was received from the far end which simply indicates that the destination address was received properly and the calling number is in the process of being outpulsed.
2.7. Event and Signal Descriptions
here's where we get into what each one actually means 👑 the name goes in parentheses, then the Event + Signal attribute code, then the packages it shows up in
Call answer (ans; P + BR; DT,MD,MS,MO): Off-hook signal normally indicates that the call has been answered and that cut-through has been established. the exception is the "MO" package, where it just means off-hook was received and the calling number is being sent (aka there's no event that tells you the operator answered the call for operator services signaling) 🙈
Acknowledgement Wink (awk; P + BR; MD): this event is only applicable to the "md" package. it gives you an indication that all digits have been received correctly. on an outgoing trunk the event is requested, and when it arrives it means the connecting switch got all of the addressing information. on an originating trunk, this signal goes out to tell the other end that all addressing info has been received. if the Call Agent is doing a transit application, say with incoming and outgoing trunks that are both EANA trunks, then once the acknowledgement wink comes in from the terminating trunk, it gets passed back to the originating side so they know the addressing made it to the destination switch 🦋
Call Block (bl; S + BR; DT,MS,MD): a steady off-hook signal applied to one-way incoming trunks, which says no more calls will be accepted. when "bl" is used as a signal, the "rel" signal is what releases the blocking condition 💅
a Call Agent should only request the "bl" event when it knows this is a one-way outgoing trunk, and it should never see an incoming call-setup request (the "sup" event). so if "bl" is requested as an event, then "sup" gets suppressed as a persistent event 🫶
Busy tone (bz ; - + TO; BL,DT,MD,MS): refer to ITU E.180. the definition of the tone comes from the national characteristics and can be set up through provisioning. Station Busy is defined in GR-506-CORE - LSSGR, SIGNALING, Section 17.2.6. as a combination of two AC tones at 480 and 620 Hertz, each at -24 dBm, for a combined level of -21 dBm. the cadence for Station Busy Tone is 0.5 seconds on, then 0.5 seconds off, repeating 🌈
Caller Id (ci(time, number, name); x + -; DO): see TR-NWT-001188, GR-30-CORE, and TR-NWT-000031. each of the three fields is optional, but the commas will always be included, so no skipping them 🎀
the time parameter is coded as "MM/DD/HH/MM". MM is a two-digit Month between 01 and 12, DD is a two-digit Day between 1 and 31, and Hour and Minute are two-digit values coded according to military local time (so 00 is midnight, 01 is 1 a.m., and 13 is 1 p.m.)
the number parameter is an ASCII string of decimal digits that identify the calling line number. white spaces are allowed if the string is quoted, but they get ignored 🍓
the name parameter is a string of ASCII characters that identify the calling line name. white spaces are allowed if the string is quoted 🌸
a "P" in the number or name field means private, and an "O" means unavailable. here's an example of the caller-id event in action:
O: ci(10/14/17/26, "555 1212", somename)Continue Wink (cwk ; - + BR; MD): this signal is only applicable to the "md" package. it tells you the digits that were sent have been accepted, and more digits need to come in before the call can be processed. for example, with FGD EAIN signaling, this would match sending a wink after the country access code has been received, to say you're ready for the identification and address fields 🧚
Dial-tone (dl ; - + TO; BL,DT): refer to ITU E.180. the definition of the tone comes from the national characteristics and can be set up through provisioning. in GR-506-CORE - LSSGR, SIGNALING, Section 17.2.1, sial Tone is defined as a combination of two continuous AC tones at 350 and 440 Hertz, each at -13dBm, for a combined level of -10 dBm. it's considered an error to try to play dial-tone on a phone that's on hook, so an error should be returned when someone tries that (error code 402 - phone on hook) ⚠️
Information Digits (inf(<inf-digits>); x + TO; MS,MD): on an outgoing call (the "md" package only), this is used as a signal to out-pulse the address information when doing overlapped sending 💖
on an incoming call, it's used as an event to say an MF digit string has been received. in this case, <inf-digits> is all of the digits collected up to and including the digit delimiters ST, ST', ST'', ST'''. multiple sequences of digits that each end with one of the ST digits can be passed in a single "inf" event. (Note that K0 is the same as KP, K1 is sometimes referred to as KP' etc. Similarly S0 is the same as ST, S1 is the same as ST' and so on.
the value of <inf-digits> is a comma separated list of MF digits:
MF1, MF2, ..., MFnwhere each MFi will be one of the following MF digit symbols:
Table 11 MF Digit Symbols
-------------------------
| Symbol |MF digit |
| 0 | MF 0 |
| 1 | MF 1 |
| 2 | MF 2 |
| 3 | MF 3 |
| 4 | MF 4 |
| 5 | MF 5 |
| 6 | MF 6 |
| 7 | MF 7 |
| 8 | MF 8 |
| 9 | MF 9 |
| K0 | MF K0 or KP |
| K1 | MF K1 |
| K2 | MF K2 |
| S0 | MF S0 or ST |
| S1 | MF S1 or ST' |
| S2 | MF S2 or ST'' |
| S3 | MF S3 or ST'''|
--------------------------so an example signal or event could look like:
inf(k0, 5,5,5,1,2,3,4, s0)and if the inter-digit timer expired after the 5,5,5, it would show up like this:
inf(k0, 5,5,5)Operation Complete (oc ; x + -; all): the operation complete event is generated when the gateway was asked to apply one or several TO signals on the endpoint, and one or more of those signals finished without being stopped by a requested or persistent event like setup 🎉 the completion report can carry the name of the signal that reached the end of its live time as a parameter, like this:
O: ms/oc(ms/sup)or
O: bl/oc(bl/rg)when the operation complete event is requested, it can't be parameterized with any event parameters 🙅♀️
and note that when it's requested at the same time as a signal for "sup" (out-pulsing, which is a TO event), the operation complete event will tell you when out-pulsing is done 🌟
Operation failure (of; x + -; all): in general, the operation failure event may be generated when the endpoint was asked to apply one or several TO signals on the endpoint, and one or more of those signals failed before timing out 😭 the completion report may carry the name of the failed signal as a parameter, like this:
O: ms/of(ms/sup)or
O: bl/of(bl/rg)when the operation failure event is requested, it can't be parameterized with any event parameters either 🫶
Operator ringback (orbk; x + -; MO): the description of the MF CAS signaling that results in this event is described in the appendix of TR-NPL-000258 [3]. in brief, it's normally a wink-on signal that may or may not be followed by an MF tone. this event is generated when the operator service requests that the calling party be alerted ("mo" package only) 📞
Reverse make busy (rbz; P + -; MO): this event corresponds to a "blocking" (off-hook) generated by the other end of the one-way operator services trunk ("mo" package). it has the same semantics as the "bl" event in other packages 🔥
Operator recall (rcl; - + BR; MO) 📞 This signal can be used to call the operator back, for example when a customer does a hook-flash to bring the operator back on the line 🎀
Release call (rel; P,S + BR; BL,DT,MD,MO,MS,DO) 💅 A rel signal from the Call Agent to the Media Gateway asks the gateway to release all the resources tied to the telephony leg of the call. This may also cause an off-hook signal to be sent when that makes sense. Once the resources are released, the gateway replies with an rcl event. Releasing the telephony leg does not touch existing connections (network legs), so it's up to the Call Agent to send the right delete connection commands to free any network connections to that endpoint 🦋
For the FXS (BL) package, the rel signal provides a tip-ground release for ground-start trunks. For loop-start trunks, asking to play this signal does nothing ✨
The Media Gateway generates a "release call" event whenever a call is released, either because of an on-hook from the originating end (a normal release) or because of an abnormal event that forced the release. The event can carry one of these cause codes to say why it happened:
Table 12 Release Reason Codes
-----------------------------------------------------------------
|Cause Code |Reason |
|-----------------------------------------------------------------
| 0 |Normal release |
| 44 |Requested channel/circuit not available |
| |(glare or incoming seizure detected during call |
| | setup) |
| 111 |Protocol/signaling error, unspecified (e.g. timeout) |
-----------------------------------------------------------------Okay so, a rel event with reason code 0 (normal release, from an incoming on-hook) will only be notified by a gateway where the call originated. This follows the rule that when the originator hangs up, all resources may be released 🌸 The matching event for an on-hook at the terminating end is the sus event. It only tells you about hook status and doesn't release anything. For the terminating end, it is always up to the Call Agent to release the call by sending the rel signal 💜
For the FXO ground-start case (DO package), the Media Gateway generates a "release call" event whenever a tip-ground release event from the far end releases the call 🌈
Resume call (res ; P + BR; DT,MD,MS,MO) 🧚 This means the called party resumed the call, which is a fancy way of saying the party went off-hook after a previous suspend (sus) but before the originating switch released (rel) the trunk. The sus and res events and signals pass on-hook and off-hook changes without releasing the call's resources ✨ Except for the operator services case (MO package), these events normally travel from the terminating end to the originating end. In other words, they're requested as events from the terminating end and sent to the gateway on the originating side as signals.
Here's the thing though: it's up to the Call Agent whether it wants suspend/resume processing at all. If it doesn't, then when it gets a sup event from the terminating end, it can just tear the call down right away by sending rel and deleting the connections to the endpoints on gateways at both the originating and terminating ends 🙈
For operator services and 911, sus and res are used to pass off-hook and on-hook signals to the operator without releasing any of the call's resources 👑
Ringing (rg; P,S + TO; BL,DO) 🔔 This signal is used for outgoing basic trunks (the bl package). See GR-506-CORE - LSSGR: SIGNALING, Section 14. The provisioning process may define the ringing cadence. Trying to ring a trunk that shows off-hook is an error, so an error should be returned when someone tries that (error code 401 - phone off hook) 😭 In the DO package, rg is instead defined as an event used to indicate that ringing has been detected.
Release complete (rlc;P,S + BR; DO,DT,MD,MO,MS) ✅ The endpoint and Call Agent use the release complete event or signal to confirm that the call has been released and the trunk is free for another call. For FXO ground-start (DO package), this is the release of the tip-ground event from the PBX after the gateway goes on-hook 💖
Reorder tone (ro; - + TO; BL,DT,MD,MS) 🎶 Reorder tone is a combination of two AC tones at frequencies of 480 and 620 Hertz, each at a level of -24 dBm, which gives a combined level of -21 dBm. The cadence is 0.25 seconds on, then 0.25 seconds off, repeating continuously. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.7 🌸
Ring back tone (rt; - + TO; BL,DT,MD,MS) 📣 Audible ring tone is a combination of two AC tones at frequencies of 440 and 480 Hertz, each at a level of -19 dBm, which gives a combined level of -16 dBm. In the US, the cadence for audible ring tone is 2 seconds on, then 4 seconds off. The definition of the tone depends on the national characteristics of the ring-back tone, and it MAY be established via provisioning. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.5 🦋
Call Setup (sup ; P,S + TO; DO,DT,MD,MS,MO) 🚀 This event or signal is used for both outgoing and incoming call setups. Each one gets its own description below.
Outgoing call setup:
On an outgoing trunk, the sup signal seizes the trunk and out-pulses digits. It takes up to four parameters, sup(<ct>, <ca>, <id>, <addr>), depending on the package, and the order of the parameters doesn't matter. The table below shows which parameters are mandatory ("M"), optional ("O") or forbidden ("F") for each package 💅
Table 13 "sup" parameters.
------------------------------------
| Parameter | MS | DT | MO | MD | DO |
|------------------------------------|
| <ct> | F | F | F | M | F |
| <ca> | F | F | F | O | F |
| <id> | F | F | M | M | F |
| <addr> | M | M | M | O | M |
------------------------------------The <ct> parameter has the format ct(<ct-value>), where <ct-value> shows the CAS signaling type. It can be one of two values: "nda" (North American Direct Access) for EANA, or "nta" (North American Tandem Access) for EAIN. This parameter is needed for trunks that handle the MD packages because the same trunk can be used for both 🎀
The <addr> field holds the destination number. When present, it looks like this:
addr(dig1, dig2, ..., dign)The <id> field holds the identification of the caller. When present, it looks like this:
id(dig1, dig2, ..., dign)The <ca> field holds the country address information. When present, it looks like this:
ca(dig1, dig2, ..., dign)When <addr> is present, it's of the form shown above, where digi is an MF symbol (as defined in Table 11) for the MS, MO, and MD packages, and digi is a DTMF symbol (0-9, *, #, A, B, C, D) for the DT and DO packages 🧚
Next up is a table showing some interactions between the Media Gateway (MG) and the Switched Circuit Network (SCN) for single-stage outpulsing applications (DT, MS and DO packages):
Table 14 SCN Sequencing during Call Setup (single stage outpulsing)
------------------------------------------------------------------
|Interface Type |Setup | Interactions |
|------------------------------------------------------------------|
|wink start |sup(add(<addrvalue>)) |MG| off-hook -> |SCN|
| | |MG| <- wink |SCN|
| | |MG| <addrvalue> -> |SCN|
|------------------------------------------------------------------|
|Immediate Start|(sup(addr(<addrvalue>)) |MG| off-hook -> |SCN|
| or FXO) | |MG| <addrvalue> -> |SCN|
------------------------------------------------------------------Call setup signal example for this case (MF signaling):
sup(addr(s0,5,5,5,1,2,3,4,k0))The MO and MD packages involve multi-stage signaling and multiple parameters 🌈 For the MD package, here are some of the interactions:
Table 15 SCN Sequencing during Call Setup (EANA and EAIN)
------------------------------------------------------------------
|Setup | Interactions |
|------------------------------------------------------------------|
| sup(ct(nda),addr(<addrvalue>), |MG| off-hook -> |SCN|
| id(<idvalue>)) |MG| <- wink |SCN|
| |MG| <idvalue> -> |SCN|
| |MG| <addrvalue> -> |SCN|
|------------------------------------------------------------------|
| sup(ct(nta), ca(<cavalue>), |MG| off-hook -> |SCN|
| addr(<addrvalue>), id(<idvalue>)) |MG| <- wink |SCN|
| |MG| <cavalue> -> |SCN|
| |MG| <- wink |SCN|
| |MG| <idvalue> -> |SCN|
| |MG| <addrvalue> -> |SCN|
|------------------------------------------------------------------|
| sup(ct(nta), ca(<cavalue>), |MG| off-hook -> |SCN|
| id(<idvalue>)) |MG| <- wink |SCN|
| |MG| <cavalue> -> |SCN|
| |MG| <- wink |SCN|
| |MG| <idvalue> -> |SCN|
------------------------------------------------------------------The last example is an overlapped sending example, where the address value is sent later using the inf signal. Here's an example setup:
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))In all of the cases above, the ans event means off-hook from the far end, so the other end answered. The operator services signaling (OSS) protocol of Feature Group D is different, though 🙈 Off-hook from the operator is part of that protocol, since it's a request for the calling number. That means ans here does not mean the operator answered, only that the off-hook (the request for the calling number) was received. The table for this is below.
Table 16 SCN Sequencing during Call Setup OSS Protocol ("MO" Package)
------------------------------------------------------------------
|Setup | Interactions |
|------------------------------------------------------------------|
| sup(ct(nda),addr(<addrvalue>), |MG| off-hook -> |SCN|
| id(<idvalue>)) |MG| <- wink |SCN|
| |MG| <- off-hook |SCN|
| |MG| <addrvalue> -> |SCN|
| |MG| <idvalue> -> |SCN|
------------------------------------------------------------------okay so this is the setup moment 💖 an incoming call shows up, and the sup event is how the gateway tells the Call Agent "heyyy, the phone just went off-hook" 📞. no parameters, it arrives bare and iconic ✨
Suspend call (sus; P + BR; DT,MD,MS,MO): bestie, sus is an on-hook event that basically says the called party hung up 🙈. it's not the end of the world though. for interfaces using the "MS", "DT" and "MD" packages, an on-hook from the endpoint at the terminating end of the call gets notified to the Call Agent as a sus event. compare that to a rel event from the originating side, which is a whole different energy 💅
the sus event from the terminating endpoint gives the Call Agent the choice of doing suspend/resume processing or just releasing the call. main character decision-making 👑
the sus signal can send an on-hook to the originating party without releasing the resources tied to the telephony leg of the call 🦋 the rel signal, on the other hand, sends an on-hook AND releases those resources. very different vibes.
because of this, sus can be followed by res (off-hook) so the call can resume 🌈 but rel can't be followed by res, because the call literally doesn't exist anymore 💀
for E911 (the "MO" package), the operator is normally the one in control of releasing the call. so sus (on-hook), res (off-hook) and rcl (flash-hook) can be used to pass the user's hook events along to the operator without releasing the call 🫶
Start Wink (swk; x + - MD,MO): a Call Agent can optionally ask the MG to notify it when the wink start signal happens 🧚 but ngl, wink start (swk) can't be applied by the Call Agent as a signal. the wink-start on an incoming trunk is a reflexive action that doesn't need the Call Agent involved at all 😭
3.0. Hook-State Signals and Events 🌸
3.1. Overview of Approach
okay so, as mentioned in the intro, we take a higher-level view of on-hook and off-hook events for a lot of the CAS packages 🎀 the goal is to make the interface feel Q.931-like, and that's giving main character realness because:
- similar call flows happen as when you're dealing with Q.931-based interfaces (e.g., PRI) ✨
- when you're looking at messages, it's way more obvious (super helpful for debugging 🔍) exactly what's going on without having to flip back to previous flows
this does mean media gateways have to keep some state, but honestly that's a relatively small price to pay 💅
one example is the sup signal, which sends off-hook followed by digits as a high-level signal 📞 the ans event also represents off-hook, but from the terminating end, at the point where the call gets answered 🥂
3.2. Suspend/Resume Processing
so sus (suspend), res (resume) and rel (release) are all based on the idea that one end, the originator, is the one in control of the call 👑 if the controlling end goes on-hook, a rel gets notified to the Call Agent and the call gets released 💔 but if the non-controlling (terminating) end goes on-hook, a sus event happens instead of rel 🙌 that gives the Call Agent the option of doing suspend/resume processing.
if the Call Agent decides NOT to do suspend/resume processing, it can just send rel and delete connection commands to the endpoints after it gets sus from the non-controlling (terminating) end 🧹
if it does want to do suspend/resume processing, it can start a timeout when it receives the sus event from the non-controlling (terminating) end, and keep the call going if a res (off-hook) event shows up 🥰 it can also propagate the sus and res as signals back to the ingress gateway, which gets a chance to release the call (rel event) or not 🦋 either way, sus and res give you another level of control over rel, which sends on-hook AND releases the resources tied to the telephony leg of the call 🌈
3.3. Control over Disconnect for E911
ok so E911 (the "MO" package) is a special case, because the operator (terminating end) is always the controlling end 🚨 the sus and res signals are used to pass user hook state forward to the operator 📲 the rel event gets passed back as a notify to the Call Agent when on-hook is received from the operator, which means the call should be released 💅 if rel is not received, the call should keep staying up ✨
3.3. Release and Release Complete
the rel signal/event generally means on-hook, but it's also giving "release of resources" for the telephony leg of the call 🔥 if a Call Agent sends a rel signal instead of sus, it's asking for the call to be abandoned (aka rel can't be followed by res) 💀
the rel signal does NOT also imply that connections get deleted 🙅♀️ so to fully release the call, including connections, you'd need a DLCX in addition to (or in conjunction with) the rel signal 🧚
on top of being a signal, rel can also be an event triggered by either:
- an on-hook from the controlling end of the call, or
- some abnormal event within the media gateway, so the telephony leg of the call can't be maintained anymore 😵
either way, rel (release) is generally followed by an rlc (release complete) 🎀 the release complete signal/event means the trunk resources are fully released and available for another call ✨ this is also an event state that can be audited, as indicated by the "S" in that event's column, so the Call Agent can check whether that trunk is released and available 🔍
examples of rel and rlc in action 🎬:
- a Call Agent sends a
relto release a trunk, which results in an outgoing off-hook being sent for that trunk 📤 when the media gateway gets the on-hook from the other end, it returns anrlcevent saying the trunk is released and available 🫶 - the media gateway gets an on-hook from the trunk at the controlling end of the call, which results in a
relevent going to the Call Agent 📨 the Call Agent then sends anrlcto the media gateway, which results in on-hook being sent in the opposite direction 🔄 - a
relevent is sent to the Call Agent in the event of some abnormal condition where the media gateway can't sustain the telephony leg of the call (e.g., a glare condition) 😱 the Call Agent sends anrlcto the gateway to finish releasing the call. (note thatrlcmay not correspond to on-hook, but it's generally sent anyway in response to arel.) 🙈 - the Call Agent can send a
rel(instead ofsus) signal to the controlling (originating) end of the call to abandon the call 🚫 the gateway will return withrlconce an off-hook has been received from the other end and all the resources have been released ✅ - a
relcan be sent on a one-way incoming trunk to release a block (bl) that was sent earlier 🔓
the "BL" (FXS) package is a simple line package, so it doesn't have these events. it only uses hd, hf, and hu as its hook state events 🍓
the "DO" (FXO) package, however, DOES have rel and rlc, because in the ground-start case there's the ability to "release" the call as a result of a tip-ground release 🧨 the rel signal is used if the PBX releases the call first (followed by S: hu from the Call Agent to complete the release) 📞 alternatively, the Call Agent can send the S: hu to initiate the release, followed by an rlc event from the media gateway to the Call Agent when the PBX does the tip-ground release 🔁 loop-start trunks wouldn't normally act this way (it only applies to ground-start), but the media gateway should emulate the behavior for loop-start too, so the Call Agent gets a common interface 🫶
3.4. Blocking CAS Trunks
besides all the signals and events above, there's the bl signal/event 🚧 it's used for blocking one-way trunks (it does NOT work for two-way trunks) by providing a continuous off-hook 📵
3.5. Summary of Hook-State Events
okay recap time 📝 this section summarizes the events that involve off-hook and on-hook, from call establishment all the way to tear-down. it mainly applies to "MS", "DT", "MD" and, to a lesser extent, the "DO" package 🎀
- the
supevent represents off-hook origination 📞 - the
supsignal with parameters provides off-hook with digit outpulsing on the terminating side 🔢 - once outpulsing is completed, an
ansevent indicates off-hook from the termination side (the called party has answered) 🥳 - the Call Agent can then send an
anssignal (off-hook) to the originating end to tell the caller the called party has answered 🫶 - the Call Agent can send a
relto either end at any time to tear down the call (e.g., to abort the call) 🛑 - the media gateway can send
relto 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 aresif 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
relsignal 📤 the Call Agent would then normally send therelsignal to the terminating end to terminate the call 🛑relis normally followed byrlc(e.g., the media gateway indicates calling party on-hook withrel, and the Call Agent responds withrlc, which sends on-hook back to the calling party to indicate release complete) 🎀
the "MO" package is a bit different, because 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 ✨
Okay so gateways can have a configurable glare bit on a per-DS0 basis 🎀 that tells the gateway whether it's the controlling or the non-controlling "switch." But honestly, PBXs are usually either preconfigured or configurable to act as non-controlling switches 💅. When one of those sees an off-hook that's longer than the allowable wink length, it attaches a receiver, goes on-hook, and waits for digits for a new call 🦋. Meanwhile, the PBX retries its original call on another trunk 🔁.
If the gateway acts like a controlling switch and detects glare, it waits up to a timeout (4 seconds by default) for the incoming off-hook to change to on-hook 🕰️. Once that happens, it starts out-pulsing like normal 🌸. But if the timeout hits before the on-hook shows up, the gateway sends a release event to the Call Agent: a "rel(44)" event with a cause code indicating glare 😭.
When the gateway sends "rel(44)," it's basically telling the Call Agent that the call is being released and that the Call Agent should give up on that trunk 🙅♀️. The gateway doesn't necessarily send the on-hook right away though, because it doesn't want the other end to mistake that on-hook for a wink 🫣. Instead, it can start a second timer and wait a longer period (around 16 seconds or so) before releasing the trunk 🍓. If an on-hook arrives before that timer runs out, the gateway completes the release by going on-hook too 💜. If the timer expires first, the gateway just goes on-hook and waits for the other end to do the same 🌈. Either way, once both ends are back on-hook, an "rlc" event gets sent to the Call Agent 🎉.
4.2. Glare Handling - Basic PBX Trunks 💖
To lower the chances of glare, the gateway should try a ringing pre-trip test before it sends 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" to the Call Agent, with error code 401 (phone off-hook) 🙅♀️💅.
5.0. Example Call Flows 🍓
5.1. PBX to PBX ("MS", "DT, and "BL" packages). 🌸
Here's where it gets fun 🥳. The following call flows involve a single Call Agent handling both sides of the call, so the inter-Call-Agent signaling gets ignored 🙈. The players are:
- The Call Agent (CA) 👑
- The originating Media Gateway (GW-o) and
- The terminating Media Gateway (GW-t)
5.1.1. Call Setup Flows ✨
Okay so this part walks through a PBX to PBX call 📞. The table gives you the big picture for the start of the call flow, and then we go step by step 🦋.
---------------------------------------------------------------------
| 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 🚨 A PBX seizure triggers a notify to the Call Agent saying a call setup has started 📣:
NTFY 3001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
O: ms/sup (or dt/sup)If you're using the "BL" package (basic PBX), the interface looks more 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/hdThere was also another option: use an embedded request in the RQNT that causes 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 skipped with "loop" mode, like this 🔄:
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
Q:loop
R: ms/sup, ms/inf, ms/relThat results in both notifies happening without needing the RQNT in step A3 🙌.
Step A2 💌 The Call Agent sends an Ack:
200 3001 OKStep A3 🔢 The Call Agent asks for digits to be collected. How it does that depends on the type of PBX interface 🤔. For an MF interface, the Call Agent asks for information digits like this:
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
R: ms/inf, ms/relThe Call Agent also wants to know if the trunk gets released for some reason during call setup (a "rel" event) 😬. That release could come from a signaling error, for example. For DTMF trunks (wink-start, immediate start, and Basic PBX), the request uses a digit map, so it 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/dlNote: 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 OKStep A5 🎯 Once the digits are collected, the gateway notifies the Call Agent. With an MF interface, the notify looks like this:
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)For a DTMF interface (including Basic PBX), it looks like this instead 🎶:
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/4Step A6 ✅ The Call Agent responds with an ack:
200 3002 OKStep B1 🎧 Now the Call Agent asks for a receive-only connection to 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 gives 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 0Step 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 0Heads up 👀: the call setup on the terminating trunk can happen with this CRCX, but in this call flow it shows up later (step C1).
Step B4 💫 The terminating gateway responds with an ack and its own 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 0Step B5 🔄 The Call Agent sends a modify connection request to the originating gateway, setting the connection mode to receive-only and including the SDP information from the terminating gateway's selected profile 🥰:
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 0Step B6 🎀 The Gateway acks the modify connection request:
200 2003 OKThe next table shows the rest of the call flow for setting up the call, except for Basic PBX (which is shown in) 📋. Details come next 💕.
---------------------------------------------------------------------
| 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 |
---------------------------------------------------------------------Okay so Step C1 💖 the Call Agent kicks things off by sending a setup request to the terminating gateway. For an MF PBX interface (wink start or immediate start), it looks like this 👇
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/ansLowkey the result of the "sup" signal is this 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 a 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/ansBasic PBX is the main character here 👑 because it needs ringing and ring-back instead 💅
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/hdSo in this case the ringback comes from the gateway and starts right away with the signal request for rt@connectionID 🔔. It ends as soon as an event happens (an off-hook, which represents the answer event). For other PBXs, the ringback tone comes from the PBX itself, so the gateway doesn't have to generate it 🙌
Also, these requests could honestly be sent at the same time as the connection request (B3), which saves some post-dial delay time ⏱️✨
Step C2 the gateway responds with an ack 🫶
200 4002 OKStep C3 ngl this one is a little bit of a plot twist 🙈 Except for the basic PBX case (where digits are not outpulsed), once the digits have finished going out, the gateway tells the Call Agent 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 OKIn the case of the BL package, steps C3 and C4 will not exist. 🙃
Step C5 when an answer comes back from the other end (off-hook from the PBX), the gateway sends a notify to say so 📞
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 OKStep C7 the Call Agent now sends a request to make the connection full duplex, and it says 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 OKStep C9 the Call Agent sends a notification request so it can be told when the trunk is 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 OKAnd just like that, the call is set up 🎀💖 slay.
5.1.2. Call Tear-Down ✨
Okay so there are two cases in here 🧚. One is where the origination end starts the release (section 5.1.2.1), and the other is where the termination end starts it (section 5.1.2.2). Both are giving main character energy 👑
5.1.2.1. Origination End Initiates the Release 💅
This call flow shows an example where the origination end starts the release for the "MS" package (it's similar for the "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 looks like this 🦋
---------------------------------------------------------------------
| 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 📴, so the gateway sends a Notify saying the trunk is being released (the reason is a 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 OKStep A3 the Call Agent sends a request to release the trunk 🔥 (this is 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 Basic PBX ("BL" package), dial-tone gets played instead 🎶
RQNT 4004 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375843
S: bl/dl
R: bl/huStep A4 the gateway acks the request ✨
200 4004 OKStep A5 the other end releases the call by going on-hook 📴, and a Notify gets sent to the Call Agent to say the 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 Basic PBX case, it's this instead 👇
NTFY 1004 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0
X: 45375843
O: bl/huStep A6 the Call Agent returns an Ack 💖
200 1004 OKStep A7 the Call Agent sends a delete connection to the originating gateway, asking it to do a release complete. This is the bit that actually sends 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, for Basic PBX ("BL" package) 🎀
DLCX 4005 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0
X: 45375844
I: 34738A
R: bl/hdStep A8 the Gateway acks and gives performance info 📊✨
250 4005 OK
P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48Step 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 info 🌈
250 2004 OK
P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=485.1.2.2. Termination End Initiates the Release 🦋
This call flow gives an example of the terminating end releasing a call for all but Basic PBX ("MS" package, and the "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 is when the PBX hangs up on the gateway 📞. Except for the "BL" package, this sends a notify with the event "sus" (suspend) 🌸.
Step A2 is the Call Agent saying "got it" with an Ack 💅.
The Call Agent starts a timer right here, usually around 10 seconds ⏱️. If the PBX on the GW-t side picks up off-hook before the origination side lets go, the call keeps going 🦋. That shows up as a "res" event, or as "hd" if it's a Basic PBX interface. If the origination side hangs up or the timer runs out, the call gets torn down 💀.
Basic PBX (the "BL" package) skips steps A3 through A6, since those steps don't exist for basic PBX 🙈.
Step A3 sends a "sus" signal to the originating side, which makes the originating PBX get an on-hook ✨.
Step A4 is GW-o acking that request 💖.
Step A5 is the Call Agent asking to see an off-hook or a resume ("res") event 🌈.
Note: this depends on whether the Call Agent wants to do suspend/resume processing 🤔. If it doesn't, the Call Agent can just send "rel" together with DLCX to both ends 💜.
Step A6 is GW-t acking that request 🫶.
Step A7 happens when the originating PBX goes on-hook. GW-o then sends a notify with the event "rel" (or "hu" for Basic PBX interface) 🔥.
Step A8 is the Call Agent acking that ✅.
Step A9 sends a delete connection to the terminating gateway with the signal "rel". That makes the terminating PBX go on-hook 🎀. Basic PBX doesn't get this signal, because there isn't one for it 😭.
Step A10 is GW-t acking the DLCX and handing over its performance information 📊.
Steps A11 and A12 don't exist for the basic PBX case 🙃.
Step A11 is GW-t returning an "rlc" event 🍓.
Step A12 is the Call Agent acking the notify 💅.
Step A13 sends a delete connection to the originating side, with the signal "rlc" (except for the "BL" package) 🧚.
Step A14 is GW-o returning an "ack" along with its performance information 🌟.
5.2. Example Call Flows - "DO" package 🎀
5.2.1. Call Setup Flows
Okay so this part walks through a PBX-to-PBX call 📞✨. The table gives you the big-picture overview of the start of the call flow, and then each step gets the full details 💖.
---------------------------------------------------------------------
| 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 is the PBX ringing, which sends a notify to the Call Agent so it knows a call setup is starting 🔔:
NTFY 3001 aaln/0@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
O: do/rgStep A2 is the Call Agent sending an Ack 💅.
Step B1 is the Call Agent asking for a receive-only connection to be made 👂.
If the endpoint is running FXO ground-start, the call also asks to detect disconnect supervision from the PBX (R: do/rel), and it should send an off-hook (S: do/hd) in response to ringing 🔥.
Step B2 is the Gateway acking with a connection ID and giving the SDP information 🌸.
Step B3 is the Call Agent passing that SDP info along to the terminating gateway (GW-t) as part of the connection request 🦋.
Step B4 is the terminating gateway responding with an ack and its own SDP information 💜.
Step B5 is the Call Agent sending a modify connection request to the origination gateway with connection mode receive-only. It includes the SDP information with the selected profile from the termination gateway 🎀.
Step B6 is the Gateway acking that modify connection request ✅.
Step C1 is the Call Agent doing a setup request to the terminating gateway 🧚. The setup request looks like this:
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/ocNote that the result of the "sup" signal is this 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 is the gateway responding with an ack:
200 4002 OKStep C3 happens once the digits have all been sent out. The gateway notifies the fact by indicating 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 is the Call Agent acking the notify 💖:
200 1001 OKStep C5 is the Call Agent sending a request to make the connection full duplex, and indicating that the other end has answered the phone 📞🎉.
If the endpoint is running FXO ground-start, the call also requests detection of disconnect supervision from the PBX (R: do/rel) 🫶.
Step C6 is the Gateway acking that request 💅.
Step C7 applies if the endpoint is running FXO ground-start. The Call Agent sends a notification request so it gets told when the trunk is to be released (R: do/rel) 👑. Steps C7 and C8 aren't needed if the endpoint is running FXO loop-start 🙈.
Step C8 is the gateway acking the request, and now the call is set up 🎊.
5.2.2. Call Tear-Down
Okay so if the endpoint is running FXO loop-start, the PBX cannot start the call release 🙅♀️. The Media Gateway always initiates the release by going onhook instead 📴. Disconnect supervision from the PBX is only provided for FXO ground-start 💀.
It doesn't matter whether the origination end or the termination end starts the release, though. The call flows for either case are the same 🤷♀️. So this section only illustrates the case where the origination end starts the release 🦋.
---------------------------------------------------------------------
| 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 is the originating PBX going on-hook, which makes the gateway send a Notify to say the trunk is being released (with a normal release reason) 📴💜:
NTFY 3005 aaln/0@gw-o.whatever.net MGCP 1.0
X: 45375842
O: do/rel(0)Step A2 is the Call Agent acking the Notify ✅:
200 3005 OKStep A3 is the Call Agent sending a request to release the trunk 🍓.
Step A4 is the Gateway acking that request 🫶.
Step A5 is the PBX at the terminating end releasing the call by releasing tip-ground. A Notify then goes to the Call Agent to say the release is complete 🎀.
Note that there is no ground signal in the case of loop-start 🙃. But this NTFY message still gets generated as soon as the hu signal is applied ✨.
Step A6 is the Call Agent returning an Ack 💅.
Step A7 is the Call Agent sending a delete connection to the originating gateway, asking it to go onhook 🧚.
Step A8 is the Gateway acking and handing over performance information 📊.
Step A9 is the Call Agent sending a DLCX to the terminating gateway 🌸.
Step A10 is the gateway acking 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 |okay bestie 💖 this is the MD package call setup, and it's a whole choreography 💅 Here's the basic version first:
|---------------------------------------------------------------------|
| 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 here is that before the initial "notify" even happens, the Call Agent has already asked to be told about "sup" and "inf" events, using quarantine handling Q: loop ✨
Step A1 🔥 Trunk seizure results in a notify to the Call Agent, which tells it a call setup has started:
NTFY 3001 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/supStep 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 gets 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/relStep B2 The Gateway "acks" the request and hands over a 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 own SDP information.
Step B5 The 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. Slay 👑
In the case of EAIN signaling there's some extra info provided, so this first part of the call setup looks a little different:
|---------------------------------------------------------------------|
| 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 -> |
---------------------------------------------------------------------Same deal as before: the Call Agent has already asked 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/supStep 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 processes the country address field and sends a request to start further input (it sends a continue wink) 🦋
RQNT 2002 ds/*@mgw45.whatever.net MGCP 1.0
X: 0123456789B1
Q: loop
R: md/inf,md/rel
S: md/cwkStep 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/relStep B2 The Gateway "acks" the request and provides a 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 The 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. ✨
Okay, the rest of the call flow, to set up the call for FGD EANA, is in this table 🎀
---------------------------------------------------------------------
| 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 sends a setup request to the terminating gateway. The setup request for an MF EANA FGD interface will look like this:
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/ansNote that the result of the "sup" signal is this 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 The gateway "notifies" the CA that signaling has started, which is when the incoming wink start has happened, like so:
NTFY 3000 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/swkStep C4 The Call Agent "acks".
Step C5 The gateway "notifies" 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 The gateway "notifies" that the acknowledgement wink has been received:
NTFY 3002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/awkStep C8 The Call Agent "acks".
Step C9 The acknowledge wink gets passed along to the originating gateway:
RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375842
S: md/awk
R: md/relStep C10 GW-o "acks". 🌈
Step C11 The gateway "notifies" an off-hook event, which means the person at the other end has answered:
NTFY 3003 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/ansStep 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's an additional digits string (country address and/or carrier access code) that has to be included, so step C1 looks like this when there's 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/ansIf overlapped sending is done, only the country address and caller ID digit strings get 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/ansThen, after these digits go out (indicated by the event oc(sup) in step C5), the Call Agent sends the address information as soon as it has it, 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 another md/oc(md/sup) event once these digits have gone out 🧚
Step C15 The Call Agent requests to be told about on-hook ("sus") events or abnormal release ("rel") events.
Step C16 The gateway "acks" the request.
5.4. Example Call Setup - "MO" Package 🚨
Okay bestie, this one is the 911 call flow using the "MO" package 📞🚨 It's Feature Group D operator services signaling. The table gives you the overview of the first part of the flow, and we'll unpack every step after it 💅 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/hdStep A2 — The Call Agent sends an Ack 🫶
200 3001 OKStep 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), huStep A4 — The gateway responds with an ack 💖
200 2001 OKStep A5 — Once the digits are collected, the gateway notifies the Call Agent. In this case, it's a 911 call 🚨😭
NTFY 3002 aaln/1@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
O: d/9,d/1,d/1Step A6 — The Call Agent responds with an ack 🌈
200 3002 OKStep 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 0Step 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 0As a result of this request, these signaling interactions happen between GW-t and the Switched Circuit Network (SCN, which in this case is the E911 tandem) 🍓
Off-hook -> SCNWink <- SCNk0,9,1,1,s2 -> SCNOff-hook <- SCNk0,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 0Step B5 — The Call Agent gets 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 OKStep B7 — The 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 0Step B8 — The gateway acks the modify connection request 🌸
200 2003 OKAnd just like that, the call is established between the user and the operator 📞🎀✨
Acknowledgements 🫶
The source for some of these packages is 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) and 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", RFC 2705, October 1999.
- [2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, 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.comFull 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 RFC Editor function is currently provided by the Internet Society 💜
📦 where this page comes from
- ietf: rfc3064 2001-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms