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
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
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:
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
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.
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
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.