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