Subject: Re: 105 & 108 tests

From: Tom-PT Taylor <[email-masked]>
Date: Sat, 19 Feb 2000 17:27:42 -0500

I suspect we have to define a new test package extending the continuity test
package.

> -----Original Message-----
> From: Chao Deng [SMTP:[email-masked]]
> Sent: Saturday, February 19, 2000 11:53 AM
> To:   [email-masked]
> Subject:      105 & 108 tests
>
> Hi all,
>
> (1). How does current Megaco protocol support 105 and 108 test line
> operations?
>
> (2). Can I utilize Basic Continuity Package to implement it as follows?
>      (a). Define and specify test types for 105 & 108 operations in
> Signals
> (Initiate & Respond)
>      (b). MGC Initiates 105/108 test type Signals.
>      (c). MG Responds with appropriate test type Signals.
>      (d). MG performs the specified test procedure 105 by setting RTP side
> terminationMode as "loopback"
>                 and test procedure 108 by setting SCN side terminationMode
> as
> "loopback". Both streamMode are set as "loopbackToken".
>
>
> (3) How can Trunk Package which defines COT & Loopback be used in 105 &
> 108
> tests?
>
> Thanks,
>
> ---Chao D.

---

From: Michael Brown <[email-masked]>
Date: Mon, 21 Feb 2000 13:40:42 -0500

I agree that it would be an extension package, but I would think that it
would be an extension to the analog line supervision package instead of
Continuity since 105 and 108 are line tests and I've been thinking of
the continuity package as applying to trunk type applications.

Michael Brown

"Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:

>
>
> I suspect we have to define a new test package extending the
> continuity test package.
>
>      (1). How does current Megaco protocol support 105 and 108 test
>      line operations?
>
>           (a). Define and specify test types for 105 & 108 operations
>      in Signals
>      (Initiate & Respond)
>                      and test procedure 108 by setting SCN side
>      terminationMode as
>      (3) How can Trunk Package which defines COT & Loopback be used in
>      105 & 108
>      tests?
>
>      Thanks,
>
>      ---Chao D.
>

---

From: Al Varney <[email-masked]>
Date: Tue, 22 Feb 2000 18:03:45 -0600

At 13:40 02/21/2000 -0500, Michael Brown wrote:

I agree that it would be an extension package,
but I would think that it would be an extension to the analog line
supervision package instead of Continuity since 105 and 108 are line
tests and I've been thinking of the continuity package as applying to
trunk type applications.

I'm trying to figure out how you could categorize 105/108
tests

as "line tests".  While 108 might be available for BER
testing of

"PBX lines" over T1/E1 facilities, the EO in many respects
treats these

as "trunks" (and they certainly would be candidates to appear
on a

Trunk Gateway rather than a Line Gateway).  BRI lines may have a
108-type

digital loop-back test available to them.  But I can't think of a
case

where 105/108 would be useful as ANALOG line tests.

In fact, the ANSI T1.207 document defining these terms (and
the

Telcordia SR-2275 "Notes on the Network" document which appears
to

have been the source for much of T1.207) both state that "test
lines"

are a basic part of Trunk Maintenance.  That's certainly been
my

experience.

Just some thoughts on tests accessed from a line:

a) Any line should be able to call up a DTMF test (even IP phones).

If RTP can pass/encode the tones, then it make sense for
this test

termination to NOT be in the line/residential gateway -- one
wants

to assure DTMF can actually be signalled over the packet
"fabric".

b) Same goes for 100-type (quiet termination) and 102-type
(milli-watt)

tests.  Noise/level measurements need to include the
packetization

effects that real calls will encounter.  So RTP had
better be able

to handle milli-watt/DRS very cleanly.

So it doesn't seem (to me) line/residential gateways need to
have

these particular types of test capabilities built in.  (They do
need

to be capable of connecting to test line equipment, including
transmission

measuring equipment.)  On the other hand, basic analog loop
tests

(power-cross, low loop resistance) made on a per-call basis, as
well

as ROH/permanent-signal capabilities are pretty much essential in
such

gateways.  Rather than 10X-type capabilities, I think metallic
test

access is something line gateways may have to provide, and that
really

IS a topic for another thread....

On to the proposal:

"Taylor, Tom-PT (P.T.)
[EXCHANGE:CAR:B904]" wrote:

I suspect we have to
define a new test package extending the continuity test package.

-----Original Message-----

From:  Chao Deng
[SMTP:[email-masked]]

Sent:  Saturday,
February 19, 2000 11:53 AM

To:
[email-masked]

Subject:       105 & 108 tests

Hi all,

(1). How does current Megaco protocol support 105 and 108 test line operations?

(2). Can I utilize Basic Continuity Package to implement it as follows?
(a). Define and specify test types for 105 & 108 operations in Signals
(Initiate & Respond)
(b). MGC Initiates 105/108 test type Signals.
(c). MG Responds with appropriate test type Signals.
(d). MG performs the specified test procedure 105 by setting RTP side
terminationMode as "loopback"
and test procedure 108 by setting SCN side terminationMode as
"loopback". Both streamMode are set as "loopbackToken".

I follow your 108 procedure (SCN loopback) at the "terminating"

Gateway -- essential if the MGC receives a 108 request from a

connecting PSTN switch.  You'll need a new package if you want to

initiate a 108 test from a gateway to a PSTN switch -- both the

digital stream generation and detector would be in the initiating

gateway.

I don't follow your 105 suggestion at all.  At a minimum, a new

package would be needed in the terminating gateway, to act as a

105-type responder (tones + signaling).  I'm confused by the use

of RTP loopback here.

There are other means to do 10X tests, besides building them into

every trunk gateway.  Two obvious alternatives are:

1) Incoming 10X-type requests are handled by bridging PSTN trunks to a

TDM circuit dedicated to trunk test equipment (and the MGC can control

this equipment).  This also works for outgoing trunk tests.  Downsides

are that a dedicated TDM circuit is needed in each trunk gateway (a

big problem for remotely-located gateways) and any test will really

be testing both the PSTN circuit AND the test trunk circuit (so any

failures are always suspect).  The PSTN-to-test-circuit bridge would

have to be bit-transparent and also pass along any robbed-bit signals.

[This is similar to how analog switches did 10X.]

2) Incoming 10X-type requests could be RTP-encoded using G.711 with

signalling bits carried transparently to a centralized test facility

(similar to an announcement server, but CAS signaling needs to be

considered as well.)  This only works if the RTP processing introduces

very little delay for these connections.  Outgoing tests (105/108)

could also use this method.  But can RTP operate with low-enough

delay to have an accurate C-notched noise test performed over it,

for example?

Note that these alternatives require no MEGACO work, unless the

support for robbed-bit/CAS signaling needs a new type of internal

bridging connection or a low-delay RTP (one packet per frame???)

needs to be added for accurate measurements.

Feedback??  (Sorry about the length.)

(3) How can Trunk Package which defines COT & Loopback be used in 105 & 108
tests?

Thanks,

---Chao D.

Al Varney - Lucent Technologies  +1 630 224-7493    [email-masked]