Re: 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 =3D 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=92re testing MGC-MG interop, =

> and aren=92t quite agreeing over a Modify request for a termination with =

> a single stream that
>
> =B7sets the Mode to RecvOnly
>
> =B7plays an external tone.
>
> The key bits of H.248.1 text up for discussion seem to be:
>
> =B7from 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 =3D "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.
>
> =B7From 6.1.1:
>
> =95 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"/=85)_*
>
> *_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:
>
> =B7One 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]*
>
> =B7The 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=92s 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=92t 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 protected] <mailto:[email protected]>
>
> +44 20 8366 1177
>
> www.metaswitch.com <http://www.metaswitch.com/>
>
>
>
> _______________________________________________
> Megaco mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/megaco