Internet Engineering Task Force B. Foster Internet Draft D. Auerbach Document: F. Andreasen Category: Informational Cisco Systems Expires: November 2002 May 2002 MGCP Bulk Audits, Redirect and Reset Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document includes two new MGCP packages. The first package defines a bulk audit mechanism to determine connection and endpoint state for a group of endpoints. The second package provides a notified entity list parameter and mechanisms for redirecting and resetting a group of endpoints as well as indicating failover of a group 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. Foster et al. Informational [Page 1] MGCP Bulk Audits and Redirect May 2002 1. Introduction This document contains two packages to help manage gateways: * The bulk audit package allows a Call Agent to obtain an overview of endpoint and connection state for a list of endpoints. * The redirect and restart package allows a Call Agent to: * Provide a NotifiedEntityList (similar to a Notified Entity but allowing multiple domain names). * Provide a new NotifiedEntity or NotifiedEntityList for an "all of" wildcarded group of endpoints (i.e. re-direct a number of endpoints to a new Call Agent). * Reset and re-initialize a group of endpoints. * Indicate the occurrence of failover of a group of endpoints. 2.0. Bulk Audit Package 2.1. Package Definition Package Name: BA Package Version: 0 Package Description: This package provides the Call Agent the ability to audit and obtain high-level overview 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 illustrated below: ReturnCode, [EndPointNameList,] [InstantiatedEndpointList,] [ReportedEndpointList,] [EndpointStateList,] [ConnectionCountList,] [NextEndpointName] <-- AuditEndPoint(EndpointId, [BulkRequestedInfo,] [StartEndpointName,] [MaxNumEndpoints]) Unlike the normal RequestedInfo parameter in the base MGCP specification, the BulkRequestedInfo parameter can be used with "all- Foster et al. Informational [Page 2] MGCP Bulk Audits and Redirect May 2002 of" wildcards for auditing a collection of endpoints. It is not an error to specify an EndpointId without wildcards, however. Because wild-carding may not be sufficient in terms of qualifying 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) parameters with the following ABNF syntax: * "BA/SE" ":" 0*WSP LocalEndpointName * "BA/NU" ":" 0*WSP MaxNumEndpoints where MaxNumEndpoints is the decimal number of endpoints with a value in the range 1 to 65535. 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. The list of endpoints defined by the StartEndpointName and MaxNumEndPoints MUST be within the range designated by the wild- carding. If there is an inconsistency (i.e. endpoints specified by StartEndpointName and MaxNumEndPoints are outside the range specified by the wildcard), error code 805 ("Incorrectly specified endpoint range") SHOULD be returned. The BulkRequestedInfo parameter line has the following ABNF format: BulkRequestedInfo = "BA/F:" 0*WSP *( EndpointOrInstantList *("," EndpointOrInstantList)) / *( EndpointOrConnState *("," EndpointOrConnState)) EndpointOrConnState = "BA/C" / 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/S" is a request to return the EndpointStateList Each of the parameters can be provided at most once in the BulkRequestedInfo. The EndpointStateList parameter is itself Foster et al. Informational [Page 3] MGCP Bulk Audits and Redirect May 2002 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, * "N" - the endpoint is in the notification state, * "S" - there is an active on-off (OO) or timeout (TO) signal on the endpoint, * "H" - the hook-state is off-hook or 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 stateless endpoints with no hook-state associated with them such as ISUP trunks. In this case, the endpoint is by definition in the "idle" state for this parameter. * 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 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. Note that the criteria "D", "N", "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, Foster et al. Informational [Page 4] MGCP Bulk Audits and Redirect May 2002 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. The EndPointNameList is a list of the endpoint names (i.e. the endpoint naming convention) 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 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.4) 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] Any EndpointId that has a local name that matches any of the values in the range notation is a valid endpoint. Since "[" is not a reserved character for endpoint names, an endpoint name that contains the character "[" SHALL escape each occurrence of the "[" character in the endpoint name by using an extra "[" character. For example, the endpoint name ds/ds1-1/foo[bar] is thus reported as ds/ds1-1/foo[[bar] Use of the "[" character in endpoint names for endpoints that support this package is discouraged. 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 Foster et al. Informational [Page 5] MGCP Bulk Audits and Redirect May 2002 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. The syntax of the InstantiatedEndpointList value is the same as the EndPointNameList value returned with EndPointNameList, i.e., a number of lines can be returned with the following syntax: "BA/X:" 0*WSP RangedLocalName 0*("," 0*WSP RangedLocalName) In the case of hard-wired/real 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 non-persistent virtual endpoints, 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/* 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 dynamic virtual endpoints. 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 hexa-decimal 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 Foster et al. Informational [Page 6] MGCP Bulk Audits and Redirect May 2002 connections on this endpoint. 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. 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 is 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. 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). 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 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 Foster et al. Informational [Page 7] MGCP Bulk Audits and Redirect May 2002 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] 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 cannot include a request for either ConnectionCountList or EndpointStateList. 2.1.2. Bulk Auditing of Dynamic Virtual Endpoints Gateways that have dynamic virtual endpoints may precede groups of ConnectionCountList or EndpointStateList lines with an InstantiatedEndpointList to indicate which endpoints the ConnectionCountList or EndpointStateList are referring to. This may be required because the instantiated endpoints may be disjoint with respect to the name space. 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: Foster et al. Informational [Page 8] MGCP Bulk Audits and Redirect May 2002 200 1201 OK ba/x: cnf/[1-3] ba/x: cnf/[6-12] 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 Ranged Local Name 802 Invalid or unsupported BulkRequestInfo Parameter 803 Invalid or unsupported StateType 804 Bulk Audit Type not supported 805 Incorrectly specified endpoint range 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 Foster et al. Informational [Page 9] MGCP Bulk Audits and Redirect May 2002 2.2. Examples of Package Use 2.2.1. Endpoint List This section contains examples of obtaining the 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 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 Foster et al. Informational [Page 10] MGCP Bulk Audits and Redirect May 2002 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 Foster et al. Informational [Page 11] MGCP Bulk Audits and Redirect May 2002 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. 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 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. Foster et al. Informational [Page 12] MGCP Bulk Audits and Redirect May 2002 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.0. Redirect and Reset Package Package Name: RED Version: 0 Package Description: The purpose of this package is to: * Introduce a new NotifiedEntityList extension parameter. This works the same as the NotifiedEntity parameter but allows more than one domain name to be specified. * Allow a Call Agent to pass a new NotifiedEntity or NotifiedEntityList to a collection of endpoints specified by an "all of" wild card. This is useful in the case where a new Call Agent takes over from a previous one and wants to re-direct endpoint(s) to send "Notifies" etc. to it from now on without interfering with current event processing. * Allow a Call Agent to request a group of endpoints to do a reset. * Provide a new restart method parameter to indicate the occurrence of a failover of a group of endpoints in the gateway. 3.1. NotifiedEntityList Extension Parameter The NotifiedEntityList parameter parameter is encoded as "NL" and is followed by a colon and a comma-separated list of NotifiedEntity values as defined in the MGCP specification [3], e.g.: RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net The NotifiedEntityList works similar to the NotifiedEntity parameter, except that it allows multiple domain names to be listed. The NotifiedEntityList thus specifies a new "notified entity" for the endpoint. The NotifiedEntityList parameter is optional in any command or response where the NotifiedEntity parameter is allowed. Following a restart, the NotifiedEntityList is initially empty, unless provisioned otherwise. In subsequent commands, it retains its current Foster et al. Informational [Page 13] MGCP Bulk Audits and Redirect May 2002 value until explicitly changed. If both a NotifiedEntity parameter and a non-empty NotifiedEntityList parameter have been set, the NotifiedEntity parameter value will be viewed as implicitly added to the beginning of the NotifiedEntityList parameter. The NotifiedEntity parameter thus always defines the first domain name to contact, unless it has explicitly been set to empty. In that case, the NotifiedEntity list defines the ônotified entityö. If the NotifiedEntity list is also empty, then the normal MGCP handling of having an empty ônotified entityö applies. We will refer to the list of domain names that result from the above rules as the ônotified entity listö. When the ônotified entity listö is non-empty, transmission is first attempted with the first domain name in the list as in normal MGCP retransmission. Each of the IP-addresses for this domain name MUST first be tried as specified in [3], and if this is unsuccessful, each of the IP-addresses for the second domain name MUST then be attempted, etc. following the normal MGCP retransmission procedures, with "N" set to zero for each domain name (see Section 4.3 in [3]). The exponential back-off considerations that apply to the changes between IP-addresses for a single domain name SHOULD also apply to IP-addresses for multiple domain names (this is to avoid a congestion collapse at the expense of a potentially slightly slower fail-over). Note that the maximum transaction lifetime considerations apply as usual, and hence retransmission to any of the IP-addresses MUST NOT occur more than T-Max seconds after the initial send of the command, irrespective of where it was sent to. The Max1 DNS query MAY be performed for each of the domain names, or it MAY simply be performed for the first. The Max2 DNS query however MUST NOT be performed for any but the last domain name. Also note, that only the last IP- address for the last domain name can reach Max2 retransmissions, and hence retransmission to all other IP-addresses MUST end after Max1 retransmissions. The current value of the NotifiedEntityList parameter can be audited via AuditEndpoint; the value of the NotifiedEntity parameter will not be included here and hence must be audited separately. Support for the NotifiedEntityList in AuditConnection is permissible, but neither required nor recommended. 3.2. Redirect Redirect uses the EndpointConfiguration command. A new NotifiedEntity parameter can be included with a "RED/N" parameter as follows: EPCF 1200 *@gw1.whatever.net MGCP 1.0 RED/N: ca1@ca1234.whatever.net This changes the "notified entity" for the endpoint(s) to the value specified. If the "all of" wildcard convention is used, the NotifiedEntity value replaces all of the existing "notified entities" for those endpoints. If NotifiedEntity is omitted in a subsequent EndpointConfiguration command, the "notified entity" remains unchanged. Foster et al. Informational [Page 14] MGCP Bulk Audits and Redirect May 2002 In the case where the "notified entity" is a domain name that resolves to multiple IP addresses: if one of the IP addresses is the IP address of the Call Agent sending the request, that IP address SHOULD be selected first. Otherwise, any one of the addresses MUST be selected. The NotifiedEntityList parameter can also be specified in a redirect endpoint configuration command, e.g.: EPCF 1200 *@gw1.whatever.net MGCP 1.0 RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net 3.3. Reset Another EndpointConfiguration parameter ("RED/R"), allows the Call Agent to reset one or more endpoints ("all-of" wildcard allowed). The ABNF syntax for the parameter line is as follows: "RED/R:" 0*WSP "reset" This has the effect of re-setting and re-initializing the specified endpoints (i.e. any connections on the endpoint will be deleted, and the endpoint will be returned to its clean default state without any active signals, etc.). The resulting "reset" has no affect on service state (whether the endpoint is in-service or out-of-service). 3.4 Failover Restart Method This package adds a new "failover" restart method in order to indicate that a failover has occurred in the gateway for the endpoints indicated. Example: RSIP 1200 ds/ds3-1/*@rgw-2567.whatever.net MGCP 1.0 RM: RED/failover The restart delay is always considered null in the case of the "failover" restart method, and hence the "restart delay" parameter MUST NOT be used with this restart method. 5.0. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Arango et al, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC XXXX {editors note - to be put in when RFC number is assigned to draft-andreasen-mgcp-rfc2705bis-04.txt) Foster et al. Informational [Page 15] MGCP Bulk Audits and Redirect May 2002 6.0. Authors' Addresses Flemming Andreasen Cisco Systems 499 Thornall Street, 8th Floor Edison, NJ 08837 EMail: fandreas@cisco.com David Auerbach Cisco Systems Europe 11, rue Camille Desmoulins 92782 Issy Les Moulineaux CEDEX 9 û France EMail: dea@cisco.com Bill Foster Cisco Systems EMail: bfoster@cisco.com 7.0. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Foster et al. Informational [Page 16] MGCP Bulk Audits and Redirect May 2002 Foster et al. Informational [Page 17]