Subject: Re: [Megaco] Query about streamID 0

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

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

event (stream ID x) - detect the event only on the particular streamID x
[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 ?

signal (stream ID x) - the signal only on the particular streamID x
[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.

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: Christian Groves <[email-masked]>
Date: Fri, 01 Feb 2002 10:59:47 +1100

Hello Kapil,

Please see my answers below.

Regards, Christian

> for streams and not just terminations ?

[CHG] The appropriate stream could be any of the streams. Packages are
on the termination by virtue that there properties, streams, event,
statistics are used by the various descriptors on the termination.

> for streams and not just terminations ?

[CHG] See above

> may be referred in other descriptors like..event, signals etc.

[CHG] YEs I guess so.

---

From: Christian Groves <[email-masked]>
Date: Fri, 01 Feb 2002 10:59:47 +1100

Hello Kapil,

Regards, Christian

[CHG] See above

[CHG] YEs I guess so.