Subject: [Megaco] H.248 Mode property vs. signals/events

From: Mark Overton <[email-masked]>
Date: Tue, 5 Mar 2013 11:00:35 +0000

Hi,

Can someone please help me understand the interaction between the H.248 Mode property and Signals/Events? We're testing MGC-MG interop, and aren't quite agreeing over a Modify request for a termination with a single stream that

*         sets the Mode to RecvOnly

*         plays an external tone.

The key bits of H.248.1 text up for discussion seem to be:

*         from 7.1.7:

The allowed values for the Mode Property are "SendOnly", "RecvOnly", "SendRecv", "Inactive"
and "LoopBack". "SendOnly", "RecvOnly" and "LoopBack" 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. When a stream is set to "LoopBack" on a termination, media received (Local
Descriptor) on the termination will be looped back to the sending side (Remote Descriptor) of the
termination and no media is passed between that termination and other terminations in the context.
The looped back media shall be sent according to the Remote Descriptor. The default value for the
Mode Property is "Inactive". Signals and events are not affected by the Mode Property. The
LocalControl Mode Property takes precedence over any mode specified in the Local and Remote
Descriptors.

*         From 6.1.1:

* The Topology Descriptor (who hears/sees whom).
The topology of a context describes the flow of media between the terminations within a
context. In contrast, the Mode Property of a termination ("SendOnly"/"RecvOnly"/...)
describes the flow of the media at the egress/ingress of the media gateway.

So I think we've both interpreted the Mode property differently:

*         One view treats the Mode property as absolute: that is, RecvOnly means absolutely no media is sent out to this termination, SendOnly means any and all received media is absolutely ignored. Setting the mode doesn't affect the Signals and Events that are programmed on a given termination, neither does it affect any subsequent programming - but it can and does affect the result of the programming. So in this case a Mode of RecvOnly combined with an external tone means the tone gets played in the DSP but absolutely no media is sent out to that termination.

Another way to explain our implementation is in this picture:
[MG egress/ingress]<--- flow affected by Mode property --->[termination including DSP for signals/events]<--- flow affected by Topology descriptor --->[context media mixpoint]

*         The other (that expects to see the tone played to the termination) effectively says that the Mode property affects the flow of media between the termination and the context media mixpoint:
[MG egress/ingress]<------>[termination including DSP for signals/events]<--- flow affected by Mode and Topology --->[context media mixpoint]

What's the right answer here? The first view seems to go against the text from 7.1.7, and the second view seems to go against that from 6.1.1.

Please don't hesitate to get back to me if any of this is unclear. Many thanks in advance,

Mark

----
Mark Overton
Project Manager, Carrier Systems Division
Metaswitch Networks

[email-masked]<mailto:[email-masked]>
+44 20 8366 1177
www.metaswitch.com<http://www.metaswitch.com/>

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 6 Mar 2013 09:48:16 +0100

Hello Mark,

H.248.1, clause 6: model aspects
H.248.1, clause 7: protocol syntax & semantics

Thus, clause 7.1.7 takes precedence over clause 6.1.1 in my understanding.
If you want to refer topology descriptor, then clause 7.1.18 ("would consider 6.1.1 as a high-level model").

Further: correct MG behaviour arround StreamMode was again frequently discussed in the last two study periods (also in the context of loopback, H.248.85), leading to a number of IG updates.
Looks like that your are not refering the latest text of H.248.1 ("e.g. text about statistics was added, which is missing in your quote").

Latest text of H.248.1: a new release had to be prepared (at 2013-01 meeting) with the end of the 2009-2012 period, which contains all consolidated IG items.
Status: http://www.itu.int/ITU-T/aap/AAPRecDetails.aspx?AAPSeqNo=2714
Thus, not yet published due to ongoing AAP, but you may use the LC text (http://www.itu.int/ITU-T/aap/dologin_aap.asp?id=T0102000A9A0701MSWE.docx&group=16 ).

You may note that also clarifications to events (7.1.9) and signals (7.1.11) were added.

Further like to add following StreamMode model, which we've used in H.248 clarifications. The model should be correct and consistent with H.248.1:

H.248 StreamMode model:

I'm not sure whether your physical model ("real resource components like DSP") is consistent with the H.248 model, hm? At least not with above StreamMode model.

Regards,
Albrecht

PS
I've to note that above StreamMode model was not added to H.248.1, rather only pure textual clarifications as IG items ...

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Overton
Sent: Dienstag, 5. März 2013 12:01
To: [email-masked]
Subject: [Megaco] H.248 Mode property vs. signals/events

Hi,

·         sets the Mode to RecvOnly

·         plays an external tone.

·         from 7.1.7:

·         From 6.1.1:

·         One view treats the Mode property as absolute: that is, RecvOnly means absolutely no media is sent out to this termination, SendOnly means any and all received media is absolutely ignored. Setting the mode doesn't affect the Signals and Events that are programmed on a given termination, neither does it affect any subsequent programming - but it can and does affect the result of the programming. So in this case a Mode of RecvOnly combined with an external tone means the tone gets played in the DSP but absolutely no media is sent out to that termination.

·         The other (that expects to see the tone played to the termination) effectively says that the Mode property affects the flow of media between the termination and the context media mixpoint:
[MG egress/ingress]<------>[termination including DSP for signals/events]<--- flow affected by Mode and Topology --->[context media mixpoint]

Mark

----
Mark Overton

---

From: Christian Groves <[email-masked]>
Date: Thu, 07 Mar 2013 16:42:16 +1100

Hello Mark,

The main sentence here is from 7.1.7 "signals and events are not 
affected by the mode property". 6.1.1 just contrasts the behaviour of 
stream mode from the topology descriptor.

Even if Streammode = recv is set, if a signal is applied on a 
Termination/Stream in the outgoing direction it will be sent (the tone 
will get played). Of course if you haven't set up media in the 
local/remote descriptor then nothing will get sent.

Regards, Christian

On 5/03/2013 10:00 PM, Mark Overton wrote:
>
> Hi,
>
> Can someone please help me understand the interaction between the 
> H.248 Mode property and Signals/Events? We’re testing MGC-MG interop, 
> and aren’t quite agreeing over a Modify request for a termination with 
> a single stream that
>
> ·sets the Mode to RecvOnly
>
> ·plays an external tone.
>
> ·from 7.1.7:
> context, so that, *_for example, a stream set to mode = "SendOnly" 
> does not pass received media into_*
>
> *_the context_*. When a stream is set to "LoopBack" on a termination, 
> media received (Local
>
> Mode Property is "Inactive". *_Signals and events are not affected by 
> the Mode Property_*. The
>
> ·From 6.1.1:
> • The Topology Descriptor (who hears/sees whom).
>
> context. In contrast, *_the Mode Property of a termination 
> ("SendOnly"/"RecvOnly"/…)_*
>
> *_describes the flow of the media at the egress/ingress of the media 
> gateway_*.
>
> ·One view treats the Mode property as absolute: that is, RecvOnly 
> means absolutely no media is sent out to this termination, SendOnly 
> means any and all received media is absolutely ignored. Setting the 
> mode doesn't affect the Signals and Events that are /programmed/ on a 
> given termination, neither does it affect any subsequent programming - 
> but it can and does affect the /result/ of the programming. So in this 
> case a Mode of RecvOnly combined with an external tone means the tone 
> gets played in the DSP but absolutely no media is sent out to that 
> termination.
>
> *[MG egress/ingress]<--- flow affected by Mode property 
> --->[termination including DSP for signals/events]<--- flow affected 
> by Topology descriptor --->[context media mixpoint]*
>
> ·The other (that expects to see the tone played to the termination) 
> effectively says that the Mode property affects the flow of media 
> between the termination and the context media mixpoint:
>
> *[MG egress/ingress]<------>[termination including DSP for 
> signals/events]<--- flow affected by Mode and Topology --->[context 
> media mixpoint]*
>
> What’s the right answer here? The first view seems to go against the 
> text from 7.1.7, and the second view seems to go against that from 6.1.1.
>
> Please don’t hesitate to get back to me if any of this is unclear. 
> Many thanks in advance,
>
> Mark
>
> ----
>
> Mark Overton
>
> /Project Manager, Carrier Systems Division/
>
> *Metaswitch Networks*
>
> [email-masked] <mailto:[email-masked]>
>
> +44 20 8366 1177
>
> www.metaswitch.com <http://www.metaswitch.com/>
>
>
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/megaco

---

From: Deepak Bissa <[email-masked]>
Date: Thu, 7 Mar 2013 11:30:59 +0530

Hello Christian,

The signal is played via media stream in this case and is dependent on local/remote descriptor.
The stream mode should decide the flow of media stream in my view. The rules on media stream should apply here even if a signal is played via media stream.
What if the stream mode is set as Inactive? Will the signal will still be played?

Regards,
Deepak Bissa

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: Thursday, March 07, 2013 11:12 AM
To: [email-masked]
Subject: Re: [Megaco] H.248 Mode property vs. signals/events

Hello Mark,

The main sentence here is from 7.1.7 "signals and events are not affected by the mode property". 6.1.1 just contrasts the behaviour of stream mode from the topology descriptor.

Even if Streammode = recv is set, if a signal is applied on a Termination/Stream in the outgoing direction it will be sent (the tone will get played). Of course if you haven't set up media in the local/remote descriptor then nothing will get sent.

Regards, Christian

On 5/03/2013 10:00 PM, Mark Overton wrote:
> H.248 Mode property and Signals/Events? We're testing MGC-MG interop,
> and aren't quite agreeing over a Modify request for a termination with
> a single stream that
>
> *sets the Mode to RecvOnly
>
> *plays an external tone.
>
> *from 7.1.7:
> *From 6.1.1:
> ("SendOnly"/"RecvOnly"/...)_*
>
> *One view treats the Mode property as absolute: that is, RecvOnly
> *The other (that expects to see the tone played to the termination)
> What's the right answer here? The first view seems to go against the

===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================

---

From: Christian Groves <[email-masked]>
Date: Wed, 13 Mar 2013 21:14:27 +1100

Hello Deepak,

The spec says "Signals are unaffected by mode". This text has been there 
since 1999. I decided to have a look through the mail archives to see if 
it had been discussed previously. It had, in the context of TDM termination.
("Re: LocalControl Descriptor" 25/04/2000)[Attached].
"        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.".

The MGC is the master, so if it sets the mode to "Inactive" and it 
doesn't want a tone or announcement played out of the MG it shouldn't 
send the signal.

Regards, Christian

>> [email-masked] <mailto:[email-masked]>

Subject: Re: LocalControl Descriptor
From: Tom-PT Taylor <[email-masked]>
To: [email-masked]
Date: Mon, 24 Apr 2000 16:05:29 -0400

My views below.

> 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.
>
> MG1 TDM termination is set to inactive.
> MG1 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.

> 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.

> 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 ****
>

---

From: Mark Overton <[email-masked]>
Date: Wed, 27 Mar 2013 09:31:33 +0000

Christian, Albrecht,

I've been thinking about this some more and have a question about the implementation of stream mode for RTP terminations in particular.

We've established so far that signals/events are unaffected by Mode: in my original example, if the Mode is RecvOnly and an external Signal is requested (e.g. a tone), it should be played; so we're sending RTP packets containing the tone waveform.

So what about RecvOnly/Inactive RTP terminations where there's no Signal requested? Should I be sending RTP packets (assuming I've a remote descriptor) or not? (And if I should, what do they contain?) Per my original trail, I'd assumed no packets should be sent...

Thanks,

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 13 March 2013 10:14
To: Deepak Bissa
Cc: [email-masked]
Subject: Re: [Megaco] H.248 Mode property vs. signals/events

Hello Deepak,

The spec says "Signals are unaffected by mode". This text has been there since 1999. I decided to have a look through the mail archives to see if it had been discussed previously. It had, in the context of TDM termination.
("Re: LocalControl Descriptor" 25/04/2000)[Attached].
"        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.".

The MGC is the master, so if it sets the mode to "Inactive" and it doesn't want a tone or announcement played out of the MG it shouldn't send the signal.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Thu, 28 Mar 2013 12:19:24 +1100

Hello Mark,

If there's no signal and the streammode is RecvOnly/Inactive then I 
agree no packets should be sent.

Regards, Christian