Re: H.248 Mode property vs. signals/events
Christian Groves <[email protected]> Wed, 13 Mar 2013 21:14:27 +1100
| Newsgroups | gmane.ietf.megaco |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------050908000501090503020904
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
On 7/03/2013 5:00 PM, Deepak Bissa wrote:
> 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.
> ===============================================================================
>
--------------050908000501090503020904
Content-Type: message/rfc822;
name="Attached Message"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Attached Message"
Received: from brsi02.epa.ericsson.se ([146.11.15.8]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
id JKTZRXZK; Tue, 25 Apr 2000 06:12:50 +1000
Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201])
by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id GAA17511;
Tue, 25 Apr 2000 06:13:15 +1000 (EST)
Received: from brsi02.epa.ericsson.se (brsi02.epa.ericsson.se [146.11.15.8])
by mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id GAA02306;
Tue, 25 Apr 2000 06:13:03 +1000 (EST)
Received: from alaska.wise.edt.ericsson.se (alaska.wise.edt.ericsson.se [153.88.253.21])
by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id GAA17501;
Tue, 25 Apr 2000 06:13:09 +1000 (EST)
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
by alaska.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.8) with ESMTP id WAA23422;
Mon, 24 Apr 2000 22:12:42 +0200 (MET DST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <[email protected]>; Mon, 24 Apr 2000 16:05:26 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
(LISTSERV-TCP/IP release 1.8d) with spool id 12500 for
[email protected]; Mon, 24 Apr 2000 16:04:00 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
for Windows NT v1.1a) with SMTP id
<[email protected]>; Mon, 24 Apr 2000 16:04:00
-0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
smtprtp1.ntcom.nortel.net; Mon, 24 Apr 2000 16:05:33 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
<27B935JS>; Mon, 24 Apr 2000 16:05:33 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID: <[email protected]>
Date: Mon, 24 Apr 2000 16:05:29 -0400
Reply-To: Tom-PT Taylor <[email protected]>
Sender: "Media Gateway Control (megaco)"
<[email protected]>
From: Tom-PT Taylor <[email protected]>
Subject: Re: LocalControl Descriptor
X-To: Chuong Nguyen <[email protected]>
To: [email protected]
X-Mozilla-Keys:
My views below.
> -----Original Message-----
> From: Chuong Nguyen [SMTP:[email protected]]
> Sent: Friday, April 07, 2000 12:43 PM
> To: [email protected]
> 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 protected]
> 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613
> **** The opinions expressed are not those of Alcatel USA, Inc ****
>
--------------050908000501090503020904
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Megaco mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/megaco
--------------050908000501090503020904--