leaves us with a dilemma: either allow the call to proceed without
waiting for the round trip to complete, and risk for example,
"clipping" a remote announcement, or wait for the full roundtrip
and settle for slower call-set-up procedures.
* Source spoofing is only effective if the attacker can obtain valid
pairs of source destination addresses and ports, for example by
listening to a fraction of the traffic. To fight source spoofing,
one could try to control all access points to the network. But
this is in practice very hard to achieve.
An alternative to checking the source address is to encrypt and
authenticate the packets, using a secret key that is conveyed during
the call set-up procedure. This will not slow down the call set-up,
and provides strong protection against address spoofing.
11. MG-MGC CONTROL INTERFACE
The control association between MG and MGC is initiated at MG cold
start, and announced by a ServiceChange message, but can be changed
by subsequent events, such as failures or manual service events.
While the protocol does not have an explicit mechanism to support
multiple MGCs controlling a physical MG, it has been designed to
support the multiple logical MG (within a single physical MG) that
can be associated with different MGCs.
11.1 Multiple Virtual MGs
A physical Media Gateway may be partitioned into one or more Virtual
MGs. A virtual MG consists of a set of statically partitioned
physical Terminations and/or sets of ephemeral Terminations. A
physical Termination is controlled by one MGC. The model does not
require that other resources be statically allocated, just
Terminations. The mechanism for allocating Terminations to virtual
MGs is a management method outside the scope of the protocol. Each
of the virtual MGs appears to the MGC as a complete MG client.
A physical MG may have only one network interface, which must be
shared across virtual MGs. In such a case, the packet/cell side
Termination is shared. It should be noted however, that in use, such
interfaces require an ephemeral instance of the Termination to be
created per flow, and thus sharing the Termination is
straightforward. This mechanism does lead to a complication, namely
that the MG must always know which of its controlling MGCs should be
notified if an event occurs on the interface.
In normal operation, the Virtual MG will be instructed by the MGC to
create network flows (if it is the originating side), or to expect
flow requests (if it is the terminating side), and no confusion will
arise. However, if an unexpected event occurs, the Virtual MG must
know what to do with respect to the physical resources it is
controlling.
If recovering from the event requires manipulation of a physical
interface's state, only one MGC should do so. These issues are
resolved by allowing any of the MGCs to create EventsDescriptors to
be notified of such events, but only one MGC can have read/write
access to the physical interface properties; all other MGCs have
read-only access. The management mechanism is used to designate
which MGC has read/write capability, and is designated the Master
MGC.
Each virtual MG has its own Root Termination. In most cases the
values for the properties of the Root Termination are independently
settable by each MGC. Where there can only be one value, the
parameter is read-only to all but the Master MGC.
ServiceChange may only be applied to a Termination or set of
Terminations partitioned to the Virtual MG or created (in the case of
ephemeral Terminations) by that Virtual MG.
11.2 Cold Start
A MG is pre-provisioned by a management mechanism outside the scope
of this protocol with a Primary and (optionally) an ordered list of
Secondary MGCs. Upon a cold start of the MG, it will issue a
ServiceChange command with a "Restart" method, on the Root
Termination to its primary MGC. If the MGC accepts the MG, it will
send a Transaction Accept, with the ServiceChangeMgcId set to itself.
If the MG receives an ServiceChangeMgcId not equal to the MGC it
contacted, it sends a ServiceChange to the MGC specified in the
ServiceChangeMgcId. It continues this process until it gets a
controlling MGC to accept its registration, or it fails to get a
reply. Upon failure to obtain a reply, either from the Primary MGC,
or a designated successor, the MG tries its pre-provisioned Secondary
MGCs, in order. If the MG is unable to establish a control
relationship with any MGC, it shall wait a random amount of time as
described in section 9.2 and then start contacting its primary, and
if necessary, its secondary MGCs again.
It is possible that the reply to a ServiceChange with Restart will be
lost, and a command will be received by the MG prior to the receipt
of the ServiceChange response. The MG shall issue error 505 -
Command Received before Restart Response.
11.3 Negotiation of Protocol Version
The first ServiceChange command from an MG shall contain the version
number of the protocol supported by the MG in the
ServiceChangeVersion parameter. Upon receiving such a message, if the
MGC supports only a lower version, then the MGC shall send a
ServiceChangeReply with the lower version and thereafter all the
messages between MG and MGC shall conform to the lower version of the
protocol. If the MG is unable to comply and it has established
a transport connection to the MGC, it should close that connection.
In any event, it should reject all subsequent requests from the MGC
with Error 406 Version Not supported.
If the MGC supports a higher version than the MG but is able to
support the lower version proposed by the MG, it shall send a
ServiceChangeReply with the lower version and thereafter all the
messages between MG and MGC shall conform to the lower version of the
protocol. If the MGC is unable to comply, it shall reject the
association, with Error 406 Version Not Supported.
Protocol version negotiation may also occur at "handoff" and
"failover" ServiceChanges.
When extending the protocol with new versions, the following rules
should be followed.
1. Existing protocol elements, i.e., procedures, parameters,
descriptor, property, values, should not be changed unless a
protocol error needs to be corrected or it becomes necessary to
change the operation of the service that is being supported by the
protocol.
2. The semantics of a command, a parameter, descriptor, property,
value should not be changed.
3. Established rules for formatting and encoding messages and
parameters should not be modified.
4. When information elements are found to be obsolete they can be
marked as not used. However, the identifier for that information
element will be marked as reserved. In that way it can not be used
in future versions.
11.4 Failure of an MG
If a MG fails, but is capable of sending a message to the MGC, it
sends a ServiceChange with an appropriate method (graceful or forced)
and specifies the Root TerminationID. When it returns to service, it
sends a ServiceChange with a "Restart" method.
Allowing the MGC to send duplicate messages to both MGs accommodates
pairs of MGs that are capable of redundant failover of one of the
MGs. Only the Working MG shall accept or reject transactions. Upon
failover, the Primary MG sends a ServiceChange command with a
"Failover" method and a "MG Impending Failure" reason. The MGC then
uses the secondary MG as the active MG. When the error condition is
repaired, the Working MG can send a "ServiceChange" with a "Restart"
method.
11.5 Failure of an MGC
If the MG detects a failure of its controlling MGC, it attempts to
contact the next MGC on its pre-provisioned list. It starts its
attempts at the beginning (Primary MGC), unless that was the MGC that
failed, in which case it starts at its first Secondary MGC. It sends
a ServiceChange message with a "Failover" method and a " MGC
Impending Failure" reason.
In partial failure, or manual maintenance reasons, an MGC may wish to
direct its controlled MGs to use a different MGC. To do so, it sends
a ServiceChange method to the MG with a "HandOff" method, and its
designated replacement in ServiceChangeMgcId. The MG should send a
ServiceChange message with a "Handoff" method and a "MGC directed
change" reason to the designated MGC. If it fails to get a reply, or
fails to see an Audit command subsequently, it should behave as if
its MGC failed, and start contacting secondary MGCs. If the MG is
unable to establish a control relationship with any MGC, it shall
wait a random amount of time as described in section 9.2 and then
start contacting its primary, and if necessary, its secondary MGCs
again.
No recommendation is made on how the MGCs involved in the Handoff
maintain state information; this is considered to be out of scope of
this recommendation. The MGC and MG may take the following steps when
Handoff occurs. When the MGC initiates a HandOff, the handover
should be transparent to Operations on the Media Gateway.
Transactions can be executed in any order, and could be in progress
when the ServiceChange is executed. Accordingly, commands in
progress continue, transaction replies are sent to the new MGC (after
a new control association is established), and the MG should expect
outstanding transaction replies from the new MGC. No new messages
shall be sent to the new MGC until the control association is
established. Repeated transaction requests shall be directed to the
new MGC. The MG shall maintain state on all terminations and
contexts.
It is possible that the MGC could be implemented in such a way that a
failed MGC is replaced by a working MGC where the identity of the new
MGC is the same as the failed one. In such a case,
ServiceChangeMgcId would be specified with the previous value and the
MG shall behave as if the value was changed, and send a ServiceChange
message, as above.
Pairs of MGCs that are capable of redundant failover can notify the
controlled MGs of the failover by the above mechanism.
12. PACKAGE DEFINITION
The primary mechanism for extension is by means of Packages. Packages
define additional Properties, Events, Signals and Statistics that may
occur on Terminations.
Packages defined by IETF will appear in separate RFCs.
Packages defined by ITU-T may appear in the relevant recommendations
(e.g. as annexes).
1. A public document or a standard forum document, which can be
referenced as the document that describes the package following
the guideline above, should be specified.
2. The document shall specify the version of the Package that it
describes.
3. The document should be available on a public web server and should
have a stable URL. The site should provide a mechanism to provide
comments and appropriate responses should be returned.
12.1 Guidelines for defining packages
Packages define Properties, Events, Signals, and Statistics.
Packages may also define new error codes according to the guidelines
given in section 13.2. This is a matter of documentary convenience:
the package documentation is submitted to IANA in support of the
error code registration. If a package is modified, it is unnecessary
to provide IANA with a new document reference in support of the error
code unless the description of the error code itself is modified.
Names of all such defined constructs shall consist of the PackageID
(which uniquely identifies the package) and the ID of the item (which
uniquely identifies the item in that package). In the text encoding
the two shall be separated by a forward slash ("/") character.
Example: togen/playtone is the text encoding to refer to the play
tone signal in the tone generation package.
A Package will contain the following sections:
12.1.1 Package
Overall description of the package, specifying:
* Package Name: only descriptive,
* PackageID: Is an identifier
* Description:
* Version: A new version of a package can only add additional
Properties, Events, Signals, Statistics and new possible values
for an existing parameter described in the original package. No
deletions or modifications shall be allowed. A version is an
integer in the range from 1 to 99.
* Extends (Optional): A package may extend an existing package. The
version of the original package must be specified. When a package
extends another package it shall only add additional Properties,
Events, Signals, Statistics and new possible values for an
existing parameter described in the original package. An extended
package shall not redefine or overload a name defined in the
original package. Hence, if package B version 1 extends package A
version 1, version 2 of B will not be able to extend the A version
2 if A version 2 defines a name already in B version 1.
12.1.2 Properties
Properties defined by the package, specifying:
* Property Name: only descriptive.
* PropertyID: Is an identifier
* Description:
* Type: One of:
String: UTF-8 string
Integer: 4 byte signed integer
Double: 8 byte signed integer
Character: Unicode UTF-8 encoding of a single letter.
Could be more than one octet.
Enumeration: One of a list of possible unique values (See 12.3)
Sub-list: A list of several values from a list
Boolean
* Possible Values:
* Defined in: Which Megaco descriptor the property is defined in.
LocalControl is for stream dependent properties. TerminationState
is for stream independent properties. These are expected to be
the most common cases, but it is possible for properties to be
defined in other descriptors.
* Characteristics: Read / Write or both, and (optionally), global:
Indicates whether a property is read-only, or read-write, and if
it is global. If Global is omitted, the property is not global.
If a property is declared as global, the value of the property is
shared by all terminations realizing the package.
12.1.3 Events
Events defined by the package, specifying:
* Event name: only descriptive.
* EventID: Is an identifier
* Description:
* EventsDescriptor Parameters: Parameters used by the MGC to
configure the event, and found in the EventsDescriptor. See
section 12.2.
* ObservedEventsDescriptor Parameters: Parameters returned to the
MGC in Notify requests and in replies to command requests from
the MGC that audit ObservedEventsDescriptor, and found in the
ObservedEventsDescriptor. See section 12.2.
12.1.4 Signals
* Signals defined by the package, specifying:
* Signal Name: only descriptive.
* SignalID: Is an identifier. SignalID is used in a
SignalsDescriptor
* Description
* SignalType: One of:
- OO (On/Off)
- TO (TimeOut)
- BR (Brief)
Note - SignalType may be defined such that it is dependent on
the value of one or more parameters. Signals that would be
played with SignalType BR or TO should have a default duration.
The package has to define the default duration and signalType.
* Duration: in hundredths of seconds
* Additional Parameters: See section 12.2
12.1.5 Statistics
Statistics defined by the package, specifying:
* Statistic name: only descriptive.
* StatisticID: Is an identifier. StatisticID is used in a
StatisticsDescriptor.
* Description
* Units: unit of measure, e.g. milliseconds, packets.
12.1.6 Procedures
Additional guidance on the use of the package.
12.2 Guidelines to defining Properties, Statistics and Parameters to
Events and Signals.
* Parameter Name: only descriptive
* ParameterID: Is an identifier
* Type: One of:
String: UTF-8 octet string
Integer: 4 octet signed integer
Double: 8 octet signed integer
Character: Unicode UTF-8 encoding of a single letter. Could be
more than one octet.
Enumeration: One of a list of possible unique values (See 12.3)
Sub-list: A list of several values from a list (not supported
for statistics)
Boolean
* Possible values:
* Description:
12.3 Lists
Possible values for parameters include enumerations. Enumerations
may be defined in a list. It is recommended that the list be IANA
registered so that packages that extend the list can be defined
without concern for conflicting names.
12.4 Identifiers
Identifiers in text encoding shall be strings of up to 64 characters,
containing no spaces, starting with an alphanumeric character and
consisting of alphanumeric characters and / or digits, and possibly
including the special character underscore ("_").
Identifiers in binary encoding are 2 octets long.
Both text and binary values shall be specified for each identifier,
including identifiers used as values in enumerated types.
12.5 Package Registration
A package can be registered with IANA for interoperability reasons.
See section 13 for IANA considerations.
13. IANA CONSIDERATIONS
13.1 Packages
The following considerations SHALL be met to register a package with
IANA:
1. A unique string name, unique serial number and version number is
registered for each package. The string name is used with text
encoding. The serial number shall be used with binary encoding.
Serial Numbers 60000-64565 are reserved for private use. Serial
number 0 is reserved.
2. A contact name, email and postal addresses for that contact shall
be specified. The contact information shall be updated by the
defining organization as necessary.
3. A reference to a document that describes the package, which should
be public:
The document shall specify the version of the Package that it
describes.
If the document is public, it should be located on a public web
server and should have a stable URL. The site should provide a
mechanism to provide comments and appropriate responses should be
returned.
4. Packages registered by other than recognized standards bodies
shall have a minimum package name length of 8 characters.
5. All other package names are first come-first served if all other
conditions are met
13.2 Error Codes
The following considerations SHALL be met to register an error code
with IANA:
1. An error number and a one line (80 character maximum) string is
registered for each error.
2. A complete description of the conditions under which the error is
detected shall be included in a publicly available document. The
description shall be sufficiently clear to differentiate the error
from all other existing error codes.
3. The document should be available on a public web server and should
have a stable URL.
4. Error numbers registered by recognized standards bodies shall have
3 or 4 character error numbers.
5. Error numbers registered by all other organizations or individuals
shall have 4 character error numbers.
6. An error number shall not be redefined, nor modified except by the
organization or individual that originally defined it, or their
successors or assigns.
13.3 ServiceChange Reasons
The following considerations SHALL be met to register service change
reason with IANA:
1. A one phrase, 80-character maximum, unique reason code is
registered for each reason.
2. A complete description of the conditions under which the reason is
used is detected shall be included in a publicly available
document. The description shall be sufficiently clear to
differentiate the reason from all other existing reasons.
3. The document should be available on a public web server and should
have a stable URL.
ANNEX A: BINARY ENCODING OF THE PROTOCOL (NORMATIVE)
This Annex specifies the syntax of messages using the notation
defined in ASN.1 [ITU-T Recommendation X.680 (1997): Information
Technology - Abstract Syntax Notation One (ASN.1) - Specification of
basic notation.]. Messages shall be encoded for transmission by
applying the basic encoding rules specified in [ITU-T Recommendation
X.690(1994) Information Technology - ASN.1 Encoding Rules:
Specification of Basic Encoding Rules (BER)].
A.1 Coding of wildcars
The use of wildcards ALL and CHOOSE is allowed in the protocol. This
allows a MGC to partially specify Termination IDs and let the MG
choose from the values that conform to the partial specification.
Termination IDs may encode a hierarchy of names. This hierarchy is
provisioned. For instance, a TerminationID may consist of a trunk
group, a trunk within the group and a circuit. Wildcarding must be
possible at all levels. The following paragraphs explain how this is
achieved.
The ASN.1 description uses octet strings of up to 8 octets in length
for Termination IDs. This means that Termination IDs consist of at
most 64 bits. A fully specified Termination ID may be preceded by a
sequence of wildcarding fields. A wildcarding field is one octet in
length. Bit 7 (the most significant bit) of this octet specifies
what type of wildcarding is invoked: if the bit value equals 1, then
the ALL wildcard is used; if the bit value if 0, then the CHOOSE
wildcard is used. Bit 6 of the wildcarding field specifies whether
the wildcarding pertains to one level in the hierarchical naming
scheme (bit value 0) or to the level of the hierarchy specified in
the wildcarding field plus all lower levels (bit value 1). Bits 0
through 5 of the wildcarding field specify the bit position in the
Termination ID at which the starts.
We illustrate this scheme with some examples. In these examples, the
most significant bit in a string of bits appears on the left hand
side.
Assume that Termination IDs are three octets long and that each octet
represents a level in a hierarchical naming scheme. A valid
Termination ID is
00000001 00011110 01010101.
Addressing ALL names with prefix 00000001 00011110 is done as
follows:
wildcarding field: 10000111
Termination ID: 00000001 00011110 xxxxxxxx.
The values of the bits labeled "x" is irrelevant and shall be ignored
by the receiver.
Indicating to the receiver that is must choose a name with 00011110
as the second octet is done as follows:
wildcarding fields: 00010111 followed by 00000111
Termination ID: xxxxxxxx 00011110 xxxxxxxx.
The first wildcard field indicates a CHOOSE wildcard for the level in
the naming hierarchy starting at bit 23, the highest level in our
assumed naming scheme. The second wildcard field indicates a CHOOSE
wildcard for the level in the naming hierarchy starting at bit 7, the
lowest level in our assumed naming scheme.
Finally, a CHOOSE-wildcarded name with the highest level of the name
equal to 00000001 is specified as follows:
wildcard field: 01001111
Termination ID: 0000001 xxxxxxxx xxxxxxxx .
Bit value 1 at bit position 6 of the first octet of the wildcard
field indicates that the wildcarding pertains to the specified level
in the naming hierarchy and all lower levels.
Context IDs may also be wildcarded. In the case of Context IDs,
however, specifying partial names is not allowed. Context ID 0x0
SHALL be used to indicate the NULL Context, Context ID 0xFFFFFFFE
SHALL be used to indicate a CHOOSE wildcard, and Context ID
0xFFFFFFFF SHALL be used to indicate an ALL wildcard.
TerminationID 0xFFFFFFFFFFFFFFFF SHALL be used to indicate the ROOT
Termination.
A.2 ASN.1 syntax specification
This section contains the ASN.1 specification of the H.248 protocol
syntax.
NOTE - In case a transport mechanism is used that employs application
level framing, the definition of Transaction below changes. Refer to
the annex defining the transport mechanism for the definition that
applies in that case.
NOTE - The ASN.1 specification below contains a clause defining
TerminationIDList as a sequence of TerminationIDs. The length of
this sequence SHALL be one, except possibly when used in
contextAuditResult.
MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::= BEGIN
MegacoMessage ::= SEQUENCE
{
authHeader AuthenticationHeader OPTIONAL,
mess Message
}
AuthenticationHeader ::= SEQUENCE
{
secParmIndex SecurityParmIndex,
seqNum SequenceNum,
ad AuthData
}
SecurityParmIndex ::= OCTET STRING(SIZE(4))
SequenceNum ::= OCTET STRING(SIZE(4))
AuthData ::= OCTET STRING (SIZE (12..32))
Message ::= SEQUENCE
{ version INTEGER(0..99),
-- The version of the protocol defined here is equal to 1.
mId MId, -- Name/address of message originator
messageBody CHOICE
{
messageError ErrorDescriptor,
transactions SEQUENCE OF Transaction
},
...
}
MId ::= CHOICE
{
ip4Address IP4Address,
ip6Address IP6Address,
domainName DomainName,
deviceName PathName,
mtpAddress OCTET STRING(SIZE(2)),
-- Addressing structure of mtpAddress:
-- 15 0
-- | PC | NI |
-- 14 bits 2 bits
...
}
DomainName ::= SEQUENCE
{
name IA5String,
-- The name starts with an alphanumeric digit followed by a
-- sequence of alphanumeric digits, hyphens and dots. No two
-- dots shall occur consecutively.
portNumber INTEGER(0..65535) OPTIONAL
}
{
address OCTET STRING (SIZE(4)),
portNumber INTEGER(0..65535) OPTIONAL
}
IP6Address ::= SEQUENCE
{
address OCTET STRING (SIZE(16)),
portNumber INTEGER(0..65535) OPTIONAL
}
PathName ::= IA5String(SIZE (1..64))
-- See section A.3
Transaction ::= CHOICE
{
transactionRequest TransactionRequest,
transactionPending TransactionPending,
transactionReply TransactionReply,
transactionResponseAck TransactionResponseAck,
-- use of response acks is dependent on underlying
transport
...
}
TransactionId ::= INTEGER(0..4294967295) -- 32 bit unsigned integer
TransactionRequest ::= SEQUENCE
{
transactionId TransactionId,
actions SEQUENCE OF ActionRequest,
...
}
TransactionPending ::= SEQUENCE
{
transactionId TransactionId,
...
}
TransactionReply ::= SEQUENCE
{
transactionId TransactionId,
immAckRequired NULL OPTIONAL, transactionResult
CHOICE
{
transactionError ErrorDescriptor,
actionReplies SEQUENCE OF ActionReply
},
...
}
TransactionResponseAck ::= SEQUENCE
{
firstAck TransactionId,
lastAck TransactionId OPTIONAL
}
ErrorDescriptor ::= SEQUENCE
{
errorCode ErrorCode,
errorText ErrorText OPTIONAL
}
ErrorCode ::= INTEGER(0..65535)
-- See section 13 for IANA considerations w.r.t. error codes
ErrorText ::= IA5String
ContextID ::= INTEGER(0..4294967295)
-- Context NULL Value: 0
-- Context CHOOSE Value: 429467294 (0xFFFFFFFE)
-- Context ALL Value: 4294967295 (0xFFFFFFFF)
ActionRequest ::= SEQUENCE
{
contextId ContextID,
contextRequest ContextRequest OPTIONAL,
contextAttrAuditReq ContextAttrAuditRequest OPTIONAL,
commandRequests SEQUENCE OF CommandRequest
}
ActionReply ::= SEQUENCE
{
contextId ContextID,
errorDescriptor ErrorDescriptor OPTIONAL,
contextReply ContextRequest OPTIONAL,
commandReply SEQUENCE OF CommandReply
}
ContextRequest ::= SEQUENCE
{
priority INTEGER(0..15) OPTIONAL,
emergency BOOLEAN OPTIONAL,
topologyReq SEQUENCE OF TopologyRequest OPTIONAL,
...
}
ContextAttrAuditRequest ::= SEQUENCE
{
topology NULL OPTIONAL,
emergency NULL OPTIONAL,
priority NULL OPTIONAL,
...
}
CommandRequest ::= SEQUENCE
{
command Command,
optional NULL OPTIONAL,
wildcardReturn NULL OPTIONAL,
...
}
Command ::= CHOICE
{
addReq AmmRequest,
moveReq AmmRequest,
modReq AmmRequest,
-- Add, Move, Modify requests have the same parameters
subtractReq SubtractRequest,
auditCapRequest AuditRequest,
auditValueRequest AuditRequest,
notifyReq NotifyRequest,
serviceChangeReq ServiceChangeRequest,
...
}
CommandReply ::= CHOICE
{
addReply AmmsReply,
moveReply AmmsReply,
modReply AmmsReply,
subtractReply AmmsReply,
-- Add, Move, Modify, Subtract replies have the same parameters
auditCapReply AuditReply,
auditValueReply AuditReply,
notifyReply NotifyReply,
serviceChangeReply ServiceChangeReply,
...
}
TopologyRequest ::= SEQUENCE
{
terminationFrom TerminationID,
terminationTo TerminationID,
topologyDirection ENUMERATED
{
bothway(0),
isolate(1),
oneway(2)
}
}
AmmRequest ::= SEQUENCE
{
terminationID TerminationIDList,
descriptors SEQUENCE OF AmmDescriptor,
-- At most one descriptor of each type (see AmmDescriptor)
-- allowed in the sequence.
...
}
AmmDescriptor ::= CHOICE
{
mediaDescriptor MediaDescriptor,
modemDescriptor ModemDescriptor,
muxDescriptor MuxDescriptor,
eventsDescriptor EventsDescriptor,
eventBufferDescriptor EventBufferDescriptor,
signalsDescriptor SignalsDescriptor,
digitMapDescriptor DigitMapDescriptor,
auditDescriptor AuditDescriptor,
...
}
AmmsReply ::= SEQUENCE
{
terminationID TerminationIDList,
terminationAudit TerminationAudit OPTIONAL,
...
}
SubtractRequest ::= SEQUENCE
{
terminationID TerminationIDList,
auditDescriptor AuditDescriptor OPTIONAL,
...
}
AuditRequest ::= SEQUENCE
{
terminationID TerminationID,
auditDescriptor AuditDescriptor,
...
}
AuditReply ::= SEQUENCE
{
terminationID TerminationID,
auditResult AuditResult,
...
}
AuditResult ::= CHOICE
{
contextAuditResult TerminationIDList,
terminationAuditResult TerminationAudit
}
TerminationAudit ::= SEQUENCE OF AuditReturnParameter
AuditReturnParameter ::= CHOICE
{
errorDescriptor ErrorDescriptor,
mediaDescriptor MediaDescriptor,
modemDescriptor ModemDescriptor,
muxDescriptor MuxDescriptor,
eventsDescriptor EventsDescriptor,
eventBufferDescriptor EventBufferDescriptor,
signalsDescriptor SignalsDescriptor,
digitMapDescriptor DigitMapDescriptor,
observedEventsDescriptor ObservedEventsDescriptor,
statisticsDescriptor StatisticsDescriptor,
packagesDescriptor PackagesDescriptor,
emptyDescriptors AuditDescriptor,
...
}
AuditDescriptor ::= SEQUENCE
{
auditToken BIT STRING
{
muxToken(0), modemToken(1), mediaToken(2),
eventsToken(3), signalsToken(4),
digitMapToken(5), statsToken(6),
observedEventsToken(7),
packagesToken(8), eventBufferToken(9)
} OPTIONAL,
...
}
NotifyRequest ::= SEQUENCE
{
terminationID TerminationIDList,
observedEventsDescriptor ObservedEventsDescriptor,
errorDescriptor ErrorDescriptor OPTIONAL,
...
}
NotifyReply ::= SEQUENCE
{
terminationID TerminationIDList OPTIONAL,
errorDescriptor ErrorDescriptor OPTIONAL,
...
}
ObservedEventsDescriptor ::= SEQUENCE
{
requestId RequestID,
observedEventLst SEQUENCE OF ObservedEvent
}
ObservedEvent ::= SEQUENCE
{
eventName EventName,
streamID StreamID OPTIONAL,
eventParList SEQUENCE OF EventParameter,
timeNotation TimeNotation OPTIONAL,
...
}
EventName ::= PkgdName
EventParameter ::= SEQUENCE
{
eventParameterName Name,
value Value
}
ServiceChangeRequest ::= SEQUENCE
{
terminationID TerminationIDList,
serviceChangeParms ServiceChangeParm,
...
}
ServiceChangeReply ::= SEQUENCE
{
terminationID TerminationIDList,
serviceChangeResult ServiceChangeResult,
...
}
-- For ServiceChangeResult, no parameters are mandatory. Hence the
-- distinction between ServiceChangeParm and ServiceChangeResParm.
ServiceChangeResult ::= CHOICE
{
errorDescriptor ErrorDescriptor,
serviceChangeResParms ServiceChangeResParm
}
WildcardField ::= OCTET STRING(SIZE(1))
TerminationID ::= SEQUENCE
{
wildcard SEQUENCE OF WildcardField,
id OCTET STRING(SIZE(1..8)),
...
}
-- See Section A.1 for explanation of wildcarding mechanism.
-- Termination ID 0xFFFFFFFFFFFFFFFF indicates the ROOT Termination.
TerminationIDList ::= SEQUENCE OF TerminationID
MediaDescriptor ::= SEQUENCE
{
termStateDescr TerminationStateDescriptor OPTIONAL,
streams CHOICE
{
oneStream StreamParms,
multiStream SEQUENCE OF StreamDescriptor
},
...
}
StreamDescriptor ::= SEQUENCE
{
streamID StreamID,
streamParms StreamParms
}
StreamParms ::= SEQUENCE
{
localControlDescriptor LocalControlDescriptor OPTIONAL,
localDescriptor LocalRemoteDescriptor OPTIONAL,
remoteDescriptor LocalRemoteDescriptor OPTIONAL,
...
}
LocalControlDescriptor ::= SEQUENCE
{
streamMode StreamMode OPTIONAL,
reserveValue BOOLEAN,
reserveGroup BOOLEAN,
propertyParms SEQUENCE OF PropertyParm,
...
}
StreamMode ::= ENUMERATED
{
sendOnly(0),
recvOnly(1),
sendRecv(2),
inactive(3),
loopBack(4),
...
}
-- In PropertyParm, value is a SEQUENCE OF octet string. When sent
-- by an MGC the interpretation is as follows:
-- empty sequence means CHOOSE
-- one element sequence specifies value
-- If the sublist field is not selected, a longer sequence means
-- "choose one of the values" (i.e. value1 OR value2 OR ...)
-- If the sublist field is selected,
-- a sequence with more than one element encodes the value of a
-- list-valued property (i.e. value1 AND value2 AND ...).
-- The relation field may only be selected if the value sequence
-- has length 1. It indicates that the MG has to choose a value
-- for the property. E.g., x > 3 (using the greaterThan
-- value for relation) instructs the MG to choose any value larger
-- than 3 for property x.
-- The range field may only be selected if the value sequence
-- has length 2. It indicates that the MG has to choose a value
-- in the range between the first octet in the value sequence and
-- the trailing octet in the value sequence, including the
-- boundary values.
-- When sent by the MG, only responses to an AuditCapability request
-- may contain multiple values, a range, or a relation field.
PropertyParm ::= SEQUENCE
{
name PkgdName,
value SEQUENCE OF OCTET STRING,
extraInfo CHOICE
{
relation Relation,
range BOOLEAN,
sublist BOOLEAN
} OPTIONAL,
...
}
Name ::= OCTET STRING(SIZE(2))
PkgdName ::= OCTET STRING(SIZE(4))
-- represents Package Name (2 octets) plus Property Name (2 octets)
-- To wildcard a package use 0xFFFF for first two octets, choose
-- is not allowed. To reference native property tag specified in
-- Annex C, use 0x0000 as first two octets.
-- Wildcarding of Package Name is permitted only if Property Name is
-- also wildcarded.
Relation ::= ENUMERATED
{
greaterThan(0),
smallerThan(1),
unequalTo(2),
...
}
LocalRemoteDescriptor ::= SEQUENCE
{
propGrps SEQUENCE OF PropertyGroup,
...
}
PropertyGroup ::= SEQUENCE OF PropertyParm
TerminationStateDescriptor ::= SEQUENCE
{
propertyParms SEQUENCE OF PropertyParm,
eventBufferControl EventBufferControl OPTIONAL,
serviceState ServiceState OPTIONAL,
...
}
EventBufferControl ::= ENUMERATED
{
off(0),
lockStep(1),
...
}
ServiceState ::= ENUMERATED
{
test(0),
outOfSvc(1),
inSvc(2),
...
}
MuxDescriptor ::= SEQUENCE
{
muxType MuxType,
termList SEQUENCE OF TerminationID,
nonStandardData NonStandardData OPTIONAL,
...
}
MuxType ::= ENUMERATED
{
h221(0),
h223(1),
h226(2),
v76(3),
...
}
StreamID ::= INTEGER(0..65535) -- 16 bit unsigned integer
EventsDescriptor ::= SEQUENCE
{
requestID RequestID,
eventList SEQUENCE OF RequestedEvent,
...
}
RequestedEvent ::= SEQUENCE
{
pkgdName PkgdName,
streamID StreamID OPTIONAL,
eventAction RequestedActions OPTIONAL,
evParList SEQUENCE OF EventParameter,
...
}
RequestedActions ::= SEQUENCE
{
keepActive BOOLEAN,
eventDM EventDM OPTIONAL,
secondEvent SecondEventsDescriptor OPTIONAL,
signalsDescriptor SignalsDescriptor OPTIONAL,
...
}
EventDM ::= CHOICE
{ digitMapName DigitMapName,
digitMapValue DigitMapValue
}
SecondEventsDescriptor ::= SEQUENCE
{
requestID RequestID,
eventList SEQUENCE OF SecondRequestedEvent,
...
}
SecondRequestedEvent ::= SEQUENCE
{
pkgdName PkgdName,
streamID StreamID OPTIONAL,
eventAction SecondRequestedActions OPTIONAL,
evParList SEQUENCE OF EventParameter,
...
}
SecondRequestedActions ::= SEQUENCE
{
keepActive BOOLEAN,
eventDM EventDM OPTIONAL,
signalsDescriptor SignalsDescriptor OPTIONAL,
...
}
EventBufferDescriptor ::= SEQUENCE OF EventSpec
EventSpec ::= SEQUENCE
{
eventName EventName,
streamID StreamID OPTIONAL,
eventParList SEQUENCE OF EventParameter,
...
}
SignalsDescriptor ::= SEQUENCE OF SignalRequest
SignalRequest ::=CHOICE
{
signal Signal,
seqSigList SeqSigList,
...
}
SeqSigList ::= SEQUENCE
{
id INTEGER(0..65535),
signalList SEQUENCE OF Signal
}
Signal ::= SEQUENCE
{
signalName SignalName,
streamID StreamID OPTIONAL,
sigType SignalType OPTIONAL,
duration INTEGER (0..65535) OPTIONAL,
notifyCompletion NotifyCompletion OPTIONAL,
keepActive BOOLEAN OPTIONAL,
sigParList SEQUENCE OF SigParameter,
...
}
SignalType ::= ENUMERATED
{
brief(0),
onOff(1),
timeOut(2),
...
}
SignalName ::= PkgdName
NotifyCompletion ::= BIT STRING
{
onTimeOut(0), onInterruptByEvent(1),
onInterruptByNewSignalDescr(2), otherReason(3)
}
SigParameter ::= SEQUENCE
{
sigParameterName Name,
value Value
}
RequestID ::= INTEGER(0..4294967295) -- 32 bit unsigned integer
ModemDescriptor ::= SEQUENCE
{
mtl SEQUENCE OF ModemType,
mpl SEQUENCE OF PropertyParm,
nonStandardData NonStandardData OPTIONAL
}
ModemType ::= ENUMERATED
{
v18(0),
v22(1),
v22bis(2),
v32(3),
v32bis(4),
v34(5),
v90(6),
v91(7),
synchISDN(8),
...
}
DigitMapDescriptor ::= SEQUENCE
{
digitMapName DigitMapName OPTIONAL,
digitMapValue DigitMapValue OPTIONAL
}
DigitMapName ::= Name
DigitMapValue ::= SEQUENCE
{
startTimer INTEGER(0..99) OPTIONAL,
shortTimer INTEGER(0..99) OPTIONAL,
longTimer INTEGER(0..99) OPTIONAL,
digitMapBody IA5String,
-- See Section A.3 for explanation of digit map syntax
...
}
ServiceChangeParm ::= SEQUENCE
{
serviceChangeMethod ServiceChangeMethod,
serviceChangeAddress ServiceChangeAddress OPTIONAL,
serviceChangeVersion INTEGER(0..99) OPTIONAL,
serviceChangeProfile ServiceChangeProfile OPTIONAL,
serviceChangeReason Value,
serviceChangeDelay INTEGER(0..4294967295) OPTIONAL,
-- 32 bit unsigned integer
serviceChangeMgcId MId OPTIONAL,
timeStamp TimeNotation OPTIONAL,
nonStandardData NonStandardData OPTIONAL,
}
ServiceChangeAddress ::= CHOICE
{
portNumber INTEGER(0..65535), -- TCP/UDP port number
ip4Address IP4Address,
ip6Address IP6Address,
domainName DomainName,
deviceName PathName,
mtpAddress OCTET STRING(SIZE(2)),
...
}
ServiceChangeResParm ::= SEQUENCE
{
serviceChangeMgcId MId OPTIONAL,
serviceChangeAddress ServiceChangeAddress OPTIONAL,
serviceChangeVersion INTEGER(0..99) OPTIONAL,
serviceChangeProfile ServiceChangeProfile OPTIONAL,
...
}
ServiceChangeMethod ::= ENUMERATED
{
failover(0),
forced(1),
graceful(2),
restart(3),
disconnected(4),
handOff(5),
...
}
ServiceChangeProfile ::= SEQUENCE
{
profileName Name,
version INTEGER(0..99)
}
PackagesDescriptor ::= SEQUENCE OF PackagesItem
PackagesItem ::= SEQUENCE
{
packageName Name,
packageVersion INTEGER(0..99),
...
}
StatisticsDescriptor ::= SEQUENCE OF StatisticsParameter
StatisticsParameter ::= SEQUENCE
{
statName PkgdName,
statValue Value
}
NonStandardData ::= SEQUENCE
{
nonStandardIdentifier NonStandardIdentifier,
data OCTET STRING
}
NonStandardIdentifier ::= CHOICE
{
object OBJECT IDENTIFIER,
h221NonStandard H221NonStandard,
experimental IA5String(SIZE(8)),
-- first two characters should be "X-" or "X+"
...
}
H221NonStandard ::= SEQUENCE
{ t35CountryCode1 INTEGER(0..255),
t35CountryCode2 INTEGER(0..255), -- country, as per T.35
t35Extension INTEGER(0..255), -- assigned nationally
manufacturerCode INTEGER(0..65535), -- assigned nationally
...
}
TimeNotation ::= SEQUENCE
{
date IA5String(SIZE(8)), -- yyyymmdd format
time IA5String(SIZE(8)) -- hhmmssss format
}
Value ::= OCTET STRING
END
A.3 Digit maps and path names
From a syntactic viewpoint, digit maps are strings with syntactic
restrictions imposed upon them. The syntax of valid digit maps is
specified in ABNF [RFC2234]. The syntax for digit maps presented in
this section is for illustrative purposes only. The definition of
digitMap in Annex B takes precedence in the case of differences
between the two.
digitMap = (digitString / LWSP "(" LWSP digitStringList LWSP ")"
LWSP)
digitStringList = digitString *( LWSP "/" LWSP digitString )
digitString = 1*(digitStringElement)
digitStringElement = digitPosition [DOT]
digitPosition = digitMapLetter / digitMapRange
digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP)
digitLetter = *((DIGIT "-" DIGIT) /digitMapLetter)
digitMapLetter = DIGIT ;digits 0-9
/ %x41-4B / %x61-6B ;a-k and A-K
/ "L" / "S" ;Inter-event timers
;(long, short)
/ "Z" ;Long duration event
DOT = %x2E ; "."
LWSP = *(WSP / COMMENT / EOL)
WSP = SP / HTAB
COMMENT = ";" *(SafeChar / RestChar / WSP) EOL
EOL = (CR [LF]) / LF
SP = %x20
HTAB = %x09
CR = %x0D
LF = %x0A
SafeChar = DIGIT / ALPHA / "+" / "-" / "&" / "!" / "_" / "/" /
"'" / "?" / "@" / "^" / "`" / "~" / "*" / "$" / "\" /
"(" / ")" / "%" / "."
RestChar = ";" / "[" / "]" / "{" / "}" / ":" / "," / "#" /
"<" / ">" / "=" / %x22
DIGIT = %x30-39 ; digits 0 through 9
ALPHA = %x41-5A / %x61-7A ; A-Z, a-z
A path name is also a string with syntactic restrictions imposed
upon it. The ABNF production defining it is copied from Annex B.
PathName = NAME *(["/"] ["*"] ["@"] (ALPHA / DIGIT)) ["*"]
NAME = ALPHA *63(ALPHA / DIGIT / "_" )
ANNEX B TEXT ENCODING OF THE PROTOCOL (NORMATIVE)
B.1 Coding of wildcards
In a text encoding of the protocol, while TerminationIDs are
arbitrary, by judicious choice of names, the wildcard character, "*"
may be made more useful. When the wildcard character is encountered,
it will "match" all TerminationIDs having the same previous and
following characters (if appropriate). For example, if there were
TerminationIDs of R13/3/1, R13/3/2 and R13/3/3, the TerminationID
R13/3/* would match all of them. There are some circumstances where
ALL Terminations must be referred to. The TerminationID "*"
suffices, and is referred to as ALL. The CHOOSE TerminationID "$" may
be used to signal to the MG that it has to create an ephemeral
Termination or select an idle physical Termination.
B.2 ABNF specification
The protocol syntax is presented in ABNF according to RFC2234.
; Boolean values, indicated in the text as True and False, are
; encoded as "On" and "Off", respectively, in the ABNF.
megacoMessage = LWSP [authenticationHeader SEP ] message
authenticationHeader = AuthToken EQUAL SecurityParmIndex COLON
SequenceNum COLON AuthData
SecurityParmIndex = "0x" 8(HEXDIG)
SequenceNum = "0x" 8(HEXDIG)
AuthData = "0x" 24*64(HEXDIG)
message = MegacopToken SLASH Version SEP mId SEP messageBody
; The version of the protocol defined here is equal to 1.
messageBody = ( errorDescriptor / transactionList )
transactionList = 1*( transactionRequest / transactionReply /
transactionPending / transactionResponseAck )
;Use of response acks is dependent on underlying transport
transactionPending = PendingToken EQUAL TransactionID LBRKT RBRKT
transactionResponseAck = ResponseAckToken LBRKT transactionAck
*(COMMA transactionAck) RBRKT
transactionAck = transactionID / (transactionID "-" transactionID)
transactionRequest = TransToken EQUAL TransactionID LBRKT
actionRequest *(COMMA actionRequest) RBRKT
actionRequest = CtxToken EQUAL ContextID LBRKT ((
contextRequest [COMMA commandRequestList])
/ commandRequestList) RBRKT
contextRequest = ((contextProperties [COMMA contextAudit])
/ contextAudit)
contextProperties = contextProperty *(COMMA contextProperty)
; at-most-once
contextProperty = (topologyDescriptor / priority / EmergencyToken)
contextAudit = ContextAuditToken LBRKT
contextAuditProperties *(COMMA
contextAuditProperties) RBRKT
; at-most-once
contextAuditProperties = ( TopologyToken / EmergencyToken /
PriorityToken )
commandRequestList= ["O-"] commandRequest *(COMMA ["O-"]
commandRequest)
commandRequest = ( ammRequest / subtractRequest / auditRequest
/ notifyRequest / serviceChangeRequest)
transactionReply = ReplyToken EQUAL TransactionID LBRKT
[ ImmAckRequiredToken COMMA]
( errorDescriptor / actionReplyList ) RBRKT
actionReplyList = actionReply *(COMMA actionReply )
actionReply = CtxToken EQUAL ContextID LBRKT
( errorDescriptor / commandReply ) RBRKT
commandReply = (( contextProperties [COMMA commandReplyList] )
/ commandReplyList )
commandReplyList = commandReplys *(COMMA commandReplys )
commandReplys = (serviceChangeReply / auditReply / ammsReply
/ notifyReply )
;Add Move and Modify have the same request parameters
ammRequest = (AddToken / MoveToken / ModifyToken ) EQUAL
TerminationID [LBRKT ammParameter *(COMMA
ammParameter) RBRKT]
;at-most-once
ammParameter = (mediaDescriptor / modemDescriptor /
muxDescriptor / eventsDescriptor /
signalsDescriptor / digitMapDescriptor /
eventBufferDescriptor / auditDescriptor)
ammsReply = (AddToken / MoveToken / ModifyToken /
SubtractToken ) EQUAL TerminationID [ LBRKT
terminationAudit RBRKT ]
subtractRequest = ["W-"] SubtractToken EQUAL TerminationID
[ LBRKT auditDescriptor RBRKT]
auditRequest = ["W-"] (AuditValueToken / AuditCapToken )
EQUAL TerminationID LBRKT auditDescriptor RBRKT
auditReply = (AuditValueToken / AuditCapToken )
( contextTerminationAudit / auditOther)
auditOther = EQUAL TerminationID LBRKT
terminationAudit RBRKT
terminationAudit = auditReturnParameter *(COMMA
auditReturnParameter)
contextTerminationAudit = EQUAL CtxToken ( terminationIDList /
LBRKT errorDescriptor RBRKT )
auditReturnParameter = (mediaDescriptor / modemDescriptor /
muxDescriptor / eventsDescriptor /
signalsDescriptor / digitMapDescriptor /
observedEventsDescriptor / eventBufferDescriptor /
statisticsDescriptor / packagesDescriptor /
errorDescriptor / auditItem )
auditDescriptor = AuditToken LBRKT [ auditItem
*(COMMA auditItem) ] RBRKT
notifyRequest = NotifyToken EQUAL TerminationID
LBRKT ( observedEventsDescriptor
[ COMMA errorDescriptor ] ) RBRKT
notifyReply = NotifyToken EQUAL TerminationID
[ LBRKT errorDescriptor RBRKT ]
serviceChangeRequest = ServiceChangeToken EQUAL TerminationID
LBRKT serviceChangeDescriptor RBRKT
serviceChangeReply = ServiceChangeToken EQUAL TerminationID
[LBRKT (errorDescriptor /
serviceChangeReplyDescriptor) RBRKT]
errorDescriptor = ErrorToken EQUAL ErrorCode
LBRKT [quotedString] RBRKT
ErrorCode = 1*4(DIGIT) ; could be extended
TransactionID = UINT32
mId = (( domainAddress / domainName )
[":" portNumber]) / mtpAddress / deviceName
; ABNF allows two or more consecutive "." although it is meaningless
; in a domain name.
domainName = "<" (ALPHA / DIGIT) *63(ALPHA / DIGIT / "-" /
".") ">"
deviceName = pathNAME
;The values 0x0, 0xFFFFFFFE and 0xFFFFFFFF are reserved.