Subject: [Megaco] Continuity tests

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 28 Apr 2004 13:20:59 -0400

Hi,

There are several continuity test types (i.e 2-wire, 4-wire, etc)
While provisioning of physical test parameters (i.e. frequencies, sequence, 
timeouts, etc)
in MG makes sense, IMHO choosing a type of continuity test seem logical
to be left to MGC.

Basic Continuity Package (ct) does not allow to choose the type of a test.
It implies that type of a test is provisioned on MG (per termination?)

Is there another (extended) continuity test package which allows MGC to choose
the type of a continuity test to be performed?
If not, does anyone see a need to have such a package?
Comments?

Thanks
	Aleks

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 28 Apr 2004 14:30:51 -0400

Is it possible to run more than one kind of continuity test on a particular
circuit?  If no, then the provisioning model holds and there is no need for
a change.  If yes, then we may need to add something to the package to allow
selection of a ct test type.

Kevin 

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]] 
Sent: Wednesday, April 28, 2004 1:21 PM
To: [email-masked]
Subject: [Megaco] Continuity tests

Hi,

There are several continuity test types (i.e 2-wire, 4-wire, etc) While
provisioning of physical test parameters (i.e. frequencies, sequence,
timeouts, etc) in MG makes sense, IMHO choosing a type of continuity test
seem logical to be left to MGC.

Is there another (extended) continuity test package which allows MGC to
choose the type of a continuity test to be performed?
If not, does anyone see a need to have such a package?
Comments?

Thanks
	Aleks

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 28 Apr 2004 14:30:51 -0400

Kevin 

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]] 
Sent: Wednesday, April 28, 2004 1:21 PM
To: [email-masked]
Subject: [Megaco] Continuity tests

Hi,

Thanks
	Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 28 Apr 2004 14:11:44 -0400

Yes, the type of test depends on what a circuit is connected to.

But, I was actually coming from the view that MGC "controls" MG
and as such only MGC should have knowledge on what test to execute
(i.e. what is connected to the other side of a circuit).

If this information is left in MG, then each circuit has to be provisioned
with that information such that MG can make intelligent decision on what
type of test to execute. Thus every time a circuit connection is changed,
directly or indirectly, MG circuit needs to be re-provisioned.

I think that configuration should  be kept on MGC and the decision should
come from MGC instead.

         Aleks

At 02:30 PM 4/28/2004, Kevin Boyle wrote:

>Is it possible to run more than one kind of continuity test on a 
>particular circuit?  If no, then the provisioning model holds and there is 
>no need for a change.  If yes, then we may need to add something to the 
>package to allow selection of a ct test type.
>
>Kevin
>
>From: Aleksandr Ryabin [<mailto:[email-masked]>mailto:[email-masked]]
><https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/mailman/listinfo/megaco 
>

---

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 29 Apr 2004 11:23:36 -0400

I agree with Tom.  The fact that the circuit is connected to a single entity
means that only a single type of continuity test is actually valid.  MGs are
expected to know how to handle their terminations.  Who the termination is
connected to is certainly part of that handling.  Because the far-end
connection changes the nature of the termination, this becomes an
MG-knowledge problem.

I believe the package is fine as it stands, and the MG should know what "run
a continuity test" means for its terminations.

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH] 
Sent: Thursday, April 29, 2004 11:19 AM
To: Aleksandr Ryabin
Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]
Subject: Re: [Megaco] Continuity tests

I for one disagree with your philosophy.  I think the physical details of
the termination should be provisioned in the MG rather than the the MGC.
However, I have no direct implementation responsibility, so I should let
those who do speak up.

Aleksandr Ryabin wrote:

> Packages defined in H.248.17 do not cover continuity tests.
> 
> If the experts agree that MGC should be able to control type of 
> continuity test then ether basic ct package needs to be amended to 
> include new functionality, or H.248.17 needs to be amended to include 
> new "extended" continuity package Commends? Suggestions?
> 
>         Aleks
> 
> At 01:14 AM 4/29/2004, Zhao Bo wrote:
> 
>> Can H.248.17 "line test packages"  be used to test these circuits?
>>
>>     ----- Original Message -----
>>     From: Aleksandr Ryabin <mailto:[email-masked]>
>>     To: Kevin Boyle <mailto:[email-masked]> ;
>>     [email-masked] <mailto:[email-masked]>
>>     Sent: Thursday, April 29, 2004 2:11 AM
>>     Subject: RE: [Megaco] Continuity tests
>>
>>>         Is it possible to run more than one kind of continuity test
>>>         on a particular circuit?  If no, then the provisioning model
>>>         holds and there is no need for a change.  If yes, then we may
>>>         need to add something to the package to allow selection of a
>>>         ct test type.
>>>
>>>         Kevin
>>>
>>>         There are several continuity test types (i.e 2-wire, 4-wire,
>>>         etc) While provisioning of physical test parameters (i.e.
>>>         frequencies, sequence, timeouts, etc) in MG makes sense, IMHO
>>>         choosing a type of continuity test seem logical to be left to
>>>         MGC.
>>>
>>>         Is there another (extended) continuity test package which
>>>         allows MGC to choose the type of a continuity test to be
>>>         performed?
>>>

---

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 29 Apr 2004 11:23:36 -0400

Kevin

---

From: Aleksandr Ryabin <[email-masked]>
Date: Thu, 29 Apr 2004 12:25:51 -0400

Kevin, exactly, the type of COT test does not only depend on the physical
details of a termination the MGC controls, but also on physical
details of circuit which *eventually* is connected to that termination.

My point is that the final far-end *final* connection can change without
a change to immediate connection to MG termination and only MGC
would know about it.

For example, if MG is digital trunking gateway, it does not mean that
only pure 4-wire tests will be used all the time. If the other side connected
trough set of intermediate switches and finally lands at the time of the test
say on analog 2-wire circuit then the test to be executed is 2-wire test.

I guess it is possible to somehow tie up configuration of MG termination
dynamically to changes which happens to those intermediate switches,
but it does not seem right. On the contrary, that information would come to
MGC naturally, since it is a controlling element.

Also putting a burden of configuring of a test type per every single
termination seems to be too much for MG, especially if we are talking
about high density MGs which handle hundred thousands terminations.

BTW This is a real problem we run into in our MGC implementation and
are trying to solve. I thought that instead of having a proprietary package
I might as well give it a shot to see if there is any interest to make the
solution public instead.

Thanks.
         Aleks

At 11:23 AM 4/29/2004, Kevin Boyle wrote:

>I agree with Tom.  The fact that the circuit is connected to a single 
>entity means that only a single type of continuity test is actually 
>valid.  MGs are expected to know how to handle their terminations.  Who 
>the termination is connected to is certainly part of that 
>handling.  Because the far-end connection changes the nature of the 
>termination, this becomes an MG-knowledge problem.
>
>I believe the package is fine as it stands, and the MG should know what 
>"run a continuity test" means for its terminations.
>
>Kevin
>
>the termination should be provisioned in the MG rather than the the 
>MGC.  However, I have no direct implementation responsibility, so I should 
>let those who do speak up.
>
>Aleksandr Ryabin wrote:
>
> >>     From: Aleksandr Ryabin 
> <<mailto:[email-masked]>mailto:[email-masked]>
> >>     To: Kevin Boyle 
> <<mailto:[email-masked]>mailto:[email-masked]> ;
> >>     [email-masked] <<mailto:[email-masked]>mailto:[email-masked]>
> >>>         From: Aleksandr Ryabin 
> [<mailto:[email-masked]>mailto:[email-masked]]

---

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 30 Apr 2004 11:41:09 -0400

Wait a minute.  You are saying that the type of test would change from
2-wire to 4-wire because some intermediary is forking the links?  I find
that very hard to believe, especially since the termination where the test
is originating (and is, presumably, under test) would be unchanged.  The
termination wouldn't magically grow (or lose) two wires just because an
interim box is splitting or redirecting the link.

As pointed out earlier, COT is a link by link test.  Splitting or
redirecting the link means that those are new links, not "continuations".
It would seem to me that the interim box would be responsible for continuing
the COT test across the redirected or split link.  If it doesn't, for
whatever reason including "being dumb", then that is the problem of the
interim box, not the original termination.

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]] 
Sent: Friday, April 30, 2004 10:39 AM
To: Christian Groves; [email-masked]
Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH]
Subject: Re: [Megaco] Continuity tests

Hi Christian,

There could be "dumb" switches in the middle of the path (for example DACS)
which are not capable of any testing/signalling.
Their only role is to split/redirect links and as such the nature of a
circuit can change, and thus the type of COT test.

Regards,
         Aleks

At 08:17 PM 4/29/2004, Christian Groves wrote:
>Hello Aleksandr,
>
>Is this really a problem? The Continuity test is a link by link 
>procedure not an end to end procedure. I tend to support Kevin and Tom on
this one.
>
>Regards, Christian
>
>Aleksandr Ryabin wrote:
>>Kevin, exactly, the type of COT test does not only depend on the 
>>physical details of a termination the MGC controls, but also on 
>>physical details of circuit which *eventually* is connected to that
termination.
>>My point is that the final far-end *final* connection can change 
>>without a change to immediate connection to MG termination and only 
>>MGC would know about it.
>>only pure 4-wire tests will be used all the time. If the other side 
>>connected trough set of intermediate switches and finally lands at the 
>>time of the test say on analog 2-wire circuit then the test to be executed
is 2-wire test.
>>I guess it is possible to somehow tie up configuration of MG 
>>termination dynamically to changes which happens to those intermediate 
>>switches, but it does not seem right. On the contrary, that 
>>information would come to MGC naturally, since it is a controlling
element.
>>are trying to solve. I thought that instead of having a proprietary 
>>package I might as well give it a shot to see if there is any interest 
>>to make the solution public instead.
>>Thanks.
>>         Aleks
>>>valid.  MGs are expected to know how to handle their terminations.
>>>Who the termination is connected to is certainly part of that 
>>>I believe the package is fine as it stands, and the MG should know 
>>>what "run a continuity test" means for its terminations.
>>>
>>>Kevin
>>>
>>>I for one disagree with your philosophy.  I think the physical 
>>>details of the termination should be provisioned in the MG rather 
>>>than the the MGC.  However, I have no direct implementation 
>>>responsibility, so I should let those who do speak up.
>>>
>>>Aleksandr Ryabin wrote:
>>>
>>> > include new functionality, or H.248.17 needs to be amended to 
>>> > include new "extended" continuity package Commends? Suggestions?
>>> >
>>> >         Aleks
>>> >
>>> >>     I think that configuration should  be kept on MGC and the
decision
>>> >>     should

---

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 30 Apr 2004 11:41:09 -0400

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]] 
Sent: Friday, April 30, 2004 10:39 AM
To: Christian Groves; [email-masked]
Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH]
Subject: Re: [Megaco] Continuity tests

Hi Christian,

Regards,
         Aleks

this one.
termination.
is 2-wire test.
element.
decision

---

From: Aleksandr Ryabin <[email-masked]>
Date: Fri, 30 Apr 2004 12:29:29 -0400

Kevin,

Yes, an intermediate box can also convert from one type of line to another,
for example, take a single ds0 from a digital T1 and patch it to an analog 
phone line.
So COT test would originate on ds0 on T1 and terminate on the analog line.

I agree that this technically looks like a problem of interim box, but 
since interim
box is dumb and there is nothing we can do about it ends up being our problem.

So no matter how we put it we have to solve it on our MGC
and for this we need to specify which test to run.

This problem will came up for any softswitch implementations
in networks/installations which utilize any kind of intermediate dumb switch.

Regards,
         Aleks

At 11:41 AM 4/30/2004, Kevin Boyle wrote:

>redirecting the link means that those are new links, not 
>"continuations".  It would seem to me that the interim box would be 
>responsible for continuing the COT test across the redirected or split 
>link.  If it doesn't, for whatever reason including "being dumb", then 
>that is the problem of the interim box, not the original termination.
>
>Kevin
>
>There could be "dumb" switches in the middle of the path (for example 
>DACS) which are not capable of any testing/signalling.
>
> >procedure not an end to end procedure. I tend to support Kevin and Tom 
> on this one.
> >
> >Regards, Christian
> >
> >Aleksandr Ryabin wrote:
> >>time of the test say on analog 2-wire circuit then the test to be 
> executed is 2-wire test.

---

From: Aleksandr Ryabin <[email-masked]>
Date: Fri, 30 Apr 2004 12:29:29 -0400

Kevin,

Regards,
         Aleks