Re: H.248 Mode property vs. signals/events

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 protected] [mailto:[email protected]] On Behalf Of Christian Groves
Sent: Thursday, March 07, 2013 11:12 AM
To: [email protected]
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:
>
> 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 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

_______________________________________________
Megaco mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/megaco




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