Subject: [Megaco] Query about streamID 0

From: [email-masked]
Date: Tue, 22 Jan 2002 19:24:24 +0530

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) ?
Can MGC send streamID value 0 in a MEGACO command/ descriptor. eg: media
descriptor, event descriptor, signal descriptor ?

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

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 22 Jan 2002 13:05:00 -0500

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,

[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.  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!)

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

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 22 Jan 2002 13:05:00 -0500

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,

Please reply back...

Thanks,
Kapil Nayar

---

From: [email-masked]
Date: Wed, 23 Jan 2002 19:25:11 +0530

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,

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

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

Please reply back...

Thanks,
Kapil Nayar

---

From: [email-masked]
Date: Wed, 23 Jan 2002 19:25:11 +0530

Hi Tom

my comments embedded.

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,

Please reply back...

Thanks,
Kapil Nayar

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Wed, 23 Jan 2002 09:30:37 -0500

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.

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,

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

Please reply back...

Thanks,
Kapil Nayar

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Wed, 23 Jan 2002 09:30:37 -0500

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

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,

Please reply back...

Thanks,
Kapil Nayar

---

From: [email-masked]
Date: Thu, 24 Jan 2002 16:19:03 +0530

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

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

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,

Please reply back...

Thanks,
Kapil Nayar

---

From: [email-masked]
Date: Thu, 24 Jan 2002 16:19:03 +0530

Hi Tom

Please comment....

Thanks & Regards,
-Kapil Nayar

To:   Kapil Nayar/HSS@HSS

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

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,

Please reply back...

Thanks,
Kapil Nayar

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Thu, 24 Jan 2002 10:37:47 -0500

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.

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.

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

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.

Please comment....

Thanks & Regards,
-Kapil Nayar

To:   Kapil Nayar/HSS@HSS

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

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,

Please reply back...

Thanks,
Kapil Nayar

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Thu, 24 Jan 2002 10:37:47 -0500

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

Please comment....

Thanks & Regards,
-Kapil Nayar

To:   Kapil Nayar/HSS@HSS

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

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,

Please reply back...

Thanks,
Kapil Nayar

---

From: [email-masked]
Date: Mon, 28 Jan 2002 19:06:29 +0530

Hi Tom

My comments embedded.....

"Tom-PT Taylor" <[email-masked]> on 01/24/2002 09:07:47 PM

To:   Kapil Nayar/HSS@HSS

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.

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

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

Please comment....

Thanks & Regards,
-Kapil Nayar

To:   Kapil Nayar/HSS@HSS

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

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,

Please reply back...

Thanks,
Kapil Nayar

---

From: [email-masked]
Date: Mon, 28 Jan 2002 19:06:29 +0530

Hi Tom

To:   Kapil Nayar/HSS@HSS

          -------------------
          |              |
     T1----------1         -------T2
          |  |            |
          |  |--2_       |
          |      |       |
          |      |       |
          |      |       |
          |      |    3--------T3
          |      |       | |
          |       |____2--| |
          |              |
          -------------------

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

Please comment....

Thanks & Regards,
-Kapil Nayar

To:   Kapil Nayar/HSS@HSS

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

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,

Please reply back...

Thanks,
Kapil Nayar

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Mon, 28 Jan 2002 09:14:43 -0500

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

To:   Kapil Nayar/HSS@HSS

          -------------------
          |              |
     T1----------1         -------T2
          |  |            |
          |  |--2_       |
          |      |       |
          |      |       |
          |      |       |
          |      |    3--------T3
          |      |       | |
          |       |____2--| |
          |              |
          -------------------

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

Please comment....

Thanks & Regards,
-Kapil Nayar

To:   Kapil Nayar/HSS@HSS

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

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,

Please reply back...

Thanks,
Kapil Nayar

---

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

---

From: [email-masked]
Date: Thu, 31 Jan 2002 14:01:00 +0530

Hi Christian

Sorry for the delayed reply.
My comments are embedded...
Thanks,
-Kapil

Christian Groves <[email-masked]> on 01/30/2002 08:51:46 AM

To:   Tom-PT Taylor <[email-masked]>
cc:   Kapil Nayar/HSS@HSS, "[email-masked]'" <[email-masked]>

G'Day

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
[KN] - Does that mean stream ID 0 refers to ANY stream or just the
APPROPRIATE stream(s)...like DTMF detector on the audio stream(s).
If it is the later, it means that packages (events) are defined
for streams and not just terminations ?

[KN] - This is OK!

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
[KN] - Does that mean stream ID 0 refers to ALL streams or just the
APPROPRIATE stream(s)...like video on the video stream(s).
If it is the later, it means that packages (signals) are defined
for streams and not just terminations ?

[KN] - This is OK!

Default streamID=1 if you leave the stream descriptor as just specify
local and remote.
[KN] - Isn't it similar to saying that stream 0 is a default stream
(a Null stream) which is not explicitly created thru' media desc but
may be referred in other descriptors like..event, signals etc.

Regards, Christian