Internet Engineering Task Force B. Foster Internet Draft C. Sivachelvan Document: F. Rednor Category: Informational Cisco Systems Expires: October 2002 April 2002 MGCP Return Code Usage 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 MGCP 1.0 provides a list of return codes with descriptions. This documents expands on the descriptions and provides some error categories as guidelines for use by Call Agents and gateways. 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 Return Code Usage April 2002 1.0. Introduction.....................................................2 2.0. Return Code Usage................................................2 2.1. Return Code Categories.........................................2 2.2. Return Code Descriptions.......................................4 3.0. Guidelines for Usage............................................16 3.1. Gateway Recommendations.......................................16 3.2. Call Agent Recommendations....................................17 4.0. Acknowledgements................................................17 5.0. References......................................................17 6.0. Authors' Addresses..............................................18 7.0. Full Copyright Statement........................................18 1.0. Introduction Although, some return codes in MGCP 1.0 [1] are indications of very specific situations, others are more generic in nature. It is not possible, nor is it necessary, to come up with an error code for all possible situations that might occur. Instead, the objective is to make sure that Call Agents behave the same for a given error situation that occurs in the gateway. This can be achieved if return codes are categorized according to a common expected behavior for the Call Agent. That way, if a certain situation occurs in the gateway that is not exactly described by one of the return codes in MGCP 1.0, the gateway developer can chose the most appropriate error code based on how he/she expects the Call Agent should behave in that situation. This document does not try to describe exactly how Call Agents behave. That is left to the specific Call Agent implementation. All that it attempts to do is try to provide categories and examples of their use. Note also that the focus is on return codes provided by gateways, resulting in certain behavior in the Call Agent (as opposed to the other way around). 2.0. Return Code Usage 2.1. Return Code Categories The following describe categorization of return codes from gateways based on expected Call Agent Behaviors. Category none (specific): a return code associated with a fairly specific situation in the gateway will likely invoke a specific Call Agent behavior based on that return code. As such, these return codes are not categorized into a common behavioral category. Category "Service Failure": a category in which the endpoint is either out of service or the treatment by the Call Agent is expected to be the same as for an out of service endpoint. Category "Provisioning Mismatch": a situation where the gateway has indicated that it does not support what the Call Agent has asked it Foster et al. Informational [Page 2] MGCP Return Code Usage April 2002 to do. This may be caused by a lack of synchronization between the provisioning of the Call Agent and the gateway. Note that attempts should be made to weed out these types of situations during integration testing. Category "Temporary Failure": the transient nature of this error is such that this particular call is likely to be permanently affected but later calls on the same endpoint may proceed successfully. Typically the situation that caused this error is not going to disappear unless there is some change in state in the gateway or network (e.g. more bandwidth becomes available, more CPU resources become available etc.). This situation is not likely to change in a few 10's of milliseconds but could change within some number of seconds or minutes later (as resources become free) i.e. within the time period that you might expect a different call to be tried on that endpoint. Category "State Mismatch": a case where there is a state mismatch between the Call Agent and gateway that can be resolved by the Call Agent making a request that is more appropriate to the gateway state. Although categorized with a common category indicator the behavior of the Call Agent will depend in the situation (the type of state mismatch that has occurred as well as other state information e.g. call state). Category "Remote Connection Descriptor Error": This indicates some mismatch between the two gateways involved in the call. Note that all gateways should ignore SDP attributes that they do not recognize (i.e. lack of recognition of an SDP attribute should not be the cause of an error indication). The exact behavior of the Call Agent for the above categories may depend on the type of endpoint (analog, ISUP trunk, CAS trunk etc.), whether this is the origination or termination endpoint in the call and possibly other information related to the call state. This document does not attempt to outline the Call Agent behaviors for these situations - but does recommend that similar Call Agent behavior should be invoked for return codes in the same category for categories: "Service Failure", "Provisioning Mismatch", "Temporary Failure" and "Remote Connection Descriptor Error". Foster et al. Informational [Page 3] MGCP Return Code Usage April 2002 A summary of the categories of the various errors codes is included in the following table. This information is also repeated in the detailed error descriptions in the next section. ------------------------------------------------------------------ | Category | Return Codes | |-------------|----------------------------------------------------| | none | 000, 100, 101, 200, 250, 405, 407, 410, 503, 510, | | | 521, 530, 533 | |-------------|----------------------------------------------------| | "Service | 501, 502, 520, 529, 531 | | Failure" | | |-------------|----------------------------------------------------| |"Provisioning| 500, 504, 506, 508, 511, 512, 513, 514, 517, | | Mismatch" | 518, 522, 523, 524, 525, 526, 528, 532, 534*, 535, | | | 536, 537, 538, 539, 541, | |-------------|----------------------------------------------------| | "Temporary | 400, 403, 404*, 406, 409 | | Failure" | | |-------------|----------------------------------------------------| | "State | 401, 402, 515, 516, 519, 540 | | Mismatch" | | |-------------|----------------------------------------------------| | "Remote | 505, 509, 527 | | Connection | | |Descriptor | | | Error" | | ------------------------------------------------------------------ * 534: See the note on return code 534 in the detailed description section (2.1) of this document (may be treated as a "Remote Connection Descriptor Error" if no local connection options were supplied. * 404: may be treated as a "Temporary Failure" but alternate behavior is possible (e.g. try an alternate codec with lower bandwidth requirement). 2.2. Return Code Descriptions This section provides more detailed descriptions of return codes from MGCP 1.0 with some example "situations" that may have been responsible, as well as the return code "category". Note that any indication that the response is valid for an RQNT is also an indication that it is valid for a connection request (CRCX, MDCX, DLCX) with an encapsulated RQNT. 000 - Response acknowledgement Expected use: final response after a provisional response (3-way handshake). Situation: If the final response that follows a provisional response contains an empty response acknowledge parameter, a Foster et al. Informational [Page 4] MGCP Return Code Usage April 2002 Response Acknowledgement is used to acknowledge the final response (section 3.5.6 of [1]). Category: none (specific situation and behavior). 100 - Provisional Response Response valid for: any command that may result in a transaction time greater than the normal retry timers. Situation: When a transaction is expected to take a processing time that is beyond the normal retry timer, the gateway will return a provisional response. A final response will be provided later, after the transaction has completed. Refer to section 3.5.6 of [1]. An example of this might be a create connection using RSVP, where the time to create the connection may be longer than usual because of the need to reserve the reservation Category: none (specific situation and behavior). 101 - Transaction has been queued for execution Response valid for: any command. Situation: the gateway is unable to complete the execution within the usual retry timers (example: gateway overloaded). A final response will be provided later, after the transaction has completed. In this case, the Call Agent should throttle back its request rate for this gateway. Category: none (specific situation and behavior). 200 - Transaction executed normally Response valid for: any command. Situation: Normal response as a result of successful execution. Note that it is recommended that the 250 response code should be used to acknowledge a successful completion of a DLCX command. However, a 200 response code should also be accepted as an appropriate response code. Category: none (normal execution) 250 - The connection was deleted Response valid for: DLCX. Situation: Response to a successful delete connection command. Category: none (normal execution) Foster et al. Informational [Page 5] MGCP Return Code Usage April 2002 400 - unspecified transient error Response valid for: any command. Situation: unspecified transient error. Category: "Temporary Failure". 401 - The Phone is already off-hook Response valid for: RQNT. Situation: This is returned in response to a request for an off- hook transition requested event when the phone is already off- hook. It is also returned when a request is made to generate a signal that is inappropriate for a phone that is off-hook - such as S: l/rg - request to ring the phone. It is also returned when requesting an incoming off-hook/seizure indication for a CAS trunk when the incoming hook-state for that trunk is already off-hook. Category: "State Mismatch". If the Call Agent makes the request with a requested event indicating a different hook-state, the request should not result in this return code again. 402 - The Phone is already on-hook Response valid for: RQNT. Situation: This is returned in response to a request for an on- hook (or hook-flash) requested event when the phone is already on-hook. It is also returned when a request is made to generate a signal that is inappropriate for a phone that is on-hook - such as S: l/dl - request to play some tone such as dial-tone. It is also returned when requesting an incoming off-hook/seizure indication for a CAS trunk when the incoming hook-state for that trunk is already off-hook. Category: "State Mismatch". If the Call Agent makes the request with a requested event indicating a different hook-state, the request should not result in this return code again. 403 - insufficient resources available at this time Response valid for: any command. Situation: This is returned if the request cannot be processed due to unavailability of pooled resources, such as CPU utilization, lack of DSP resources, lack of memory etc; however, the command may succeed at a later time when resources free up. Category: "Temporary Failure" Foster et al. Informational [Page 6] MGCP Return Code Usage April 2002 404 - insufficient bandwidth at this time. Response valid for: CRCX, MDCX. Situation: This is an indication that there is not enough bandwidth available to sustain the call. It is as a result of some bandwidth check (could be RSVP or some other mechanism). It is possible that the Call Agent could request a codec requiring lower bandwidth codec and have a successful result. Alternatively it could treat this as a "Temporary Failure" for this codec. Category: "Temporary Failure". Alternatively, as indicated above, the Call Agent could apply some specific behavior (try a lower bandwidth codec) depending on policy. 405 - endpoint is restarting Response valid for: any command. Situation: It is returned to requests made when the GW has initiated the Restart Procedures (RSIP) on an endpoint. If the request is made at a later time, it may be "successful" but may not be appropriate (because of possible state mismatch) depending on restart method that is associated with the RSIP. The Call Agent should proceed after the RSIP has been received. Category: none (specific situation and behavior). 406 - Transaction Timeout Response valid for: any command. Situation: The transaction took longer that expected. An example might be a transaction where a provisional response (100 response code) was returned. Following that the gateway determined that the actual transaction was taking longer than expected and as a result it timed out and returned 406 as the final response. Category: "Temporary Failure" 407 - Transaction aborted by some external action. Response valid for: any command. Situation: This is returned to indicate cancellation of a pending request. For example, DLCX is received while processing a CRCX or MDCX, or the same command is received with a different transaction Id. Category: none (specific situation and behavior). Foster et al. Informational [Page 7] MGCP Return Code Usage April 2002 409 - internal overload Response valid for: any command. Situation: Gateway is overloaded (e.g. too many requests per second from the Call Agent) and is unable to respond at this time. In this case, the Call Agent should throttle back its request rate for this gateway. Category: "Temporary Failure". 410 - no endpoint available Response valid for: RQNT, CRCX, MDCX with "any of" wildcard. Situation: Request was made with an "any of" or "$" wild card and no endpoint was available to execute the request. Category: none (specific situation and behavior). 500 - endpoint unknown Response valid for: any command. Situation: This could be the result of a provisioning mismatch between the Call Agent and the gateway or it could be because a card was removed from the gateway so that the endpoint is no longer available (in which case an RSIP should be received). Category: "Provisioning Mismatch". 501 - endpoint is not ready or is out of service Response valid for: any command. Situation: This is returned if the endpoint is in a permanent ônot readyö state. This includes maintenance states such as out of service. Category: "Service Failure". 502 - insufficient resources (permanent). Response valid for: any command. Situation: This is returned when the endpoint does not have sufficient resources and future requests on this endpoint are guaranteed to fail, meaning some resources dedicated to the endpoint are broken (e.g. return code 529 - "hardware failure" might be a more specific indication). For situations where resources may become available in the future (i.e. resources are pooled and not available at the present time), return code 403 should be used instead. Foster et al. Informational [Page 8] MGCP Return Code Usage April 2002 Category: "Service Failure". 503 - "All of" wildcard too complicated. Response valid for: any command. Situation: This is returned when the wildcard convention used in the request is understood, but the requested command cannot be processed with wildcarding. An example of this would be an RQNT with a request such that a failure would make it too difficult to roll back the state of all the endpoints to what they were prior to the request. The Call Agent should enumerate the requests (send them one at a time). Category: none (specific situation and behavior) 504 - unknown or unsupported command. Response valid for: an unknown command. Situation: command was requested other than those specified in the MGCP specification [1]. Category: "Provisioning Mismatch". 505 - Unsupported remote connection descriptor. Response valid for: CRCX, MDCX. Situation: one or more mandatory parameters or values in the RemoteConnectionDescriptor are not supported by the gateway. Category: "Remote Connection Descriptor Error". 506 - Inability to satisfy both local connection options and remote connection descriptor simultaneously. Response valid for: CRCX, MDCX. Situation: the LocalConnectionOptions and RemoteConnectionDescriptor contain one or more mandatory parameters or values that conflict with each other and/or cannot be supported at the same time (except for codec negotiation failure - see error code 534). Category: "Provisioning Mismatch". 508 - unknown or unsupported quarantine handling. Response valid for: RQNT. Situation: gateway does not support or does not recognize the quarantine handling parameter. Foster et al. Informational [Page 9] MGCP Return Code Usage April 2002 Category: "Provisioning Mismatch". 509 - Error in RemoteConnectionDescriptor Response valid for: CRCX, MDCX. Situation: There is a syntax or semantic error in the Remote Connection Descriptor. Category: "Remote Connection Descriptor Error". 510 - protocol error Response valid for: any command. Situation: Some unspecified protocol error was detected. Gateways should use this error as a last resort since it provides very little information. If used, some specific commentary should be including to aid in debug. Category: none. The Call Agent may want to do a retry before making a decision that this is a "Provisioning Mismatch" type of error. 511 - unrecognized extension. Response valid for: any command. Situation: It is returned if the requested command contains an unrecognized X+ extension. In MGCP 1.0, this specifically refers to unrecognized parameters, since other error codes are available for unrecognized connection modes (517), unrecognized packages (518), unrecognized local connection options (541) etc. Category: "Provisioning Mismatch". 512 - gateway not equipped to detect one of the requested events. Response valid for: RQNT. Situation: An event was requested that the gateway is not equipped to detect. Note that if the package is unknown or unsupported, then return code 518. Category: "Provisioning Mismatch". 513 - gateway is not equipped to generate one of the requested signals. Response valid for: RQNT. Foster et al. Informational [Page 10] MGCP Return Code Usage April 2002 Situation: An signal was requested that the gateway is not equipped to generate. Note that if the package is unknown or unsupported, then return code 518. Category: "Provisioning Mismatch". 514 - the gateway cannot send the specified announcement. Response valid for: RQNT with a request for an announcement to be played. Situation: this is a specific situation with respect to playing announcements on an endpoint or connection associated with the endpoint. Category: "Provisioning Mismatch". 515 - incorrect connection-id. Response valid for: CRCX, MDCX, DLCX, RQNT, AUCX. Situation: an invalid connection ID has been specified. It is possible that the connection has already been deleted. It should be noted that the connection Id can also supplied with events and signals (e.g., S: L/rt@connId). Category: "State Mismatch". 516 - unknown or incorrect call-id. Response valid for: MCDX, DLCX. Situation: unknown call-id, or the call-id supplied is incorrect (e.g. connection-id not associated with this call-id). Category: "State Mismatch". 517 - invalid or unsupported mode. Response valid for: CRCX, MCDX. Situation: This is returned if the command specifies a connection mode that the endpoint does not support (note that not all endpoint types will support all modes). Category: "Provisioning Mismatch". 518 - unsupported or unknown package. Response valid for: All Situation: A package name included in a request is not supported (or unknown). Note that the package name may be a prefix to an event or other things (e.g. a parameter) as defined in [1]. Note Foster et al. Informational [Page 11] MGCP Return Code Usage April 2002 that it is recommended to include a PackageList parameter with the list of supported packages in the response. Category: "Provisioning Mismatch". 519 - endpoint does not have a digit map. Response valid for: RQNT. Situation: Request was made to detect digits based on a digit map and the gateway does not have the digit map. Category: "State Mismatch". The Call Agent needs to send down a digit map in order to continue with the call. 520 - endpoint is restarting. Situation: This is normally a transient error so that error code 405 should be used. Gateways should not use this error code since it was included only to maintain backwards compatibility with previous releases of the MGCP specification. Category: If it is returned, this return code will be treated as category "Service Failure" - i.e. this endpoint is out of service. 521 - endpoint re-directed to another Call Agent. Response valid for: RSIP. Situation: RSIP was sent to the Call Agent and the Call Agent returns this return code along with a Notified Entity parameter pointing to another Call Agent. The gateway then re-sends the RSIP to the Call Agent specified in the Notified Entity. Category: none (specific situation and behavior). 522 - no such event or signal. Response valid for: RQNT. Situation: This is returned if the requested event/signal name is not registered with this package. If on the other hand the signal or event is part of the package but is not supported, by the gateway then return codes 512 or 513 should be provided instead. If the package is not supported, return code 518 should be returned. Category: "Provisioning Mismatch". 523 - unknown action or illegal combination of actions. Response valid for: RQNT with one or more requested events. Foster et al. Informational [Page 12] MGCP Return Code Usage April 2002 Situation: Request was made with a requested event(s) that included an action or actions that are either unknown, unsupported or an illegal combination as indicated in section 2.3.3 of [1]. Category: "Provisioning Mismatch". 524 - internal inconsistency in Local Connection Options Response valid for: CRCX, MDCX. Situation: This is returned if one or more of Local Connection Option parameters are coded with values that are not consistent with each other (e.g. with the network type). Category: "Provisioning Mismatch". 525 - unknown extension in Local Connection Options. Response valid for: CRCX, MDCX. Situation: This is returned if the request contains one or more unrecognized X+ extensions. Category: "Provisioning Mismatch". 526 - insufficient bandwidth Situation: In most cases where there is insufficient bandwidth, a 404 return code should be used. 526 would be used in cases where future requests are destined to fail. An example might be a very restricted bandwidth case, where there is not enough bandwidth available for the codec requested even for a single endpoint. Making a request with the same codec in the future will fail. However, making a request for some other codec (with a higher degree of compression) may pass. For cases, where the bandwidth is pooled over multiple endpoints and could free up at some future time (because an endpoint becomes inactive), then 404 is more appropriate. Category: If it is returned, this return code will be treated as category "Provisioning Mismatch" - e.g. the codec was incorrectly provisioned for the bandwidth available. 527 - missing Remote Connection Descriptor. Response valid for: CRCX, MDCX. Situation: This is returned if the request does not contain the Remote Connection Descriptor when one is required to support the request. Category: "Remote Connection Descriptor Error". Foster et al. Informational [Page 13] MGCP Return Code Usage April 2002 528 - incompatible protocol version Response valid for: any command. Category: "Provisioning Mismatch". 529 - Internal Hardware Error. Response valid for: any command. Situation: A hardware fault occurred during the execution of a command. Category: "Service Failure". 530 - CAS Signaling Protocol Error. Response valid for: RQNT. Situation: This is specific to Channel Associated Signaling interface. A typical example might be an attempt to outpulse digits failed for some reason. Category: none (specific situation and behavior). 531 - failure of a grouping of trunks (e.g. facility failure) Response valid for: any command. Situation: request made to an endpoint that has a failed trunk connection (e.g. T1 or E1 failed). Note that an RSIP should have been sent as a result of the facility failure. Category: "Service Failure". 532 - Unsupported value(s) in Local Connection Options. Response valid for: CRCX, MDCX. Situation: This is returned if one or more of the Local Connection Options parameters is coded with a value that the gateway does not support. Category: "Provisioning Mismatch". 533 - response too large Response valid for: AUEP. Situation: This would only likely to occur in the case of an audit where the maximum response packet size would end up being too large. Category: none (specific situation and behavior). Foster et al. Informational [Page 14] MGCP Return Code Usage April 2002 534 - codec negotiation failure Response valid for: CRCX, MDCX. Situation: The intersection between the list of codecs that the gateway supports, the codecs supplied in the local connection options and the codecs supplied in the Remote Connection Descriptor is empty. Category: "Provisioning Mismatch" (if local connection options were supplied) "Remote Connection Descriptor Error" if no local connection options were supplied. 535 - packetization period not supported Response valid for: CRCX, MDCX. Situation: the gateway is unable to support the packetization period specified in the local connection options for the codec indicated. Category: "Provisioning Mismatch". 536 - unknown or unsupported Restart Method Response valid for: RSIP. Category: "Provisioning Mismatch". 537 - unknown or unsupported digit map extension Response valid for: RQNT. Situation: digit map letter in the digit map unknown or unsupported. Category: "Provisioning Mismatch". 538 - event/signal parameter error Response valid for: RQNT. Situation: It is returned if the event/signal parameter is in error or not supported. If the event/signal of package is not supported, then one of 512, 513, 518, or 522 should be used instead. Category: "Provisioning Mismatch". 539 - invalid or unsupported command parameter Response valid for: any command. Foster et al. Informational [Page 15] MGCP Return Code Usage April 2002 Situation: This is returned if the command contains an invalid or unsupported parameter, which is neither a package (which would use return code 518) nor vendor specific extension (which would use return code 511). Category: "Provisioning Mismatch". 540 - per endpoint connection limit exceeded Response valid for: CRCX. Situation: A create connection was made, but the gateway cannot support any additional connections on that endpoint. Category: "State Mismatch". 541 - invalid or unsupported Local Connection Options Response valid for: CRCX, MDCX. Situation: This is returned if the command contains an invalid or unsupported Local Connection option, which is neither a package (which would use return code 518) nor vendor specific extension (which would use return code 511). Category: "Provisioning Mismatch". In the case where the error code is not recognized, the following behavior is assumed: 0XX - treated as a 000 (assumed to be a response acknowledgement) 1XX - treated as a 100 (provisional response), final response expected later. 2XX - treated as a 200 (successful response) 3XX - treated as a 521 (i.e. should only occur as a re-direct within an RSIP message) 4XX - treated as a 400 (Category "Temporary Failure") 5XX -9XX - treated as a 510. 3.0. Guidelines for Usage 3.1. Gateway Recommendations The following guidelines are recommended for gateway implementations: * For uncategorized return codes (category "none") that involve specific situations, gateways should make sure they do an accurate mapping between the situation and the return code. Foster et al. Informational [Page 16] MGCP Return Code Usage April 2002 * Also for category "State Mismatch", it is equally important that the situation (and state) are accurately mapped to the specific error code. * For situations similar to those involving return codes in "Service Failure", Provisioning Mismatch", "Temporary Failure" and "Remote Connection Descriptor Error" categories, the gateway should make sure that it uses a return code in the correct category. * MGCP allows additional commentary to be included with the return code. It is important for the gateway include more specific information concerning the situation for debug purposes. * It is recommended that return codes 502, 520 and 526 not be used unless there is something that makes these permanent situations. As indicated in the detailed description of these return codes, 403, 405 and 404 respectively are more appropriate in almost all situations. If a gateway presently uses 502, 520 and 526 for temporary situations and expects to upgrade to 403, 405 and 404, the gateway should refrain from using 502, 520 and 526 for some other use immediately after the upgrade. This is to avoid problems where a Call Agent is expected to treat the same error code in two different ways e.g. 403 is a category "Temporary Failure" which requires a different Call Agent behavior from 502 which is in category "Service Failure". 3.2. Call Agent Recommendations The following guidelines are recommended for gateway implementations: * Call Agents should handle return codes they do not recognize (or do not expect) based on the first digit in the return code as outlined in [1] (repeated at the end of section 2 in this document). * For categories "Service Failure", "Provisioning Mismatch", "Temporary Failure", and "Remote Connection Descriptor Error", Call Agents are expected to treat return codes that are within the same category in the same way (i.e. make the same decision, based on the return code and other state information available to them). * Because there was little guidance given for return codes 502, 520 and 526 in RFC 2705, Call Agents may have to treat these as 403, 405 and 404 respectively for gateways that have not been updated according to [1] and these recommendations. Consult the gateway vendor for information on the gateway behavior for (now and in the future) for these return codes (i.e. it may be that return codes 502, 520 and 526 are presently used incorrectly but will be replaced with 403, 405 and 404 in the future). 4.0. Acknowledgements Thanks also to Kevin Miller, Joe Stone, Flemming Andreasen, Bob Biskner for input contributions used in this document. 5.0. References Foster et al. Informational [Page 17] MGCP Return Code Usage April 2002 [1] Arango et al, Media Gateway Control Protocol (MGCP)Version 1.0bis, draft-andreasen-mgcp-rfc2705bis-02.txt 6.0. Authors' Addresses F. Rednor frednor@cisco.com C. Sivachelvan chelliah@cisco.com B. Foster 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 18]