Subject: Re: LocalControl Descriptor

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 24 Apr 2000 19:19:25 -0400

The general response to your follow-up queries is that, except where a
package specifies otherwise, signals are sent from the termination outwards,
never inwards to the context.  See the third-last paragraph of sec. 7.1.11.

The only reason continuity test tones would be propagated inwards would be
because the audio stream of the termination is in receive or sendReceive
mode.

> -----Original Message-----
> From: Chuong Nguyen [SMTP:[email-masked]]
> Sent: Monday, April 24, 2000 5:45 PM
> To:   [email-masked]
> Subject:      Re: LocalControl Descriptor
>
> Thanks for the response Tom.
>
> See comments below.
>
> Tom-PT Taylor wrote:
>
>
>
>       My views below.
>
>               -----Original Message-----
>       From:  Chuong Nguyen [SMTP:[email-masked]]
>       Sent:  Friday, April 07, 2000 12:43 PM
>       To:    [email-masked]
>       Subject:       LocalControl Descriptor
>
>               Hi
>
>               I asked this question before maybe in a different but I
> don't think that I got a response or
>       clarification in the latest version.
>
>               Maybe I will try again w/an example.
>
>
>               Section 7.1.7 LocalControl Descriptor
>       "The allowed values for the mode property are send-only,
> receive-only, send/receive,
>       inactive and loop-back.  "Send" and "receive" are with respect to
> the exterior of the context,
>       so that, for example, a stream set to mode=sendonly does not pass
> received media
>       into the context.  Signals and Events are not affected by mode."
>
>               If I have the following sceanrio
>
>
>                        MG1                                          MG2
> CO
>           ______________         ________________
> _______________
>           |                       |        |                           |
> |                             |
>           |   TDM--*--RTP  |--------|  RTP--*--TDM ------|           |
> |
>           |                       |        |                           |
> |                             |
>                    |------------|                     |-------------|
> |-----------|
>
>
>               MG1 TDM termination is set to sendrecv.
>       MG1 RTP termination is set to receive only.
>
>               MG2 TDM termination is set to inactive.
>       MG2 RTP termination is set to inactive.
>
>               MGC sends the following transaction to MG2 to do a
> Continuity Test:
>
>               Transaction=1{Context=1{Modify=TDM{Signals={ct/ct},
> Events=123{ct/cmp} }}}
>
>               The questions that I have are (keep in mind of the
> definition of mode and the relationship
>       of signal and mode as described in Section 7.1.7 above):
>
>               1) Since the MG2 TDM termination mode is inactive, does a ct
> signal get send to CO?
>            The answer should be yes since "Signals and Events are not
> affected by mode.".
>       [PTT]  Agreed.
>
>               2) Since the MG2 RTP termination mode is inactive, does a ct
> signal gets propagated to
>            MG1 RTP terminaiton?
>            The answer should be no since the termination mode is inactive.
>
>       [PTT]  Agreed.
>
>
> <cnn>  This is the behavior that I would like to see but doesn't this
> conflict w/#1 above?
>              That is a signal is applied to TDM termination.  Is this
> signal seen by the RTP termination?
>              If this signal is seen by the RTP termination (default
> topology behavior of bothway),
>              shouldn't this signal be propagated out of the context via
> RTP termination too
>             since signal is not dependent on termination mode?
>
>              Does topology, signal, event, termination/stream mode have
> any relationships?
>
>
>
>
>       3) Even though MG2 TDM termination is inactive, with the above
> transaction would I
>            still have performed a valid COT between the TDM termination
> and CO?
>       [PTT]  Yes.  It's important to note that you have tested the TDM
> portion of the connection only, but that is AFAIK the intent of a
> continuity test.
>
>               4) Does signal get propagated out of the context regardless
> of mode via whatever terminations
>            are in the context?
>            If there is a link between 2 MGs contexts, does a signal
> applied to MG2 termination get
>            propagate out of MG2 context and into MG1 context?
>       [PTT]  Since you're putting MG2 in the role of initiator, the
> response from the other end gets propagated through the context if the
> modes of the two terminations are set to allow it.
>
>
> <cnn>  I understand the response gets propagated through the context.  But
> the question is, does
>              signal applied to a TDM gets propagated
>
>
>       5) What does loopback really mean?  Can someone provide an example?
>             " "Send" and "receive" are with respect to the exterior of the
> context, ...."
>             Does loopback on a RTP termination mean that media flows into
> the context via
>             the RTP termination and flows back out of the context.? That
> media does not flow
>             into the TDM termination.  Thus that same media does not flow
> out of context via
>             the TDM termination.
>             Was loopback intended for COT initiated by CO?  But with the
> definition that signal
>              is not affected by mode, how is loopback used with COT
> signal?
>       [PTT]  "Loopback" mode means that the media content received on a
> termination is reflected back along the return direction.  We have not
> pinned down whether loopback happens on the outside of the MG or whether
> it passes through signal processors in the interior.  The difference does
> matter for some maintenance operations, so this is an open issue.
>
>               When it comes to continuity tests, some variants require
> loopback at the responding end, while others require generation of a
> different tone in the return direction from the tone sent by the
> initiator.  In our design of the package, we assumed that the MG would be
> aware through provisioning which test variant applied to a given
> termination.  Where loopback is required, it is implicit in the invocation
> of ct/rsp that it should be applied to the termination while the ct/rsp
> "signal" is active.
>
>               Am I even approaching this COT correctly?
>
>
>
>               Thanks
>       Chuong
>
>
>               --
>         Alcatel USA, Inc             Internet:
> [email-masked]
>         1000 Coit Road Plano, Texas 75075           Phone:    (972)
> 519-4613
>         **** The opinions expressed are not those of Alcatel USA, Inc ****
>
>
>
> --
>   Alcatel USA, Inc             Internet: [email-masked]
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>

---

From: Chuong Nguyen <[email-masked]>
Date: Tue, 25 Apr 2000 09:17:56 -0500

Can signal be applied to ephermeral termination (RTP)?
Appendix A: Example Call Flows, step 20,
"An RTP termination has no events nor signals, ..."

Thanks
Chuong

Tom-PT Taylor wrote:

> package specifies otherwise, signals are sent from the termination
> outwards, never inwards to the context.  See the third-last paragraph
> of sec. 7.1.11.
>
> The only reason continuity test tones would be propagated inwards
> would be because the audio stream of the termination is in receive or
> sendReceive mode.
>
>                   I asked this question before maybe in a different
>           but I don't think that I got a response or
>           inactive and loop-back.  "Send" and "receive" are with
>           respect to the exterior of the context,
>           so that, for example, a stream set to mode=sendonly does not
>           pass received media
>           MG1
>           MG2                                            CO
>               |   TDM--*--RTP  |--------|  RTP--*--TDM
>           ------|           |                 |
>               |                       |
>           |                           |
>           |                             |
>                        |------------|
>           |-------------|            |-----------|
>
>
>                   1) Since the MG2 TDM termination mode is inactive,
>           does a ct signal get send to CO?
>                The answer should be yes since "Signals and Events are
>           not affected by mode.".
>           [PTT]  Agreed.
>
>                   2) Since the MG2 RTP termination mode is inactive,
>           does a ct signal gets propagated to
>                MG1 RTP terminaiton?
>      <cnn>  This is the behavior that I would like to see but doesn't
>      this conflict w/#1 above?
>                   That is a signal is applied to TDM termination.  Is
>      this signal seen by the RTP termination?
>                   If this signal is seen by the RTP termination
>      (default topology behavior of bothway),
>                   shouldn't this signal be propagated out of the
>      context via RTP termination too
>                   Does topology, signal, event, termination/stream
>      mode have any relationships?
>
>
>
>           3) Even though MG2 TDM termination is inactive, with the
>           above transaction would I
>                still have performed a valid COT between the TDM
>           termination and CO?
>           [PTT]  Yes.  It's important to note that you have tested the
>           TDM portion of the connection only, but that is AFAIK the
>           intent of a continuity test.
>
>                   4) Does signal get propagated out of the context
>           regardless of mode via whatever terminations
>                are in the context?
>                If there is a link between 2 MGs contexts, does a
>           signal applied to MG2 termination get
>           [PTT]  Since you're putting MG2 in the role of initiator,
>           the response from the other end gets propagated through the
>           context if the modes of the two terminations are set to
>           allow it.
>
>      <cnn>  I understand the response gets propagated through the
>      context.  But the question is, does
>                 " "Send" and "receive" are with respect to the
>           exterior of the context, ...."
>                 Does loopback on a RTP termination mean that media
>           flows into the context via
>                 the RTP termination and flows back out of the
>           context.? That media does not flow
>                 into the TDM termination.  Thus that same media does
>           not flow out of context via
>                 the TDM termination.
>                 Was loopback intended for COT initiated by CO?  But
>           with the definition that signal
>                  is not affected by mode, how is loopback used with
>           COT signal?
>           [PTT]  "Loopback" mode means that the media content received
>           on a termination is reflected back along the return
>           direction.  We have not pinned down whether loopback happens
>           on the outside of the MG or whether it passes through signal
>           processors in the interior.  The difference does matter for
>           some maintenance operations, so this is an open issue.
>
>                   When it comes to continuity tests, some variants
>           require loopback at the responding end, while others require
>           generation of a different tone in the return direction from
>           the tone sent by the initiator.  In our design of the
>           package, we assumed that the MG would be aware through
>           provisioning which test variant applied to a given
>           termination.  Where loopback is required, it is implicit in
>           the invocation of ct/rsp that it should be applied to the
>           termination while the ct/rsp "signal" is active.
>

---

From: Christian Groves <[email-masked]>
Date: Wed, 26 Apr 2000 14:16:14 +1000

G'Day Tom,

The only other way would be if the direction was specified in a package.
The protocol spec says direction is outward unless specified in a
package.

Cheers, Christian