Subject: RE: [Megaco] Query about streamID 0

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 29 Jan 2002 23:09:02 -0500

Darn: hit the wrong button again.

Anyway, if everyone sees it this way let's go for it.  Do we need text
changes?

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Tuesday, January 29, 2002 10:22 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: [email-masked]'; [email-masked]'
Subject: Re: [Megaco] Query about streamID 0

G'Day

My understanding of the combinations are the following:

event (no stream) - detect an event on the termination irrespective of
what streams are on the termination. The MG will insert the correct
detection equipment. ie. DTMF detector on the audio stream/s.
event (stream ID 0) - as above
event (stream ID x) - detect the event only on the particular streamID x

signal (no stream) - play the signal on the termination irrespective of
what streams are on the termination. The MG will insert the correct
playout equipment. Play a video on the video stream.
signal (stream ID 0) - as above
signal (stream ID x) - the signal only on the particular streamID x

Default streamID=1 if you leave the stream descriptor as just specify
local and remote.

Now this is all rather acedemic if the termination only ever has one
stream.
I can't see the problem. What am I missing?

Regards, Christian

Tom-PT Taylor wrote:
> 
> Your proposal that the default streamId (0) means "all active streams" is
a
> workable one for events, especially if the actual stream on which the
signal
> occurred is reported in the Notify.  I suspect signals are a bit more
> problematic -- you only want a signal to go out on one stream, usually.
> 
> I'm still troubled by the implications of assuming that you can't detect
> events on a stream not specifically defined at a given termination.  I'm
> mainly worried about the NULL context.  The simplest way around that
concern
> is to assume that the media properties of physical terminations are
> pre-provisioned.  In fact, people must be making that asumption now --
> otherwise there would have been a lot more interest in my draft on SDP
> attributes for TDM.  I intend to revive that draft shortly, by the way.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, January 28, 2002 8:36 AM
> To: Taylor, Tom-PT [CAR:B800:EXCH]
> Cc: [email-masked]'
> Subject: RE: [Megaco] Query about streamID 0
> 
> Hi Tom
> 
> My comments embedded.....
> 
> "Tom-PT Taylor" <[email-masked]> on 01/24/2002 09:07:47 PM
> 
> To:   Kapil Nayar/HSS@HSS
> cc:   "[email-masked]'" <[email-masked]>
> 
> Subject:  RE: [Megaco] Query about streamID 0
> 
> You've opened up a good discussion.
> 
> 1. You are right about streams also being bound to terminations.  Aside
from
> being able to define streams when the termination is in the NULL context,
we
> have the provision that a termination retains its current streams when it
is
> moved from one context to another.
> 
> 2. I differ slightly on the interpretation of streams versus actual
enabling
> of flows, but this is at an abstract level that I don't think makes any
> difference in behaviour.  My interpretation is that as soon as a stream is
> created in a context, it introduces the potential of bi-directional
exchange
> of media between the context and each termination in it.  Of course, to
have
> an actual flow in each direction, you need the conditions you've stated:
> Local and Remote defined on at least two terminations and sendRecv set on
> both.
> 
> The real issue is whether a termination can detect events and send signals
> on a stream not explicitly defined at that termination.  I think this is a
> matter of convention -- we have to decide one way or the other.  I'll
point
> out that it has implications for detection of DTMF events in the NULL
> context.
> <KN> I feel as per the convention and to some extent simple logic it
> would be appropriate to allow terminations to detect events and signals
> on only those streams which are explicitly defined on them. More so,
because
> in cases where there are multiple streams on multiple terminations
> Eg:
> A context with 4 terminations T1, T2, T3....
> Streams 1 and 2 on T1,3 and 2 on T3.
> T2 has currently no explicit stream defined on it.
> 
>           -------------------
>           |              |
>      T1----------1         -------T2
>           |  |            |
>           |  |--2_       |
>           |      |       |
>           |      |       |
>           |      |       |
>           |      |    3--------T3
>           |      |       | |
>           |       |____2--| |
>           |              |
>           -------------------
> It would be questionable to expect the following combinations:
> -    T2 detect events or apply signals on stream 1 or 2 or 3.
> -    T1 detect events or apply signals on stream 3.
> -    T3 detect events or apply signals on stream 1.
> At the current moment these terminations are completely oblivious of the
> stream IDs refered.
> 
> 3. I think I've made the point that H.248v1 requires that most of the
events
> and signals we have already defined must be applied to a non-zero stream.
> Hence requiring that packages indicate which ones apply to stream 0 is not
a
> change in the protocol, just a clarification.
> 
> I do have a couple of alternatives which indeed would be changes to the
> protocol.  PEOPLE SHOULD SPEAK UP ON THIS QUICKLY.
> 
>  (a) Default streamId is 1 rather than 0 if streamId is unspecified for an
> event or signal, or
>  (b) If only one stream is defined on the specific termination, an
> unspecified streamId selects that stream.
> <KN> I have an opinion.....How does MGC tell MG to detect events
> on all active streams on a termination. Does MGC have to repeat event IDs
> in the event descriptor with all active stream IDs as parameters. Protocol
> does not introduce any concept of stream ID as "*"(ALL).
> >From the current text, the stream ID 0 seems to be solving this problem.
> Stream ID 0 is the default stream on all terminations,i.e., does not need
to
> be created explicitly through media descriptor (valid).
> If event descriptor contains stream ID 0, "it does not refer to any
specific
> stream"(valid) but does refer to the termination as a whole.
> The inference is that detect events on all streams (currently active on
> stream-specific terminations like RTP/ TDMC or stream ID 0 on
> nonstream-specific terminations like NAS). If the event is detected on any
> stream, report the same to MGC with the specific stream ID.
> A similar interpretation can also be made for signals.
> And, the default stream ID remains 0 for events/ signals, but 1 for
> media descriptor.
> 
> Actually, I think people are going to have to bite the bullet and start
> specifying streamIds eventually if they don't do it now.  Choosing
> alternative (b) would buy a bit of time.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 24, 2002 5:49 AM
> To: Taylor, Tom-PT [CAR:B800:EXCH]
> Cc: [email-masked]'
> Subject: RE: [Megaco] Query about streamID 0
> 
> Hi Tom
> 
> I would like to add more to your comments about streams being context
> properties.
> 
> Streams are as good properties of the terminations too....
> -    A stream can be created on a termination in the Null Context.
>      (almost in all call flows including those in the RFC 3015 stream
> descriptor
>      or the default stream 1 is sent by the MGC in MODIFY command in the
>      Null context).
> -    To create a bi-directional stream, we need to send stream descriptor
>      with (at the least mode=sendrecv) for both the terminations in the
> context.
>      The bi-directional stream cannot be created by just refering it in
one
>      termination.
> 
> Assuming there are terminations T1 and T2 in a context. Now, MGC creates a
> stream=1 (something similar to a unidirectional media flow) by specifying
> stream descriptor for termination T1. At this point it would be incorrect
> to assume that termination T2 can detect events or apply signals on the
> stream
> 1.
> (T2 is neither a source nor a sink for stream 1 at this point, i.e., it is
> totally
> oblivious of stream 1).
> To detect events or signals on the stream at T2, we need to first make T2
> aware
> of the stream.
> 
> Although, it would be a good idea to specify in package definitions about
> which event/ signals etc. would apply on streamID=0, this would amount to
> changing
> the protocol....are you considering it for version2.
> 
> Please comment....
> 
> Thanks & Regards,
> -Kapil Nayar
> 
> "Tom-PT Taylor" <[email-masked]> on 01/23/2002 08:00:37 PM
> 
> To:   Kapil Nayar/HSS@HSS
> cc:   "[email-masked]'" <[email-masked]>
> 
> Subject:  RE: [Megaco] Query about streamID 0
> 
> Hi.  See new comments [PTT2] below.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, January 23, 2002 8:55 AM
> To: Taylor, Tom-PT [CAR:B800:EXCH]
> Cc: [email-masked]'
> Subject: RE: [Megaco] Query about streamID 0
> 
> Hi Tom
> 
> my comments embedded.
> 
> "Tom-PT Taylor" <[email-masked]> on 01/22/2002 11:35:00 PM
> 
> To:   Kapil Nayar/HSS@HSS, "[email-masked]'" <[email-masked]>
> cc:
> 
> Subject:  RE: [Megaco] Query about streamID 0
> 
> Hi.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, January 22, 2002 8:54 AM
> To: [email-masked]'
> Subject: [Megaco] Query about streamID 0
> 
> Hi Tom & list,
> 
> RFC 3015 Section 7.1.9 Event Descriptor & 7.1.11 Signal Descriptor
mentions:
> 
> "The default streamID is 0, indicating that the event to be detected is
not
> related to a particular media stream."
> 
> Does the "streamID 0" refer to the complete termination (which means all
the
> active streams on the termination) ?
> 
> [PTT] No.  It really means as it says, that the event or signal is not
> associated with any specific stream.  An example is an electrical signal
> such as off-hook.
> [KN] Does that mean that stream 0 is possible for only physical
> terminations,
> since electrical signals are more appropriate for physical terminations.
> [PTT2] There can be applications of streamId 0 on ephemerals which don't
> relate to specific streams.  Electrical signals were just an example.  I
> suspect I could find a good example in one of my NAS packages of something
> more abstract, but I won't take the time.  Just accept that we don't want
to
> foreclose the possibility of using this on ephemerals.
> 
> And, if some event is required to be detected on the ephemeral
termination,
> the event descriptor should clearly identify which stream it is required
on.
> (i.e., MGC cannot send an events descriptor for ephemeral termination
> without
> stream ID parameter since that defaults to stream ID 0, which may not be
> applicable).
> [PTT2] That has to be thought through for all terminations.
> *** IG issue: It does strike me that you can know in advance (by
definition
> of the event or signal) whether streamId=0 will apply.  We should
therefore
> make it requirement to specify this in package definitions.
> 
> [PTT] On the other hand, an audio signal such as a DTMF tone is
> associated with an audio stream.  (But I bet nobody has bothered to
specify
> stream 1 for DTMF events when they are using a default streamId for audio.
> They should!)
> [KN] Does that mean that before sending DTMFdet (dd/<?>) in events
> descriptor,
> MGC should have already created the stream 1 thru' the media descriptor
> in a previous command?
> [PTT2] StreamId=1 is the default stream created if you don't use a stream
> descriptor, but just specify Local, Remote, and LocalControl.
> *** IG issue: would it make more sense to have streamId=0 as the default
for
> signals and events, or have streamId=1 as the default?
> 
> A related doubt is...if an event descriptor refers
> to a stream ID which is not previously created by the MGC, MG should
> return an error.
> [PTT2] I'm not sure.  Remember that streamIds are really a context
property.
> If a given streamId is supported somewhere in the context, then referring
to
> that streamId at a given termination implies that the termination also
> supports it.  That means it could detect events or send signals on the
> stream even if it doesn't know how to handle the media flows on that
stream.
> I suppose if this is the first mention of the streamId in the context, it
> might be appropriate to reject the command.
> ***IG issue: The implication is that within any command, Stream
Descriptors
> for new streams MUST appear before Signals and Events descriptors
referring
> to those StreamIds.
> 
> Can MGC send streamID value 0 in a MEGACO command/ descriptor. eg: media
> descriptor, event descriptor, signal descriptor ?
> 
> [PTT] Logically, you cannot use streamId = 0 in a media descriptor and be
> consistent with the meaning of that streamId for events and signals.  We
> should have a note to the effect that streamId=0 is reserved in sections
> 7.1.4 (for thoroughness) and 7.1.6.
> 
> You can specify streamId=0 in a signals or events descriptor, but that's
the
> same as leaving it unspecified.
> 
> Please reply back...
> 
> Thanks,
> Kapil Nayar
> 
> "DISCLAIMER: This message is proprietary to Hughes Software Systmes
Limited
> (HSS) and is intended solely for the use of the individual  to whom it is
> addressed. It may contain  privileged or confidential information  and
> should
> not be circulated or used for any purpose other than for what it is
> intended.If
> you have received this message in error, please notify the originator
> immediately. If you are not the intended recipient, you are notified that
> you
> are strictly prohibited from using, copying, altering, or disclosing the
> contents of this message. HSS accepts no responsibility for loss or damage
> arising from the use of the information transimitted by this email
including
> damage from virus."
> 
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
> 
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
> 
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Jan 2002 07:49:09 +0200

Hi,

I think the proposal sounds good. However, wouldn't it be more clear if
stream ID 0 was default, instead of stream ID 1? Just a detail, but
still...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Jan 2002 07:49:09 +0200

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christian Groves <[email-masked]>
Date: Thu, 31 Jan 2002 10:44:55 +1100

G'Day Christer,

I think we still need stream ID 1 as an instance of local and remote is
associated with a single stream. The rules below give stream ID 0 a
slightly different semantic.

Christian

---

From: Christian Groves <[email-masked]>
Date: Thu, 31 Jan 2002 10:44:55 +1100

G'Day Christer,

Christian

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 31 Jan 2002 08:53:09 +0200

Hi,

>slightly different semantic.

True, and it would mean that one must always use a stream descriptor for
a non-zero streamID (currently it's not needed for streamID 1, since
it's default). I just thought it would be more clear...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 31 Jan 2002 08:53:09 +0200

Hi,

Regards,

Christer Holmberg
Ericsson Finland