summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3624.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3624.txt')
-rw-r--r--doc/rfc/rfc3624.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc3624.txt b/doc/rfc/rfc3624.txt
new file mode 100644
index 0000000..05c49df
--- /dev/null
+++ b/doc/rfc/rfc3624.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group B. Foster
+Request for Comments: 3624 D. Auerbach
+Category: Informational F. Andreasen
+ Cisco Systems
+ November 2003
+
+
+ The Media Gateway Control Protocol (MGCP) Bulk Audit Package
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+IESG Note
+
+ This document is being published for the information of the
+ community. It describes a non-IETF protocol that is currently being
+ deployed in a number of products. Implementers should be aware of
+ RFC 3015, which was developed in the IETF Megaco Working Group and
+ the ITU-T SG16, and which is considered by the IETF and the ITU-T to
+ be the standards-based (including reviewed security considerations)
+ way to meet the needs that MGCP was designed to address.
+
+Abstract
+
+ The base Media Gateway Control Protocol (MGCP) includes audit
+ commands that only allow a Call Agent to audit endpoint and/or
+ connection state one endpoint at a time. This document describes a
+ new MGCP package for bulk auditing of a group of gateway endpoints.
+ It allows a Call Agent to determine the endpoint naming convention,
+ the list of instantiated endpoints as well connection and endpoint
+ state for the group of endpoints.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Foster, et al. Informational [Page 1]
+
+RFC 3624 MGCP Bulk Audit Package November 2003
+
+
+Table of Contents
+
+ 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Bulk Audit Package. . . . . . . . . . . . . . . . . . . . . . 2
+ 2.1. Package Definition. . . . . . . . . . . . . . . . . . . 2
+ 2.1.1. Package Parameters . . . . . . . . . . . . . . . 3
+ 2.1.2. Bulk Auditing of Non-persistent Virtual
+ Endpoints. . . . . . . . . . . . . . . . . . . . 11
+ 2.1.3. Package Specific Return Codes. . . . . . . . . . 12
+ 2.2. Examples of Package Use . . . . . . . . . . . . . . . . 13
+ 2.2.1. Endpoint List. . . . . . . . . . . . . . . . . . 13
+ 2.2.2. Connection Count List. . . . . . . . . . . . . . 13
+ 2.2.3. Connection Mode List . . . . . . . . . . . . . . 15
+ 2.2.4. Endpoint State . . . . . . . . . . . . . . . . . 15
+ 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
+ 5. References. . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 6. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 18
+ 7. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19
+
+1. Introduction
+
+ The reader is assumed to be familiar with the base MGCP protocol [3].
+
+ The base Media Gateway Control Protocol (MGCP) [3] includes audit
+ commands that only allow a Call Agent to audit an endpoint and/or a
+ connection state, one endpoint at a time. This document describes a
+ new MGCP package for bulk auditing of a group of gateway endpoints.
+ It allows a Call Agent to determine the endpoint naming convention,
+ to determine the list of instantiated endpoints, and to determine the
+ connection and endpoint state for the group of endpoints. This is
+ particularly important in fail-over situations in which there are
+ gateways that have large numbers of endpoints.
+
+ 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 [2].
+
+2. Bulk Audit Package
+
+2.1. Package Definition
+
+ Package Name: BA
+
+ Package Version: 0
+
+
+
+
+Foster, et al. Informational [Page 2]
+
+RFC 3624 MGCP Bulk Audit Package November 2003
+
+
+ Package Description: This package provides the Call Agent the ability
+ to audit and obtain high-level view of endpoint and connection state
+ for a group of endpoints in a gateway.
+
+2.1.1. Package Parameters
+
+ A new BulkRequestedInfo parameter is defined for use in the
+ AuditEndpoint command. The parameter can be used to request a
+ compact list of EndpointIds or to request a high level view of
+ endpoint or connection state for a group of endpoints as defined
+ below:
+
+ ReturnCode,
+ [EndPointNameList,]
+ [InstantiatedEndpointList,]
+ [ConnectionCountList,]
+ [ConnectionModeList,]
+ [EndpointStateList,]
+ [NextEndpointName,]
+ [ReportedEndpointList]
+ <-- AuditEndPoint(EndpointId,
+ [StartEndpointName,]
+ [MaxNumEndpoints,]
+ [BulkRequestedInfo])
+
+ Unlike the normal RequestedInfo parameter in the base MGCP
+ specification, the BulkRequestedInfo parameter associated with the
+ Bulk Audits package can be used with "all-of" wildcards for auditing
+ a collection of endpoints. However, it is not an error to specify an
+ EndpointId without wildcards.
+
+ The following sub-sections describe the parameters associated with
+ the Bulk Audit Command in detail. Sections 2.1.1.1 and 2.1.1.2
+ describe the parameters that can be included with a request and
+ sections 2.1.1.3 to 2.1.1.8 describe return parameters.
+
+2.1.1.1. StartEndpointName and MaxNumEndpoints Parameters
+
+ Because wild-carding may not be sufficient to qualify the endpoints
+ of interest, further qualification can be provided by including a
+ StartEndpointName (the first endpoint of interest) and
+ MaxNumEndPoints (the maximum number of endpoints of interest). These
+ parameters are described according to the following Augmented BNF
+ (ABNF) Syntax (refer to RFC 2234 for ABNF syntax definitions [1]):
+
+ "BA/SE" ":" 0*WSP LocalEndpointName
+
+ "BA/NU" ":" 0*WSP MaxNumEndpoints
+
+
+
+Foster, et al. Informational [Page 3]
+
+RFC 3624 MGCP Bulk Audit Package November 2003
+
+
+ where MaxNumEndpoints is the decimal number of endpoints with a value
+ in the range 1 to 65535. The MaxNumEndpoints parameter SHOULD only
+ be included when requesting an audit for an EndpointStateList and/or
+ ConnectionCountList. If included in a request for the
+ EndPointNameList or InstantiatedEndpointList, it MAY be ignored.
+
+ Note that only the LocalEndpointName (see ABNF grammar in [3]) is
+ provided in request and response parameter lines for this package
+ rather than the full EndpointName. This is done for the sake of
+ compactness, i.e., the domain name portion is left out since it is
+ already available in the command line portion of a given request.
+
+ If the list of endpoints defined by the StartEndpointName and
+ MaxNumEndPoints is outside the range designated by the wild-carding,
+ a report will only be returned for endpoints up to those specified
+ within the wild-card range.
+
+2.1.1.2. BulkRequestedInfo Parameter
+
+ The BulkRequestedInfo parameter line is described according to the
+ following ABNF syntax definitions:
+
+ BulkRequestedInfo = "BA/F:" 0*WSP
+ *( EndpointOrInstantList *("," EndpointOrInstantList))
+ / *( EndpointOrConnState *("," EndpointOrConnState))
+
+ EndpointOrConnState = "BA/C" / "BA/M" / EndpointStateParam
+
+ EndpointOrInstantList = "BA/Z" / "BA/X"
+
+ EndpointStateParam = "BA/S" "(" StateType
+ 0*("," 0*(WSP) StateType)")"
+
+ StateType = "I" / "D" / "N" / "S" / "H"
+
+ where the BulkRequestedInfo parameters have the following meaning:
+
+ * "BA/Z" is a request to return EndPointNameList
+ * "BA/X" is a request to return InstantiatedEndpointList
+ * "BA/C" is a request to return the ConnectionCountList
+ * "BA/M" is a request to return the ConnectionModeList
+ * "BA/S" is a request to return the EndpointStateList
+
+ Each of the parameters can be provided at most once in the
+ BulkRequestedInfo.
+
+
+
+
+
+
+Foster, et al. Informational [Page 4]
+
+RFC 3624 MGCP Bulk Audit Package November 2003
+
+
+ EndpointStateParam Parameter:
+
+ As indicated in the above ABNF, the EndpointStateParam parameter is
+ itself parameterized with one or more StateType parameters that
+ define the conditions to be evaluated for the endpoint:
+
+ * "I" - the endpoint is in-service,
+ * "D" - the endpoint is disconnected (see sections 4.3 and 4.4.7 of
+ [3] for a discussion on disconnected endpoints),
+ * "N" - the endpoint is in the notification state,
+ * "L" - the endpoint is in lockstep state (i.e., waiting for an RQNT
+ after a response to a NTFY has occurred while in lockstep mode)
+ * "S" - there is an active on-off (OO) or timeout (TO) signal on the
+ endpoint,
+ * "H" - the endpoint is in some state other than "idle". The
+ meaning of this last parameter depends on the type of endpoint:
+ * The parameter has no meaning for endpoints that only provide
+ bearer services (with no state that the endpoint is aware of).
+ In this case, the condition is always evaluated to false
+ (corresponding to "idle").
+ * For endpoints that have a state machine associated with them
+ (such as a CAS endpoint), the endpoint MUST be in some state
+ other than the "idle" state in order for the condition to be
+ evaluated as true.
+ * In the case where the endpoint has hook-state associated with
+ it, the hook-state MUST be off-hook. In the case of digital
+ channel associated signaling (CAS) connections, hook-state may
+ be provided in either direction. If the hook-state in either
+ direction is off-hook, the endpoint is considered non-idle,
+ i.e., the condition is satisfied.
+
+ The list of StateTypes may be extended in the future. If an unknown
+ StateType is encountered, the command MUST be rejected with error
+ code 803 (i.e., "unsupported StateType").
+
+ The report, provided as a result of this request, yields an
+ indication of either "True", "False", or "Out of Service" for each
+ endpoint. If the endpoint is in-service and any one of the criteria
+ holds true, then the report for the endpoint will evaluate to "True".
+ A "False" indication will only be reported if the endpoint is in-
+ service and all criteria evaluate to false. The report thus provides
+ the logical "OR" function over the conditions audited for endpoints
+ in-service. Irrespective of the state being audited, an "Out of
+ Service" indication will always be reported if the endpoint is
+ considered out-of-service.
+
+
+
+
+
+
+Foster, et al. Informational [Page 5]
+
+RFC 3624 MGCP Bulk Audit Package November 2003
+
+
+ Note that the criteria "D", "N", "L", "S" and "H" can only be true if
+ the endpoint is in-service, so that requesting "I" at the same time
+ (although allowed) would be unnecessary (i.e., redundant).
+
+ Example: If the request for EndpointStateList for one or more
+ endpoints includes the parameter line:
+
+ BA/F: BA/S(D,N)
+
+ indicating a request for a report on whether endpoints are
+ disconnected or in the notification state. If a given endpoint is in
+ either a "disconnected" or "notification" state, then the report will
+ indicate "True" for that endpoint. If the endpoint is neither in a
+ disconnected state nor in a notification state, but is in-service,
+ then the report for that endpoint will indicate "False". If the
+ endpoint is out-of-service, then the report for that endpoint will
+ indicate "Out of Service".
+
+ In order to only determine whether an endpoint is in-service or out-
+ of service, the Call Agent should make a request with only the "I"
+ StateType parameter.
+
+2.1.1.3. EndPointNameList and InstantiatedEndpointList Parameters
+
+ EndPointNameList Parameter:
+
+ The EndPointNameList is a list of the endpoint names (i.e., the
+ endpoint naming convention for the endpoints configured for service)
+ supported by the gateway as qualified by the wildcarded EndPointId,
+ and possibly StartEndPointName and MaxNumEndpoints parameters. This
+ list can include one or more lines in the following ABNF format:
+
+ "BA/Z:" 0*WSP RangedLocalName 0*("," 0*WSP RangedLocalName)
+
+ where RangedLocalName is a LocalEndpointName that may include the
+ ranged wildcard notation described in Appendix E (section E.5) of
+ [3], i.e.,:
+
+ RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]"
+ NumericalRange = 1*(DIGIT) [ "-" 1*(DIGIT) ].
+
+ Example:
+
+ ba/z: ds/ds1-1/[1-24], ds/ds1-2/[1-24], ds/ds1-3/[1-24]
+
+ or simply:
+
+ ba/z: ds/ds1-[1-3]/[1-24]
+
+
+
+Foster, et al. Informational [Page 6]
+
+RFC 3624 MGCP Bulk Audit Package November 2003
+
+
+ Note that, since range wildcards use the character "[" to indicate
+ the start of a range, the "[" character MUST NOT be used in endpoint
+ names that use range wildcards.
+
+ Note that the ranged wildcard notation (RangeWildcard above) also
+ allows commas between ranges like:
+
+ ba/z: ds/ds1-1/[1,3-5,8-24]
+
+ For virtual endpoints, that are automatically created and deleted on
+ the fly by the gateway, there is a difference between reporting the
+ endpoint names (i.e., the "naming convention") used in describing the
+ endpoints and reporting the actual endpoints that are instantiated at
+ the time the request is made. For this case:
+
+ * EndPointNameList is a request to return the naming convention and
+
+ * InstantiatedEndpointList is a request to return the "real" (or
+ instantiated) endpoints.
+
+ InstantiatedEndpointList Parameter:
+
+ The syntax of the InstantiatedEndpointList value is the same as
+ the EndPointNameList value returned with EndPointNameList, i.e., a
+ number of lines may be returned with the following syntax:
+
+ "BA/X:" 0*WSP RangedLocalName 0*("," 0*WSP RangedLocalName)
+
+ In the case of hard-wired/physical endpoints (such as DSO's) or other
+ persistent endpoints, the InstantiatedEndpointList would normally not
+ be requested. However, if it is requested, the
+ InstantiatedEndpointList and the EndPointNameList will be the same.
+
+ For virtual endpoints that are not persistent, an "all of" wild card
+ ("*") is returned for the leftmost term of the name, which is
+ dynamically assigned in the EndPointNameList to indicate that
+ arbitrary names apply, and that the endpoints are virtual and non-
+ persistent. The "all of" wild card notation MUST NOT be used when
+ returning the EndPointNameList for persistent endpoints however. The
+ following example illustrates this:
+
+ ba/z: announcement/*
+ ba/z: foo/bar/*
+ ba/z: foo/foo/*
+
+
+
+
+
+
+
+Foster, et al. Informational [Page 7]
+
+RFC 3624 MGCP Bulk Audit Package November 2003
+
+
+ The "all of" wildcard tells us, that "announcement" is simply the
+ leftmost term for a dynamic set of non-persistent virtual endpoints.
+ To instantiate one of these endpoints, we would include the "any of"
+ wildcard (e.g., "announcement/$") as the LocalEndpointName in the
+ EndpointId of a request (e.g., NotificationRequest or
+ CreateConnection). The response would then include the
+ SpecificEndpointId indicating the instantiated endpoint. Also, note
+ in the above example that "foo" defines two different levels of non-
+ persistent virtual endpoints.
+
+2.1.1.4. ConnectionCountList
+
+ The ConnectionCountList indicates the number of connections on a
+ series of endpoints. It consists of a number of lines with the
+ following ABNF syntax:
+
+ "BA/C:" 0*WSP NumConnections 0*(NumConnections)
+
+ where NumConnections is either:
+
+ * a hexadecimal digit indicating the number of connections on the
+ endpoint corresponding to the position on the list, or
+
+ * the letter "Z" indicating that there are more than 15 connections
+ on this endpoint.
+
+2.1.1.5. ConnectionModeList
+
+ The ConnectionModeList indicates the connection modes for all the
+ connections on a series of endpoints. It consists of a number of
+ lines with the following ABNF syntax:
+
+ "BA/M:" 0*WSP ModeOrCount 0*(ModOrCount)
+
+ ModeOrCount = ConnCount / ConnMode
+
+ ConnMode = "I" / "S" / "R" / "B" / "C" / "L" / "T" / "N" / "U"
+
+ where ConnCount is either hexadecimal value corresponding to 0-15
+ connections on an endpoint or the value "Z", indicating that more
+ than 15 connections are present.
+
+
+
+
+
+
+
+
+
+
+Foster, et al. Informational [Page 8]
+
+RFC 3624 MGCP Bulk Audit Package November 2003
+
+
+ ConnMode indicates the connection mode where:
+
+ * "I" indicates "inactive" connection mode
+ * "S" indicates "sendonly" connection mode
+ * "R" indicates "recvonly" connection mode
+ * "B" indicates "sendrecv" connection mode
+ * "C" indicates "confrnce" connection mode
+ * "L" indicates "loopback" connection mode
+ * "T" indicates "conttest" connection mode
+ * "N" indicates "netwloop" connection mode
+ * "U" indicates some other connection mode
+
+ For a definition of MGCP connection modes, refer to section 3.2.2.6
+ of [3].
+
+ If an endpoint has no connections on it, ModeOrCount is given the
+ value "0". If there is one connection associated with the endpoint,
+ the symbol for the connection mode (ConnMode) is provided. If, on
+ the other hand, there are from 2 to 15 connections, a symbol
+ representing the number of connections (ConnCount) is provided
+ followed by a list of symbols indicating the connection mode
+ (ConnMode) for each connection. If there are more than 15
+ connections, "Z" is indicated for ConnCount and no connection modes
+ are provided for the connections on that endpoint.
+
+2.1.1.6. EndpointStateList Parameter
+
+ The EndpointStateList gives an overview of the endpoint state for a
+ series of endpoints. It consists of a number of lines with the
+ following ABNF syntax:
+
+ "BA/S:" 0*WSP EndPointState 0*(EndPointState)
+
+ EndPointState = "T" / "F" / "O"
+
+ where:
+
+ * "T" indicates "True"
+ * "F" indicates "False"
+ * "O" indicates "Out of Service"
+
+ The "True" or "False" determination is based on the criteria supplied
+ in StateType parameters when the request is made.
+
+ Note that the EndPointState indicator does not say anything about the
+ connection state of the endpoint.
+
+
+
+
+
+Foster, et al. Informational [Page 9]
+
+RFC 3624 MGCP Bulk Audit Package November 2003
+
+
+2.1.1.7. NextEndpointName Parameter
+
+ The NextEndpointName parameter will be included in the return, if
+ there are additional endpoints in this gateway covered by the wild-
+ carded endpoint name that were not reported, but for which
+ information was available to be reported.
+
+ Note that the NextEndpointName is the LocalEndpointName (as opposed
+ to EndpointName) of the next endpoint after the last endpoint
+ reported. The syntax is as follows:
+
+ "BA/NE" ":" 0*WSP LocalEndpointName
+
+ A gateway may supply a report that is shorter than the request if the
+ resulting report would have resulted in a message that would be too
+ large (i.e., such that the report is larger than the maximum datagram
+ size). In the case where the gateway supplied a response for less
+ endpoints than requested, the gateway MUST supply NextEndpointName in
+ the response.
+
+ In order to continue the audit on a following set of endpoints, the
+ Call Agent can make a further request by using the NextEndpointName
+ as the starting point (e.g., as the StartEndpointName in a following
+ request).
+
+2.1.1.8. ReportedEndpointList Parameter
+
+ A ReportedEndpointList MUST be provided in a response line before
+ list(s) of EndpointStateList and/or ConnectionCountList in order to
+ clearly specify the list of endpoints that are being reported. The
+ ABNF syntax is as follows:
+
+ "BA/EL:" 0*WSP LimitedRangedName 0*("," 0*WSP LimitRangedName)
+
+ where LimitedRangedName is a LocalEndpointName that may include a
+ ranged wildcard notation (RangeWildcard syntax indicated earlier).
+ However, unlike the RangedLocalName that allows the range wildcard
+ notation to be used on multiple terms of the local name at the same
+ time, LimitedRangedName only allows the range notation to be used for
+ the last term, i.e., the following is valid:
+
+ ba/el: ds/ds1-1/[1,3-5,8-24]
+
+ or
+
+ ba/el: ds/ds1-1/[1-24], ds/ds1-2/[1-24], ds/ds1-3/[1-24]
+
+
+
+
+
+Foster, et al. Informational [Page 10]
+
+RFC 3624 MGCP Bulk Audit Package November 2003
+
+
+ However, the following is not valid:
+
+ ba/el: ds/ds1-[1-3]/[1-24]
+
+ Note that a single bulk audit request may include a request to return
+ both ConnectionCountList and EndpointStateList. However, the
+ resulting report that includes both MUST cover the same endpoints.
+
+ A single bulk audit request may also include a request to return both
+ EndPointNameList and InstantiatedEndpointList. However, requests for
+ either an EndPointNameList and/or an InstantiatedEndpointList MUST
+ NOT include a request for either ConnectionCountList or
+ EndpointStateList.
+
+2.1.2. Bulk Auditing of Non-persistent Virtual Endpoints
+
+ Note that gateways that have non-persistent virtual endpoints may
+ have instantiated endpoints that are disjoint with respect to the
+ name space. The ReportedEndpointList in front of a
+ ConnectionCountList and/or EndpointStateList describes exactly which
+ endpoints are being reported.
+
+ Example:
+
+ A Call Agent requests to know about the EndPointNameList for the
+ endpoints on a conference bridge:
+
+ AUEP 1200 *@gw1.x.net MGCP 1.0
+ BA/F: BA/Z
+
+ Response:
+
+ 200 1200 OK
+ ba/z: cnf/*
+
+ This indicates the naming convention but in fact not all of these
+ endpoints are instantiated. A request for the list of instantiated
+ endpoints, i.e.,:
+
+ AUEP 1201 cnf/*@gw1.x.net MGCP 1.0
+ BA/F: BA/X
+
+ might yield:
+
+ 200 1201 OK
+ ba/x: cnf/[1-3]
+ ba/x: cnf/[6-12]
+
+
+
+
+Foster, et al. Informational [Page 11]
+
+RFC 3624 MGCP Bulk Audit Package November 2003
+
+
+ indicating that only these particular endpoints are instantiated.
+
+ Suppose the Call Agent now asks for the ConnectionCountList i.e.,:
+
+ AUEP 1202 cnf/*@gw1.x.net MGCP 1.0
+ BA/F: BA/C
+
+ The resulting instantiated virtual endpoints may be disjoint, which
+ would be indicated by the ReportedEndpointList in front of the
+ ConnectionCountList, e.g.,:
+
+ 200 1202 OK
+ ba/el: cnf/[1-3]
+ ba/c: 035
+ ba/el: cnf/[6-12]
+ ba/c: 3450333
+
+ or alternatively:
+
+ 200 1202 OK
+ ba/el: cnf/[1-3], ba/el: cnf/[6-12]
+ ba/c: 035
+ ba/c: 3450333
+
+ or
+
+ 200 1202 OK
+ ba/el: cnf/[1-3], ba/el: cnf/[6-12]
+ ba/c: 0353450333
+
+2.1.3. Package Specific Return Codes
+
+ The following return codes are specific to this package:
+
+ 800 Invalid NextEndpointName
+ 801 Invalid StartEndpointName
+ 802 Invalid or unsupported BulkRequestInfo Parameter
+ 803 Invalid or unsupported StateType
+ 804 Bulk Audit Type not supported
+ 805 Incorrectly specified endpoint range
+ 806 Requested StartEndpoint unknown or unavailable
+
+
+
+
+
+
+
+
+
+
+Foster, et al. Informational [Page 12]
+
+RFC 3624 MGCP Bulk Audit Package November 2003
+
+
+ Note that package specific error codes includes the package name
+ following the error code. For example, if error code 801 occurs in
+ response to a request with a transaction ID of 1001 it would be sent
+ as:
+
+ 801 1001 /BA
+
+2.2. Examples of Package Use
+
+2.2.1. Endpoint List
+
+ This section contains examples of how to obtain a list of endpoints.
+
+ Example 1: This is an example of a gateway that contains a single OC3
+ that contains a single level of hierarchy at the T1 level.
+
+ The request is made:
+
+ AUEP 1200 *@gw1.x.net MGCP 1.0
+ BA/F: BA/Z
+
+ This may result in a single "BA/Z" term with ranges specifying all of
+ the endpoints.
+
+ 200 1200 OK
+ ba/z: ds/ds1-[1-84]/[1-24]
+
+ Example 2: In this example the gateway has 10 analog lines and a
+ single T1. The same request is made as in example 1, but now the
+ response is:
+
+ 200 1200 OK
+ ba/z: aaln/[1-10]
+ ba/z: ds/ds1-1/[1-24]
+
+2.2.2. Connection Count List
+
+ Example1: Audit the number of connections on endpoints of a single
+ E1:
+
+ AUEP 2111 ds/e1-3/*@gw1.net
+ BA/F: BA/C
+
+ Response:
+
+ 200 2111 OK
+ BA/EL: ds/e1-3/[1-30]
+ BA/C: 012111210001000001000001000010
+
+
+
+Foster, et al. Informational [Page 13]
+
+RFC 3624 MGCP Bulk Audit Package November 2003
+
+
+ Example 2: Audit the number of connections on endpoints of a DS3:
+
+ AUEP 1144 ds/ds3-1/*@gateway.net
+ BA/F: BA/C
+
+ Response:
+
+ 200 1144 OK
+ BA/EL: ds/ds3-1/[1-192]
+ BA/C: 010000010001000001000001
+ BA/C: 001000000101000000001001
+ :
+ BA/C: 011000100010000010000010
+ BA/C: 011111010001000001000001
+ BA/C: 011000001100000001000001
+ BA/NE: ds/ds3-1/193
+
+ In this case, the response provided by the gateway contained
+ information about the first 192 endpoints. If the ds-3 contained a
+ T1 hierarchy, the "BA/EL" and "BA/NE" values would indicate that
+ hierarchy e.g.,:
+
+ 200 1144 OK
+ BA/EL: ds/ds3-1/ds1-1/[1-24]
+ BA/C: 010000010001000001000001
+ BA/EL: ds/ds3-1/ds1-2/[1-24]
+ BA/C: 001000000101000000001001
+ :
+ BA/EL: ds/ds3-1/ds1-6/[1-24]
+ BA/C: 011000100010000010000010
+ BA/EL: ds/ds3-1/ds1-7/[1-24]
+ BA/C: 011111010001000001000001
+ BA/EL: ds/ds3-1/ds1-8/[1-24]
+ BA/C: 011000001100000001000001
+ BA/NE: ds/ds3-1/ds1-9/1
+
+ The Call Agent could continue to request endpoints by indicating the
+ starting endpoint where it left off, i.e., simply using the returned
+ "BE/NE" value as the "BA/SE" value for the next request:
+
+ AUEP 1145 ds/ds3-3/*@gw1.net
+ BA/F: BA/C
+ BA/SE: ds/ds3-1/ds1-9/1
+
+
+
+
+
+
+
+
+Foster, et al. Informational [Page 14]
+
+RFC 3624 MGCP Bulk Audit Package November 2003
+
+
+ Example 3: In this case, the Call Agent wants to know about the
+ connection state of 12 DS0's starting with the endpoint with the
+ LocalEndpointName "ds/ds3-1/ds1-6/4":
+
+ AUEP 1146 ds/ds3-1/*@gw1.net
+ BA/F: BA/C
+ BA/SE: ds/ds3-1/ds1-6/4
+ BA/NU: 12
+
+ Response:
+
+ 200 1144 OK
+ BA/EL: ds/ds3-1/ds1-6/[4-15]
+ BA/C: 011000010001
+ BA/NE: ds/ds3-1/ds1-6/16
+
+2.2.3. Connection Mode List
+
+ Example: Audit the connection modes for connections on the endpoints
+ of a single E1:
+
+ AUEP 2111 ds/e1-3/*@gw1.net
+ BA/F: BA/M
+
+ Response:
+
+ 200 2111 OK
+ BA/EL: ds/e1-3/[1-30]
+ BA/M: 0R2BRBBB2RRB000B00000B00000B0000B0
+
+ This shows that:
+
+ * Endpoint ds/e1-3/1 has no connections
+ * Endpoint ds/e1-3/2 has one connection and it is in "recvonly"
+ mode.
+ * Endpoint ds/e1-3/3 has two connections which are in "sendrecv" and
+ "recvonly" mode
+ * Endpoints ds/e1-3/4 to ds/e1-3/6 each have one connection - in
+ "sendrecv" mode in all cases
+ * Endpoints ds/e1-3/7 has two connections, both in "recvonly" mode
+ * etc.
+
+2.2.4. Endpoint State
+
+ Endpoint state requests and responses are similar. An example of
+ requesting endpoint state similar to example 3 in the previous
+ section:
+
+
+
+
+Foster, et al. Informational [Page 15]
+
+RFC 3624 MGCP Bulk Audit Package November 2003
+
+
+ AUEP 1150 ds/ds3-1/*@gw1.net
+ BA/F: BA/S(I)
+ BA/SE: ds/ds3-1/ds1-6/4
+ BA/NU: 12
+
+ Response:
+
+ 200 1150 OK
+ BA/EL: ds/ds3-1/ds1-6/[4-15]
+ BA/S: TOOTTOOTTOOT
+ BA/NE: ds/ds3-1/ds1-6/16
+
+ The request for in-service endpoints returns "True" for all endpoints
+ in-service, and "O" for all endpoints "Out of Service".
+
+ A similar request but with additional parameters might be:
+
+ AUEP 1151 ds/ds3-1/*@gw1.net
+ BA/F: BA/S(H,N)
+ BA/SE: ds/ds3-1/ds1-6/4
+ BA/NU: 12
+
+ Response:
+
+ 200 1151 OK
+ BA/EL: ds/ds3-1/ds1-6/[4-15]
+ BA/S: FFFTFFFFFFFO
+ BA/NE: ds/ds3-1/ds1-6/16
+
+ This indicates that at least one of the StateType parameters "H"
+ (off-hook) and "N" (notification state) evaluated to true for the
+ endpoints that have a "T" associated with then (i.e., ds/ds3-1/ds1-
+ 6/7 and ds/ds3-1/ds1-6/16 since the request started from ds/ds3-
+ 1/ds1-6/4). All other endpoints are neither off-hook nor in the
+ "notification state". Note that endpoint ds/ds3-1/ds1-6/15 is marked
+ as being out-of-service.
+
+ It is possible to request both connection state and endpoint state in
+ the same request such as:
+
+ AUEP 1151 ds/ds3-1/*@gw1.net
+ BA/F: BA/S(H,N), BA/C
+ BA/SE: ds/ds3-1/ds1-6/4
+ BA/NU: 12
+
+
+
+
+
+
+
+Foster, et al. Informational [Page 16]
+
+RFC 3624 MGCP Bulk Audit Package November 2003
+
+
+ In this case, the response might be:
+
+ 200 1151 OK
+ BA/EL: ds/ds3-1/ds1-6/[4-15]
+ BA/S: FFFTFFFFFFFO
+ BA/C: 011000010001
+ BA/NE: ds/ds3-1/ds1-6/16
+
+3. IANA Considerations
+
+ The MGCP package title, "Bulk Audit", with the name, "BA", has been
+ registered with IANA as indicated in Appendix C.1 in [3].
+
+4. Security Considerations
+
+ Section 5 of the base MGCP specification [3] discusses security
+ requirements for the base protocol, which apply equally to the
+ package defined in this document. Use of a security Protocol such as
+ IPsec [4, 5] that provides per message authentication and integrity
+ services is required in order to ensure that requests and responses
+ are obtained from authenticated sources and that messages have not
+ been modified. Without such services, gateways and Call Agents are
+ open to attacks.
+
+ For example, although audit requests from unauthorized sources will
+ not modify media gateway state, the information provided could be
+ used to locate idle endpoints, which could then lead to making
+ unauthorized calls. Similarly, an attack that modifies a response to
+ an audit returned to a Call Agent could lead to a denial of service
+ attack in which a Call Agent that is provided misinformation as to
+ endpoint state could take some incorrect action such as taking valid
+ calls out of service.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Foster, et al. Informational [Page 17]
+
+RFC 3624 MGCP Bulk Audit Package November 2003
+
+
+5. References
+
+ [1] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [3] Andreasen, F. and B. Foster, "Media Gateway Control Protocol
+ (MGCP) Version 1.0", RFC 3435, January 2003.
+
+ [4] Kent, S. and R. Atkinson, "Security Architecture for the
+ Internet Protocol", RFC 2401, November 1998.
+
+ [5] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
+ (ESP)", RFC 2406, November 1998.
+
+6. Authors' Addresses
+
+ Flemming Andreasen
+ Cisco Systems
+ 499 Thornall Street, 8th Floor
+ Edison, NJ 08837
+
+ EMail: fandreas@cisco.com
+
+
+ David Auerbach
+ Cisco Systems Inc.
+ 170 W. Tasman Drive
+ San Jose, CA, 95134
+
+ EMail: dea@cisco.com
+
+
+ Bill Foster
+ Cisco Systems
+
+ EMail: bfoster@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+Foster, et al. Informational [Page 18]
+
+RFC 3624 MGCP Bulk Audit Package November 2003
+
+
+7. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). 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 assignees.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Foster, et al. Informational [Page 19]
+