followed by a list of parameters enclosed between parenthesis. The
first optional parameter group, identified by the letter "R", is the
enabled value of the RequestedEvents parameter. The second optional
group, identified by the letter "S", is the enabled value of the
SignalRequests parameter. The third optional group, identified by
the letter "D", is the enabled value of the DigitMap. (Note that some
existing implementation may encode these three components in a
different order.)
If the RequestedEvents is not present, the parameter will be set to a
null value. If the SignalRequest is not present, the parameter will
be set to a null value. If the DigitMap is absent, the current value
should be used. The following are valid examples of embedded
requests:
R: hd(E(R([0-9#T](D),hu(N)),S(dl),D([0-9].[#T])))
R: hd(E(R([0-9#T](D),hu(N)),S(dl)))
3.2.2.9. SignalRequests
The SignalRequests parameter provides the name of the signals that
have been requested. Each signal is identified by a name, as
indicated in the previous section.
Several signals, such as for example announcement or ADSI display,
can be qualified by additional parameters:
* the name and parameters of the announcement,
* the string that should be displayed.
These parameters will be encoded as a set of UTF8 character strings,
spearated by comams and enclosed within parenthesis, as in:
S: adsi("123456 Francois Gerard")
S: ann(no-such-number, 1234567)
When several signals are requested, their codes are separated by a
comma, as in:
S: asdi(123456 Your friend), rg
3.2.2.10. ObservedEvent
The observed event parameters provides the list of events that have
been observed. The event codes are the same as those used in the
NotificationRequest. Events that have been accumulated according to
the digit map may be grouped in a single string; they should be
reported as lists of isolated events if other events where detected
during the digit accumulation. Examples of observed actions are:
O: L/hu
O: 8295555T
O: 8,2,9,5,5,L/hf,5,5,T
O: L/hf, L/hf, L/hu
3.2.2.11. RequestedInfo
The RequestedInfo parameter contains a comma separated list of
parameter codes, as defined in the "Parameter lines" section. For
example, if one wants to audit the value of the NotifiedEntity,
RequestIdentifier, RequestedEvents, SignalRequests, DigitMap,
QuarantineHandling and DetectEvents parameters, The value of the
RequestedInfo parameter will be:
F:N,X,R,S,D,Q,T
The capabilities request, in the AuditEndPoint command, is encoded by
the keyword "A", as in:
F:A
3.2.2.12. QuarantineHandling
The quarantine handling parameter contains a list of comma separated
keywords:
* The keyword "process" or "discard" to indicate the treatment of
quarantined events. If neither process or discard is present,
process is assumed.
* The keyword "step" or "loop" to indicate whether exactly at most
one notification is expected, or whether multiple notifications
are allowed. If neither step or loop is present, step is assumed.
The following values are valid examples:
Q:loop
Q:process
Q:discard,loop
3.2.2.13. DetectEvents
The DetectEvent parameter is encoded as a comma separated list of
events, such as for example:
T: hu,hd,hf,[0-9#*]
It should be noted, that no actions can be associated with the
events.
3.2.2.14. EventStates
The EventStates parameter is encoded as a comma separated list of
events, such as for example:
ES: hu
It should be noted, that no actions can be associated with the
events.
3.2.2.15. RestartMethod
The RestartMethod parameter is encoded as one of the keywords
"graceful", "forced", "restart", "disconnected" or "cancel-graceful"
as for example:
RM:restart
3.2.2.16. Bearer Information
The values of the bearer informations are encoded as a comma
separated list of attributes, represented by an attribute name,
separated by a colon from an attribute value.
The only attribute that is defined is the "encoding" (code "e"),
whose defined values are "A" (A-law) and "mu" (mu-law).
An example of bearer information encoding is:
B: e:mu
3.3. Format of response headers
The response header is composed of a response line, optionally
followed by headers that encode the response parameters.
An example of response header could be:
200 1203 OK
The response line starts with the response code, which is a three
digit numeric value. The code is followed by a white space, the
transaction identifier, and an optional commentary preceded by a
white space.
The following table describe the parameters whose presence is
mandatory or optional in a response header, as a function of the
command that triggered the response. The letter M stands for
mandatory, O for optional and F for forbidden.
___________________________________________________________________
| Parameter name | EP| CR| MD| DL| RQ| NT| AU| AU| RS|
| | CF| CX| CX| CX| NT| FY| EP| CX| IP|
|_____________________|____|____|____|____|____|____|____|____|____|
| ResponseAck | F | F | F | F | F | F | F | F | F |
| BearerInformation | F | F | F | F | F | F | O | F | F |
| CallId | F | F | F | F | F | F | F | O | F |
| ConnectionId | F | O*| F | F | F | F | F | F | F |
| RequestIdentifier | F | F | F | F | F | F | O | F | F |
| LocalConnection | F | F | F | F | F | F | O | O | F |
| Options | | | | | | | | | |
| Connection Mode | F | F | F | F | F | F | F | O | F |
| RequestedEvents | F | F | F | F | F | F | O | F | F |
| SignalRequests | F | F | F | F | F | F | O | F | F |
| NotifiedEntity | F | F | F | F | F | F | F | F | O |
| ReasonCode | F | F | F | F | F | F | O | F | F |
| ObservedEvents | F | F | F | F | F | F | O | F | F |
| DigitMap | F | F | F | F | F | F | O | F | F |
| Connection | F | F | F | O | F | F | F | O | F |
| Parameters | | | | | | | | | |
| Specific Endpoint ID| F | O | F | F | F | F | F | F | F |
| RequestedInfo | F | F | F | F | F | F | F | F | F |
| QuarantineHandling | F | F | F | F | F | F | O | F | F |
| DetectEvents | F | F | F | F | F | F | O | F | F |
| EventStates | F | F | F | F | F | F | O | F | F |
| RestartMethod | F | F | F | F | F | F | O | F | F |
| RestartDelay | F | F | F | F | F | F | O | F | F |
| Capabilities | F | F | F | F | F | F | O | F | F |
| SecondConnectionId | F | O | F | F | F | F | F | F | F |
| SecondEndpointID | F | O | F | F | F | F | F | F | F |
|_____________________|____|____|____|____|____|____|____|____|____|
| LocalConnection | F | M | O | F | F | F | F | O*| F |
| Descriptor | | | | | | | | | |
| RemoteConnection | F | F | F | F | F | F | F | O*| F |
| Descriptor | | | | | | | | | |
|_____________________|____|____|____|____|____|____|____|____|____|
In the case of a CreateConnection message, the response line is
followed by a Connection-Id parameter. It may also be followed a
Specific-Endpoint-Id parameter, if the creation request was sent to a
wildcarded Endpoint-Id. The connection-Id parameter is marked as
optional in the Table. In fact, it is mandatory with all positive
responses, when a connection was created, and forbidden when the
response is negative, when no connection as created.
In the case of a DeleteConnection message, the response line is
followed by a Connection Parameters parameter, as defined in section
3.2.2.2.
A LocalConnectionDescriptor should be transmitted with a positive
response (code 200) to a CreateConnection. It may be transmitted in
response to a ModifyConnection command, if the modification resulted
in a modification of the session parameters. The
LocalConnectionDescriptor is encoded as a "session description," as
defined in section 3.4. It is separated from the response header by
an empty line.
When several session descriptors are encoded in the same response,
they are encoded one after each other, separated by an empty line.
This is the case for example when the response to an audit connection
request carries both a local session description and a remote session
description, as in:
200 1203 OK
C: A3C47F21456789F0
N: [128.96.41.12]
L: p:10, a:PCMU;G726-32
M: sendrecv
P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48
v=0
c=IN IP4 128.96.41.1
m=audio 1296 RTP/AVP 0
v=0
c=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
In this example, according to the SDP syntax, each description starts
with a "version" line, (v=...). The local description is always
transmitted before the remote description. If a connection descriptor
is requested, but it does not exist for the connection audited, that
connection descriptor will appear with the SDP protocol version field
only.
3.4. Formal syntax description of the protocol
In this section, we provided a formal description of the protocol
syntax, following the "Augmented BNF for Syntax Specifications"
defined in RFC2234.
MGCPMessage = MGCPCommand / MGCPResponse
MGCPCommand = MGCPCommandLine 0*(MGCPParameter) [EOL *SDPinformation]
MGCPCommandLine = MGCPVerb 1*(WSP) <transaction-id> 1*(WSP)
<endpointName> 1*(WSP) MGCPversion EOL
MGCPVerb = "EPCF" / "CRCX" / "MDCX" / "DLCX" / "RQNT"
/ "NTFY" / "AUEP" / "AUCX" / "RSIP" / extensionVerb
extensionVerb = "X" 3(ALPHA / DIGIT)
transaction-id = 1*9(DIGIT)
endpointName = localEndpointName "@" DomainName
LocalEndpointName = LocalNamePart 0*("/" LocalNamePart)
LocalNamePart = AnyName / AllName / NameString
AnyName = "$"
AllNames = "*"
NameString = 1*(range-of-allowed-characters)
DomainName = 1*256(ALPHA / DIGIT / "." / "-") ; as defined in RFC821
MGCPversion = "MGCP" 1*(WSP) 1*(DIGIT) "." 1*(DIGIT)
[1*(WSP) ProfileName]
ProfileName = 1*(range-of-allowed-characters)
MGCPParameter = ParameterValue EOL
ParameterValue = ("K" ":" 0*WSP <ResponseAck>) /
("B" ":" 0*WSP <BearerInformation>) /
("C" ":" 0*WSP <CallId>) /
("I" ":" 0*WSP <ConnectionId>) /
("N" ":" 0*WSP <NotifiedEntity>) /
("X" ":" 0*WSP <RequestIdentifier>) /
("L" ":" 0*WSP <LocalConnectionOptions>) /
("M" ":" 0*WSP <ConnectionMode>) /
("R" ":" 0*WSP <RequestedEvents>) /
("S" ":" 0*WSP <SignalRequests>) /
("D" ":" 0*WSP <DigitMap>) /
("O" ":" 0*WSP <ObservedEvents>) /
("P" ":" 0*WSP <ConnectionParameters>) /
("E" ":" 0*WSP <ReasonCode>) /
("Z" ":" 0*WSP <SpecificEndpointID>) /
("Z2" ":" 0*WSP <SecondEndpointID>) /
("I2" ":" 0*WSP <SecondConnectionID>) /
("F" ":" 0*WSP <RequestedInfo>) /
("Q" ":" 0*WSP <QuarantineHandling>) /
("T" ":" 0*WSP <DetectEvents>) /
("RM" ":" 0*WSP <RestartMethod>) /
("RD" ":" 0*WSP <RestartDelay>) /
("A" ":" 0*WSP <Capabilities>) /
("ES" ":" 0*WSP <EventStates>) /
(extensionParameter ":" 0*WSP <parameterString>)
ResponseAck = confirmedTransactionIdRange
*[ "," confirmedTransactionIdRange ]
confirmedTransactionIdRange = 1*9DIGIT [ "-" 1*9DIGIT ]
BearerInformation = BearerAttribute 0*("," 0*WSP BearerAttribute)
BearerAttribute = ("e" ":" <BearerEncoding>)
BearerEncoding = "A" / "mu"
CallId = 1*32(HEXDIG)
// The audit request response may include a list of identifiers
ConnectionId = 1*32(HEXDIG) 0*("," 1*32(HEXDIG))
SecondConnectionID = ConnectionId
NotifiedEntity = [LocalName "@"] DomainName [":" portNumber]
LocalName = 1*32(suitableCharacter)
portNumber = 1*5(DIGIT)
RequestIdentifier = 1*32(HEXDIG)
LocalConnectionOptions = [ LocalOptionValue 0*(WSP)
0*("," 0*(WSP) LocalOptionValue 0*(WSP)) ]
LocalOptionValue = ("p" ":" <packetizationPeriod> )
/ ("a" ":" <compressionAlgorithm> )
/ ("b" ":" <bandwidth> )
/ ("e" ":" <echoCancellation> )
/ ("gc" ":" <gainControl> )
/ ("s" ":" <silenceSuppression> )
/ ("t" ":" <typeOfService> )
/ ("r" ":" <resourceReservation> )
/ ("k" ":" <encryptionmethod>[":"<encryptionKey>])
/ ("nt" ":" <typeOfNetwork> )
/ (localOptionExtensionName ":"
/ localOptionExtensionValue)
Capabilities = [ CapabilityValue 0*(WSP)
0*("," 0*(WSP) CapabilityValue 0*(WSP)) ]
CapabilityValue = LocalOptionValue
/ ("v" ":" <supportedPackages>)
/ ("m" ":" <supportedModes> )
packetizationPeriod = 1*4(DIGIT)["-" 1*4(DIGIT)]
compressionAlgorithm = algorithmName 0*(";" algorithmName)
algorithmName = 1*32(SuitableCharacter)
bandwidth = 1*4(DIGIT)["-" 1*4(DIGIT)]
echoCancellation = "on" / "off"
gainControl = "auto" / ["-"]1*4(DIGIT)
silenceSuppression = "on" / "off"
typeOfService = 2HEXDIG
resourceReservation = "g" / "cl" / "be"
;encryption parameters are coded as in SDP (RFC2327)
encryptiondata = ( "clear" ":" <encryptionKey> )
/ ( "base64" ":" <encodedEncryptionKey> )
/ ( "uri" ":" <URItoObtainKey> )
/ ( "prompt" ) ; defined in SDP, not usable in MGCP!
encryptionKey = 1*(SuitableCharacter / SP)
encodedEncryptionKey = 1*(ALPHA / DIGIT / "+" / "/" / "=")
URItoObtainKey = 1*(SuitableCharacter) / quotedString
typeOfNetwork = "IN" / "ATM" / "LOCAL"
supportedModes= ConnectionMode 0*(";" ConnectionMode)
supportedPackages = packageName 0*(";" packageName)
localOptionExtensionName = "x" ("+"/"-") 1*32(SuitableCharacter)
localOptionExtensionValue = 1*32(SuitableCharacter) / quotedString
ConnectionMode = "sendonly" / "recvonly" / "sendrecv" /
"confrnce" / "inactive" / "loopback" /
"conttest" / "netwloop" / "netwtest" / "data"
RequestedEvents = [requestedEvent 0*("," 0*(WSP) requestedEvent)]
requestedEvent = eventName [ "(" requestedActions ")" ]
eventName = [ (packageName / "*") "/" ] (eventId / "all" / eventRange)
[ "@" (ConnectionId / "$" / "*") ]
packageName = 1*(ALPHA / DIGIT / HYPHEN)
eventId = 1*(SuitableCharacter)
eventRange = "[" 1*(DIGIT / DTMFLetter / "*" / "#" /
(DIGIT "-" DIGIT)/(DTMFLetter "-"
DTMFLetter)) "]"
requestedActions = requestedAction 0*("," 0*(WSP) requestedAction)
requestedAction = "N" / "A" / "D" / "S" / "I" / "K" /
"E" "(" EmbeddedRequest ")"
EmbeddedRequest = ( "R" "(" EmbeddedRequestList ")"
["," "S" "(" EmbeddedSignalRequest ")" ]
["," "D" "(" EmbeddedDigitMap ")" ] )
/ ( "S" "(" EmbeddedSignalRequest ")"
["," "D" "(" EmbeddedDigitMap ")" ] )
/ ( "D" "(" EmbeddedDigitMap ")" )
EmbeddedRequestList = RequestedEvents
EmbeddedSignalRequest = SignalRequests
EmbeddedDigitMap = DigitMap
SignalRequests = [ SignalRequest 0*("," 0*(WSP) SignalRequest ) ]
SignalRequest = eventName [ "(" eventParameters ")" ]
eventParameters = eventParameter 0*("," 0*(WSP) eventParameter)
eventParameter = eventParameterString / quotedString
eventParameterString = 1*(SuitableCharacter)
DigitMap = DigitString / "(" DigitStringList ")"
DigitStringList = DigitString 0*( "|" DigitString )
DigitString = 1*(DigitStringElement)
DigitStringElement = DigitPosition ["."]
DigitPosition = DigitMapLetter / DigitMapRange
DigitMapLetter = DIGIT / "#" / "*" / "A" / "B" / "C" / "D" / "T"
DigitMapRange = "x" / "[" 1*DigitLetter "]"
DigitLetter ::= *((DIGIT "-" DIGIT ) / DigitMapLetter)
ObservedEvents = SignalRequests
EventStates = SignalRequests
ConnectionParameters = [ConnectionParameter
0*( "," 0*(WSP) ConnectionParameter )
ConnectionParameter = ( "PS" "=" packetsSent )
/ ( "OS" "=" octetsSent )
/ ( "PR" "=" packetsReceived )
/ ( "OR" "=" octetsReceived )
/ ( "PL" "=" packetsLost )
/ ( "JI" "=" jitter )
/ ( "LA" "=" averageLatency )
/ ( ConnectionParameterExtensionName "="
ConnectionParameterExtensionValue )
packetsSent = 1*9(DIGIT)
octetsSent = 1*9(DIGIT)
packetsReceived = 1*9(DIGIT)
octetsReceived = 1*9(DIGIT)
packetsLost = 1*9(DIGIT)
jitter = 1*9(DIGIT)
averageLatency = 1*9(DIGIT)
ConnectionParameterExtensionName = "X" "-" 2*ALPHA
ConnectionParameterExtensionValue = 1*9(DIGIT)
ReasonCode = 3DIGIT [SPACE 1*(%x20-7E)]
SpecificEndpointID = endpointName
SecondEndpointID = endpointName
RequestedInfo = [infoCode 0*("," infoCode)]
infoCode = "B" / "C" / "I" / "N" / "X" / "L" / "M" /
"R" / "S" / "D" / "O" / "P" / "E" / "Z" /
"Q" / "T" / "RC" / "LC" / "A" / "ES" / "RM" / "RD"
QuarantineHandling = loopControl / processControl /
(loopControl "," processControl )
loopControl = "step" / "loop"
processControl = "process" / "discard"
DetectEvents = [eventName 0*("," eventName)]
RestartMethod = "graceful" / "forced" / "restart" / "disconnected"
RestartDelay = 1*6(DIGIT)
extensionParameter = "X" ("-"/"+") 1*6(ALPHA / DIGIT)
parameterString = 1*(%x20-7F)
MGCPResponse = MGCPResponseLine 0*(MGCPParameter)
[EOL *SDPinformation]
MGCPResponseLine = (<responseCode> 1*(WSP) <transaction-id>
[1*(WSP) <responseString>] EOL)
responseCode = 3DIGIT
responseString = *(%x20-7E)
SuitableCharacter= DIGIT / ALPHA / "+" / "-" / "_" / "&" /
"!" / "'" / "|" / "=" / "#" / "?" / "/" /
"." / "$" / "*" / ";" / "@" / "[" / "]" /
"^" / "`" / "{" / "}" / "~"
quotedString = DQUOTE visibleString
0*(quoteEscape visibleString) DQUOTE
quoteEscape = DQUOTE DQUOTE
visibleString = (%x00-21 / %x23-FF)
EOL = CRLF / LF
SDPinformation = ;See RFC2327
3.5. Encoding of the session description
The session description is encoded in conformance with the session
description protocol, SDP. MGCP implementations are expected to be
fully capable of parsing any conformant SDP message, and should send
session descriptions that strictly conform to the SDP standard. The
usage of SDP actually depends on the type of session that is being,
as specified in the "mode" parameter:
* if the mode is set to "data", the session description describes
the configuration of a data access service.
* if the mode is set to any other value, the session description is
for an audio service.
For an audio service, the gateway will consider the information
provided in SDP for the "audio" media. For a data service, the
gateway will consider the information provided for the "network-
access" media.
3.5.1. Usage of SDP for an audio service
In a telephony gateway, we only have to describe sessions that use
exactly one media, audio. The parameters of SDP that are relevant for
the telephony application are:
At the session description level:
* The IP address of the remote gateway (in commands) or of the
local gateway (in responses), or multicast address of the audio
conference, encoded as an SDP "connection data" parameter. This
parameter specifies the IP address that will be used to
exchange RTP packets.
For the audio media:
* Media description field (m) specifying the audio media, the
transport port used for receiving RTP packets by the remote
gateway (commands) or by the local gateway (responses), the
RTP/AVP transport, and the list of formats that the gateway
will accept. This list should normally always include the code
0 (reserved for PCMU).
* Optionally, RTPMAP attributes that define the encoding of
dynamic audio formats,
* Optionally, a packetization period (packet time) attribute
(Ptime) defining the duration of the packet,
* Optionally, an attribute defining the type of connection
(sendonly, recvonly, sendrecv, inactive). Note that this
attribute does not have a direct relation with the "Mode"
parameter of MGCP. In fact, the SDP type of connection will
most of the time be set to "sendrecv", regardless of the value
used by MGCP. Other values will only be used rarely, for
example in the case of information or announcement servers that
need to establish one way connections.
* The IP address of the remote gateway (in commands) or of the
local gateway (in responses), if it is not present at the
session level.
An example of SDP specification for an audio connection could be:
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
There is a request, in some environments, to use the MGCP to
negotiate connections that will use other transmission channels than
RTP over UDP and IP. This will be detailed in an extension to this
document.
3.5.2. Usage of SDP in a network access service
The parameters of SDP that are relevant for a data network access
application are:
For the data media:
* Media description field (m) specifying the network access
media, identified by the code "m=nas/xxxx", where "xxxx"
describes the access control method that should be used for
parametrizing the network access, as specified below. The field
may also specify the port that should be used for contacting
the server, as specified in the SDP syntax.
* Connection address parameter (c=) specifying the address, or
the domain name, of the server that implement the access
control method. This parameter may also be specified at the
session level.
* Optionally, a bearer type attribute (a=bearer:) describing the
type of data connection to be used, including the modem type.
* Optionally, a framing type attribue (a=framing:) describing the
type of framing that will be used on the channel.
* Optionally, attributes describing the called number
(a=dialed:), the number to which the call was delivered
(a=called:) and the calling number (a=dialing:).
* Optionally, attributes describing the range of addresses that
could be used by the dialup client on its LAN (a=subnet:).
* Optionally, an encryption key, encoded as specified in the SDP
protocol(k=).
The connection address shall be encoded as specified in the SDP
standard. It will be used in conjunction with the port specified in
the media line to access a server, whose type will one of:
__________________________________________________________
| Method name| Method description |
|____________|____________________________________________|
| radius | Authentication according |
| | to the Radius protocol. |
| tacacs | Authentication according |
| | to the TACACS+ protocol. |
| diameter | Authentication according |
| | to the Diameter protocol. |
| l2tp | Level 2 tunneling protocol. |
| | The address and port are those of the LNS.|
| login | Local login. (There is normally |
| | no server for that method.) |
| none | No authentication required. |
| | (The call was probably vetted |
| | by the Call Agent.) |
|____________|____________________________________________|
If needed, the gateway may use the key specified in the announcement
to access the service. That key, in particular, may be used for the
establishment of an L2TP tunnel.
The bearer attribute is composed of a bearer name and an optional
extension. The bearer type specifies the type of modulation (modem
name) or, in the case of digital connections, the type of ISDN
service (8 bits, 7 bits). When an extension is present, it is
separated from the bearer name by a single slash (/). The valid
values of the bearer attribute are defined in the following table:
____________________________________________________________________
| Type of bearer description | Example of values |
|_________________________________|_________________________________|
| ITU modem standard | V.32, V.34, V.90. |
| ITU modem standard qualified | v.90/3com, |
| by a manufacturer name | v.90/rockwell, |
| | v.90/xxx |
| Well known modem types | X2, K56flex |
| ISDN transparent access, 64 kbps| ISDN64 |
| ISDN64 + V.110 | ISDN64/V.110 |
| ISDN64 + V.120 | ISDN64/V.120 |
| ISDN transparent access, 56 kbps| ISDN56 |
| Informal identification | (Requires coordination between |
| | the Call Agent and the gateway)|
|_________________________________|_________________________________|
The valid values of the framing attribute are defined in the
following table:
_________________________________________________
| Type of framing description| Example of values|
|____________________________|___________________|
| PPP, asynchronous framing | ppp-asynch |
| PPP, HDLC framing | ppp-hdlc |
| SLIP, asynchronous | slip |
| Asynchronous, no framing | asynch |
|____________________________|___________________|
The network access authentication parameter provides instructions on
the access control that should be exercized for the data call. This
optional attribute is encoded as:
"a=subnet:" <network type> <address type>
<connection address> "/" <prefix length>
Where the parameters "network type", "address type", and "connection
address" are formatted as defined for the connection address
parameter (c=) in SDP, and where the "prefix length" is a decimal
representation of the number of bits in the prefix.
Examples of SDP announcement for the network access service could be:
v=0
m=nas/radius
c=IN IP4 radius.example.net
a=bearer:v.34
a=framing:ppp-asynch
a=dialed:18001234567
a=called:12345678901
a=dialing:12340567890
v=0
m=nas/none
c=IN IP4 128.96.41.1
a=subnet:IN IP4 123.45.67.64/26
a=bearer:isdn64
a=framing:ppp-sync
a=dialed:18001234567
a=dialing:2345678901
v=0
c=IN IP4 access.example.net
m=nas/l2tp
k=clear:some-shared-secret
a=bearer:v.32
a=framing:ppp-asynch
a=dialed:18001234567
a=dialing:2345678901
3.5.3. Usage of SDP for ATM connections
The specification of the SDP payload for ATM connections will be
described in a companion document, "Usage of MGCP to control Voice
over ATM gateways." The following text is indicative.
The SDP payload will specify:
* That the connection is to be established over an ATM interface,
using the "c=" parameter of SDP to specify an address in the ATM
family, the ATM addressing variant (NSAP, UNI, E.164) and the ATM
address.
* The "m=audio" parameter will specify the audio encoding and, if
needed, the VPI and VCI.
* Additional attributes parameters (a=) will be used to specify the
ATM coding variants, such as the type of adaptation layer and the
error correction or loss compenmsation algorithms.
An example of SDP payload for an ATM connection could be:
v=0 c=ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.fe m=audio
5/1002 ATM/AVP PCMU a=connection_type:AAL2
3.5.4. Usage of SDP for local connections
When MGCP is used to set up internal connections within a single
gateway, the SDP format is used to encode the parameters of that
connection. The following parameters will be used:
* The connection parameter (C=) will specify that the connection is
local, using the keyword "LOCAL" as network type space, the
keyword "EPN" (endpoint name) as address type, and the name of
the endpoint as the connection-address.
* The "m=audio" parameter will specify a port number, which will
always be set to 0, the type of protocol, always set to the
keyword LOCAL, and the type of encoding, using the same
conventions used for RTP (RTP payload numbers.) The type of
encoding should normally be set to 0 (PCMU).
An example of local SDP payload could be:
v=0
c=LOCAL EPN X35V3+A4/13
m=audio 0 LOCAL 0
3.6. Transmission over UDP
MGCP messages are transmitted over UDP. Commands are sent to one of
the IP addresses defined in the DNS for the specified endpoint . The
responses are sent back to the source address of the commands.
When no port is specified for the endpoint, the commands should be
sent:
* by the Call Agents, to the default MGCP port for gateways, 2427.
* by the Gateways, to the default MGCP port for Call Agents, 2727.
3.6.1. Providing the At-Most-Once functionality
MGCP messages, being carried over UDP, may be subject to losses. In
the absence of a timely response, commands are repeated. Most MGCP
commands are not idempotent. The state of the gateway would become
unpredictable if, for example, CreateConnection commands were
executed several times. The transmission procedures must thus
provide an "At-Most-Once" functionality.
MGCP entities are expected to keep in memory a list of the responses
that they sent to recent transactions and a list of the transactions
that are currently being executed. The transaction identifiers of
incoming commands are compared to the transaction identifiers of the
recent responses. If a match is found, the MGCP entity does not
execute the transaction, but simply repeats the response. The
remaining commands will be compared to the list of current
transaction. If a match is found, the MGCP entity does not execute
the transaction, which is simply ignored.
The procedure use a long timer value, noted LONG-TIMER in the
following. The timer should be set larger than the maximum duration
of a transaction, which should take into account the maximum number
of repetitions, the maximum value of the repetition timer and the
maximum propagation delay of a packet in the network. A suggested
value is 30 seconds.
The copy of the responses can be destroyed either LONG-TIMER seconds
after the response is issued, or when the gateway (or the call agent)
receives a confirmation that the response has been received, through
the "Response Acknowledgement attribute". For transactions that are
acknowledged through this attribute, the gateway shall keep a copy of
the transaction-id for LONG-TIMER seconds after the response is
issued, in order to detect and ignore duplicate copies of the
transaction request that could be produced by the network.
3.6.2. Transaction identifiers and three ways handshake
Transaction identifiers are integer numbers in the range from 0 to
999,999,999. Call-agents may decide to use a specific number space
for each of the gateways that they manage, or to use the same number
space for all gateways that belong to some arbitrary group. Call
agents may decide to share the load of managing a large gateway
between several independent processes. These processes will share
the same transaction number space. There are multiple possible
implementations of this sharing, such as having a centralized
allocation of transaction identifiers, or pre-allocating non-
overlapping ranges of identifiers to different processes. The
implementations must guarantee that unique transaction identifiers
are allocated to all transactions that originate from a logical call
agent, as defined in the "states, failover and race conditions"
section. Gateways can simply detect duplicate transactions by looking
at the transaction identifier only.
The Response Acknowledgement Attribute can be found in any command.
It carries a set of "confirmed transaction-id ranges."
MGCP gateways may choose to delete the copies of the responses to
transactions whose id is included in "confirmed transaction-id
ranges" received in the Response Confirmation messages. They should
silently discard further commands from that Call Agent when the
transaction-id falls within these ranges.
The "confirmed transaction-id ranges" values shall not be used if
more than LONG-TIMER seconds have elapsed since the gateway issued
its last response to that call agent, or when a gateway resumes
operation. In this situation, commands should be accepted and
processed, without any test on the transaction-id.
Commands that carry the "Response Acknowledgement attribute" may be
transmitted in disorder. The gateway shall retain the union of the
"confirmed transaction-id ranges" received in recent commands.
3.6.3. Computing retransmission timers
It is the responsibility of the requesting entity to provide suitable
time outs for all outstanding commands, and to retry commands when
time outs have been exceeded. Furthermore, when repeated commands
fail to be acknowledged, it is the responsibility of the requesting
entity to seek redundant services and/or clear existing or pending
connections.
The specification purposely avoids specifying any value for the
retransmission timers. These values are typically network dependent.
The retransmission timers should normally estimate the timer by
measuring the time spent between the sending of a command and the
return of a response. One possibility is to use the algorithm
implemented in TCP-IP, which uses two variables:
* the average acknowledgement delay, AAD, estimated through an
exponentially smoothed average of the observed delays,
* the average deviation, ADEV, estimated through an exponentially
smoothed average of the absolute value of the difference between
the observed delay and the current average
The retransmission timer, in TCP, is set to the sum of the average
delay plus N times the average deviation. In MGCP, the maximum value
of the timer should however be bounded, in order to guarantee that no
repeated packet will be received by the gateways after LONG-TIMER
seconds. A suggested maximum value is 4 seconds.
After any retransmission, the MGCP entity should do the following:
* It should double the estimated value of the average delay, AAD
* It should compute a random value, uniformly distributed between
0.5 AAD and AAD
* It should set the retransmission timer to the sum of that random
value and N times the average deviation.
This procedure has two effects. Because it includes an exponentially
increasing component, it will automatically slow down the stream of
messages in case of congestion. Because it includes a random
component, it will break the potential synchronization between
notifications triggered by the same external event.
3.6.4. Piggy backing
There are cases when a Call Agent will want to send several messages
at the same time to the same gateways. When several MGCP messages
have to be sent in the same UDP packets, they should be separated by
a line of text that contain a single dot, as in for example:
200 2005 OK
DLCX 1244 card23/21@trgw-7.example.net MGCP 1.0
C: A3C47F21456789F0
I: FDE234C8
The piggy-backed messages should be processed exactly has if they had
been received in several simultaneous messages.
3.6.5. Provisional responses
Executing some transactions may require a long time. Long execution
times may interact with the timer based retransmission procedure.
This may result either in an inordinate number of retransmissions, or
in timer values that become too long to be efficient.
Gateways that can predict that a transaction will require a long
execution time may send a provisional response, with response code
100. They should send this response if they receive a repetition of
a transaction that is still being executed.
MGCP entities that receive a provisional response shall switch to a
longer repetition timer for that transaction.
4. States, failover and race conditions.
In order to implement proper call signalling, the Call Agent must
keep track of the state of the endpoint, and the gateway must make
sure that events are properly notified to the call agent. Special
conditions exist when the gateway or the call agent are restarted:
the gateway must be redirected to a new call agent during "failover"
procedures, the call agent must take special action when the gateway
is taken offline, or restarted.
4.1. Basic Asumptions
The support of "failover" is based on the following assumptions:
* Call Agents are identified by their domain name, not their network
addresses, and several addresses can be associated with a domain
name.
* An endpoint has one NotifiedEntity associated with it any given
point in time.
* The NotifiedEntity is the last value of the "NotifiedEntity"
parameter received for this endpoint (including wild-carded end-
point-names). If no explicit "NotifiedEntity" parameter has been
received, the "NotifiedEntity" defaults to the provisioned
NotifiedEntity value, or if no value was provisioned to the source
address of the last command received for the endpoint,
* Responses to commands are always sent to the source address of the
command, regardless of the NotifiedEntity.
* When the "notified entity" refers to a domain name that resolves
to multiple IP- address, endpoints are capable of switching
between different interfaces on the same logical call agent,
however they cannot switch to other (backup) call agent(s) on
their own. A backup call agent can however instruct them to
switch, either directly or indirectly.
* If an entire call agent becomes unavailable, the endpoints managed
by that call agent will eventually become "disconnected". The only
way for these endpoints to become connected again is either for
the failed call agent to become available, or for a backup call
agent to contact the affected endpoints.
* When a backup call agent has taken over control of a group of
endpoints, it is assumed that the failed call agent will
communicate and synchronize with the backup call agent in order to
transfer control of the affected endpoints back to the original
call agent (if that's even desired - maybe the failed call agent
should simply become the backup call agent now).
We should note that handover conflict resolution between separate
CA's is not in place - we are relying strictly on the CA's knowing
what they are doing and communicating with each other (although
AuditEndpoint can be used to learn about the current NotifiedEntity).
4.2. Security, Retransmission, and Detection of Lost Associations:
The media gateway control protocol is organized as a set of
transactions, each of which is composed of a command and a response,
commonly referred to as an acknowledgement. The MGCP messages, being
carried over UDP, may be subject to losses. In the absence of a
timely response, commands are repeated. MGCP entities are expected to
keep in memory a list of the responses that they sent to recent
transactions, i.e. a list of all the responses they sent over the
last LONG-TIMER seconds, and a list of the transactions that are
currently being executed.
The transaction identifiers of incoming commands are compared to the
transaction identifiers of the recent responses. If a match is found,
the MGCP entity does not execute the transaction, but simply repeats
the response. The remaining commands will be compared to the list of
current transaction. If a match is found, the MGCP entity does not
execute the transaction, which is simply ignored - a response will be
provided when the execution of the command is complete.
The repetition mechanism is used to guard against four types of
possible errors:
* transmission errors, when for example a packet is lost due to
noise on a line or congestion in a queue,
* component failure, when for example an interface to a call agent
becomes unavailable,
* call agent failure, when for example an entire call agent becomes
unavailable,
* failover, when a new call agent is "taking over" transparently.
The elements should be able to derive from the past history an
estimate of the packet loss rate due to transmission errors. In a
properly configured system, this loss rate should be kept very low,
typically less than 1%. If a call agent or a gateway has to repeat a
message more than a few times, it is very legitimate to assume that
something else than a transmission error is occurring. For example,
given a loss rate of 1%, the probability that 5 consecutive
transmission attempts fail is 1 in 100 billion, an event that should
occur less than once every 10 days for a call agent that processes
1,000 transactions per second. (Indeed, the number of repetition that
is considered excessive should be a function of the prevailing packet
loss rate.) We should note that the "suspicion threshold", which we
will call "Max1", is normally lower than the "disconnection
threshold", which should be set to a larger value.
Command issued: N=0
|
transmission: N++
| +------------ retransmission: N++ -----------+
| | |
| | transmission |
| | +---to new address -+<--------------------|--+
| | | N=0 | | |
V V V | | |
+-----------+ | | |
| awaiting |- new call agent ->+ +------------+ | |
| response |--- timer elapsed --->| N > Max1 ? |-(no)+ |
+-----------+ <----------+ +------------+ ^ |
| | | | | |
| +- wrong key? -+ (yes) | |
| | | |
response received (if N=Max1, | |
| or N=Max2 | |
| check DNS) | |
v | | |
(end) +---------------+ | |
|more addresses?|(yes)|--+
+---------------+ |
| |
(no) |
| |
+------------+ |
| N > Max2 ? |(no)-+
+------------+
|
(yes)
|
v
(disconnected)
A classic retransmission algorithm would simply count the number of
successive repetitions, and conclude that the association is broken
after re-transmitting the packet an excessive number of times
(typically between 7 and 11 times.) In order to account for the
possibility of an undetected or in-progress "failover", we modify the
classic algorithm as follows:
* We request that the gateway always checks for the presence of a
new call agent. It can be noticed either by
- receiving a valid multicast message announcing a failover, or
- receiving a command where the NotifiedEntity points to the new
call agent, or
- receiving a redirection response pointing to a new Call Agent.
If a new call agent is detected, the gateway starts transmitting
outstanding commands to that new agent. Responses to commands are
still transmitted to the source address of the command.
* we request that if the number of repetitions for this Call Agent
is larger than "Max1", that the gateway actively queries the name
server in order to detect the possible change of the call agent
interfaces.
* The gateway may have learned several IP addresses for the call
agent. If the number of repetitions is larger than "Max1" and
lower than "Max2", and there are more interfaces that have not
been tried, then the gateway should direct the retransmissions to
alternate addresses.
* If there are no more interfaces to try, and the number of
repetitions is Max2, then the gateway contacts the DNS one more
time to see if any other interface should have become available.
If not, the gateway is now disconnected.
The procedure will maximize the chances of detecting an ongoing
failover. It poses indeed two very specific problems, the potentially
long delays of a timer based procedure and the risk of confusion
caused by the use of cryptographic protections.
In order to automatically adapt to network load, MGCP specifies
exponentially increasing timers. If the initial timer is set to 200
milliseconds, the loss of a fifth retransmission will be detected
after about 6 seconds. This is probably an acceptable waiting delay
to detect a failover. The repetitions should continue after that
delay not only in order to perhaps overcome a transient connectivity
problem, but also in order to allow some more time for the execution
of a failover - waiting a total delay of 30 seconds is probably
acceptable.
It is however important that the maximum delay of retransmissions be
bounded. Prior to any retransmission, it is checked that the time
elapsed since the sending of the initial datagram is no greater than
T- MAX. If more than T-MAX time has elapsed, the endpoint becomes
disconnected. The value T-MAX is related to the LONG-TIMER value: the
LONG-TIMER value is obtained by adding to T-MAX the maximum
propagation delay in the network.
Another potential cause of connection failure would be the reception
of a "wrong key" message, sent by a call agent that could not
authenticate the command, presumably because it had lost the security
parameters of the association. Such messages are actually not
authorized in IPSEC, and they should in fact not be taken at face
value: an attacker could easily forge "wrong key" messages in order
to precipitate the loss of a control connection. The current
algorithm ignores these messages, which translates into a strict
reliance on timers. The algorithm could in fact be improved, maybe
by executing a check with the key server of the call agent after
"Max1" repetitions.
4.3. Race conditions
MGCP deals with race conditions through the notion of a "quarantine
list" and through explicit detection of desynchronization.
MGCP does not assume that the transport mechanism will maintain the
order of command and responses. This may cause race conditions, that
may be obviated through a proper behavior of the call agent. (Note
that some race conditions are inherent to distributed systems; they
would still occur, even if the commands were transmitted in strict
order.)
In some cases, many gateways may decide to restart operation at the
same time. This may occur, for example, if an area loses power or
transmission capability during an earthquake or an ice storm. When
power and transmission are reestablished, many gateways may decide to
send "RestartInProgress" commands simultaneously, leading to very
unstable operation.
4.3.1. Quarantine list
MGCP controlled gateways will receive "notification requests" that
ask them to watch for a list of "events." The protocol elements that
determine the handling of these events are the "Requested Events"
list, the "Digit Map" and the "Detect Events" list.
When the endpoint is initialized, the requested events list and the
digit map are empty. After reception of a command, the gateway
starts observing the endpoint for occurrences of the events mentioned
in the list.
The events are examined as they occur. The action that follows is
determined by the "action" parameter associated to the event in the
list of requested events, and also by the digit map. The events that
are defined as "accumulate" or "treat according to digit map" are
accumulated in a list of events, the events that are marked as
"treated according to the digit map" will additionally be accumulated
in the dialed string. This will go on until one event is encountered
that triggers a Notification to the "notified entity."
The gateway, at this point, will transmit the notification command
and will place the endpoint in a "notification" state. As long as the
endpoint is in this notification state, the events that are to be
detected on the endpoint are stored in a "quarantine" buffer for
later processing. The events are, in a sense, "quarantined." All
events that are specified by the union of the RequestedEvents
parameter and the most recently received DetectEvent parameter or, in
the absence of the latter, all events that are referred to in the
RequestedEvents, should be detected and quarantined, regardless of
the action associated to the event.
The endpoint exits the "notification state" when the acknowledgement
of the Notify command is received. The Notify command may be
retransmitted in the "notification state", as specified in section
3.5. When the endpoint exits the "notification state" it resets the
list of observed events and the "current dial string" of the endpoint
to a null value.
Following that point, the behavior of the gateway depends on the
value of The QuarantineHandling parameter in the notification
request. If the Call Agent specified that it expected at most one
notification in response to the notification request command, then
the gateway should simply keep on accumulating events in the
quarantine list until it receives the next notification request
command.
If the gateway is authorized to send multiple successive Notify
commands, it will proceed as follows. When the gateway exits the
"notification state", it resets the list of observed events and the
"current dial string" of the endpoint to a null value and starts
processing the list of quarantined events, using the already received