RE: [Megaco] COT...
"Kamitses, Jerry" <jkamitses@sonusnet.com> Mon, 10 February 2003 18:39 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20035 for <megaco-archive@lists.ietf.org>; Mon, 10 Feb 2003 13:39:20 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AIlBp02748; Mon, 10 Feb 2003 13:47:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AIjHp02644 for <megaco@optimus.ietf.org>; Mon, 10 Feb 2003 13:45:17 -0500
Received: from revere.sonusnet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19934 for <megaco@ietf.org>; Mon, 10 Feb 2003 13:36:13 -0500 (EST)
Received: from sonusdc3.sonusnet.com (sonusdc3.sonusnet.com [10.128.32.53]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id h1AIdl724353; Mon, 10 Feb 2003 13:39:47 -0500 (EST)
Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id <Y68HWJWH>; Mon, 10 Feb 2003 13:39:54 -0500
Message-ID: <4CF48720B6E9D4118D040060CF2074E907B34510@sonusdc3.sonusnet.com>
From: "Kamitses, Jerry" <jkamitses@sonusnet.com>
To: 'kt r' <ktr449@yahoo.com>, megaco@ietf.org
Subject: RE: [Megaco] COT...
Date: Mon, 10 Feb 2003 13:39:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=subscribe>
There was a discussion on this topic last Spring with contributions from Al Varney, Madhu Babu Brahmanapally, and Anil Jangam, which I have reproduced below. Maybe this will help? There is also a good description of the COT protocol in the MGCP Trunk Package write up (Section 2.3 of draft-foster-mgcp-basic-packages-09.txt). See also GR-317-CORE. ---------------------------------------------------------------------------- ---- To: <megaco@ietf.org> Subject: Re: [Megaco] Continuity test procedure. From: Al Varney <varney@ieee.org> Date: Wed, 15 May 2002 12:35:01 -0500 In-Reply-To: <F73B646FCC01D5118F530002B32C337263B3E5@INDTS_FS> List-Id: Media Gateway Control <megaco.ietf.org> Sender: megaco-admin@ietf.org ---------------------------------------------------------------------------- ---- Some further details on continuity test, and comments on Madhu's, et al callflows draft: At 09:01 PM 5/13/02 +0530, Anil Jangam wrote: >In carrying out the continuity check on the given Physical terminal (CIC), >there are two cases are defined (see 2.12 in Madhu's call flow). > >In the case a, the message flow depicts the transaction between the MGC and >MG. My question is -- When the continuity signal is applied at the MG side >of the link, who does the loopback at the other end of the link? It is shown >that upon receiving the "Continuity Signal Resp", a Notify message signal is >sent back to the MGC. Continuity checks are initiated and controlled by MGCs (or SS7 exchanges/switches in non-MGC architectures). The loopback at the other end of the circuit (link?) is initiated by a PSTN switch or MGC controlling that end of the circuit. But that switch/MGC is acting on an (SS7) request by the initiating MGC described in case (a). >This is imperative from the description of the case b that there has to be >some form of message exchange between the node who is initialting/requesting >the continuity (the MG end) and the other end (may be MGC or MG). The MGC is initiating the continuity test (not the MG). And yes, there is a message sent to the other end (MGC or switch) to stimulate the case (b) behavior at that end. The SS7 message might be an IAM or a maintenance message (CCR) -- in either instance, the loopback remains until a further SS7 message (COT or REL or ...) requests removal of the loopback. >In case b it is mentioned that PSTN requests for the continuity check. >Please complete the call flow. Both cases are missing some Megaco information. Adding the associated SS7 messages (IAM/COT?) would also add some clarity. Assuming a typical call (rather than the CCR scenario), in case (a) show the MGC sending an "IAM with Continuity Request" prior to step 1, and sending a "COT with Success" after receiving the MG Notify and completing Step 4. Step 4 needs to remove the "test" state from the circuit, and place it in a context or mode allowing transmission in the backward (or both) direction(s). (Transmission of COT w/Success in ISUP implies the test equipment has been removed and the circuit is ready to transport in-band tones at least in the backwards direction.) For the case (b) scenario, the MGC receives the above IAM prior to Step 1, and receives the COT after Step 2. Add a Step 3 showing the removal of the "test/loopback" condition and "rsp" signal after receipt of COT. In most cases, after the continuity test is complete, the circuit should be added to (or already be in) a context where it can receive and transport audible ring tone from the succeeding leg of the connection back to the originating end. Since these are call-flows, they correctly show little detail about the continuity test itself. Nor does RFC 3015 aid in understanding the timing and tones required for the test. For that, ITU-T Q.724 (TUP) is perhaps the best reference for test tones and the 2-wire (non-loopback) test. Note that, unlike the loopback form of the test, the 2-wire test returns a different frequency than the sent frequency. Thus the 2-wire test will fail if an accidental digital loopback is left in place in the circuit (transmission) network -- the loopback test cannot detect this error. For that reason, some service providers prefer to use the 2-wire test even on ISUP/digital circuits. In ISUP, ITU-T Q.764 should be used to determine the specific states of the continuity test (TUP uses an end-to-end test, where ISUP uses a circuit-by-circuit test). Q.764 assumes (incorrectly) that there will be no 2-wire circuits used by ISUP, so it specifies only the loopback form of the test. The ANSI T1.113 version describes both forms. Also, note that actual test frequencies/timing vary from country to country. Al Varney _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ---------------------------------------------------------------------------- ---- -----Original Message----- From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] Sent: Tuesday, May 14, 2002 1:02 PM To: 'Anil Jangam'; megaco@ietf.org Subject: RE: [Megaco] Continuity test procedure. HI anil, There are two ways of performing the continuity tests. One in which the remote end is set to loopback and the same signal generated at near end will be loop backed from the far end. Another method in which the near end and far end generate different signals . Irrespective of the type of test, it is assumed that the MGC will generate necessary messages to both sides to generate and detect necessary signals/events. Both cases of terminating and originating continuity tests were considered in the call flows. Regards Madhubabu Brahmanapally. -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Anil Jangam Sent: Monday, May 13, 2002 11:32 AM To: 'megaco@ietf.org ' Subject: [Megaco] Continuity test procedure. Hi, In carrying out the continuity check on the given Physical terminal (CIC), there are two cases are defined (see 2.12 in Madhu's call flow). In the case a, the message flow depicts the transaction between the MGC and MG. My question is -- When the continuity signal is applied at the MG side of the link, who does the loopback at the other end of the link? It is shown that upon receiving the "Continuity Signal Resp", a Notify message signal is sent back to the MGC. This is imperative from the description of the case b that there has to be some form of message exchange between the node who is initialting/requesting the continuity (the MG end) and the other end (may be MGC or MG). In case b it is mentioned that PSTN requests for the continuity check. Please complete the call flow. /anil. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --- [This E-mail was scanned for viruses and is clean.] _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco \-----Original Message----- From: kt r [mailto:ktr449@yahoo.com] Sent: Saturday, February 08, 2003 12:38 AM To: megaco@ietf.org Subject: [Megaco] COT... Hi all, I just wanted to know some detailed description about the COT (Continuity). I would appreciate if someone can throw some light on how this is accomplished...I have questions like when the call server sends this message with COT signal, how does the Gateway handles this message i.e. how COT is performed. Thanks, KTR __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
- [Megaco] COT... kt r
- RE: [Megaco] COT... Kamitses, Jerry