Subject: Re: Signal Queuing

From: Peter Blatherwick <[email-masked]>
Date: Tue, 7 Dec 1999 09:09:36 -0600

I agree with Brian on this one.  Two primary reasons:

1. Lets keep it simple until we know more about the problem
   and see clearly that there are sufficient cases (with
   multi-package interactions) to warrant a general
   mechanism.

2. I do not want to burden all MGs with functionality needed
   by a few relatively complex ones.  I see dynamic queuing
   and simultaneous play as not needed by most applications.
   At a minimum, they must be able to be turned off, as
   suggested by others.  (And yes, the sequential signal list
   should be optional to implement in the MG for the same
   reason, as it is.)

For now, I believe we should keep this stuff contained in
packages that need it.  An excellent topic to work through in
detail in the next revision, but lets finish version 1 first.

-- Peter Blatherwick, minimalist

> -----Original Message-----
> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: 7 Dec, 1999 08:54
> To:   [email-masked]
> Subject:      Re: Signal Queuing
>
> I think that this just highlights the issue that we
> don't KNOW what future packages may need.  Simple
> queuing may not be enough.
>
> If you allow an MG to declare it has no queue, then
> MGCs have to cope with no queuing.  If they can do
> that, there is very little advantage to having the
> queue (it would have to be something like a
> reduction in the number of messages).  That kind of
> optimization should be deferred until we understand
> the problem better.
>
> Brian
>
> > -----Original Message-----
> > From: Christian Groves [mailto:[email-masked]]
> > Sent: Monday, December 06, 1999 3:51 PM
> > To: [email-masked]
> > Subject: Re: Signal Queuing
> >
> >
> > G'Day Tom,
> >
> > Well its the first time I've been called theoretical (maybe a
> > thesis is
> > in order :-) )but I think that Steven Magnell has highlighted
> > some very
> > practical issues.
> >
> > Cases for both queing and synchronous playing have been highlighted.
> > There may be other uses that other people haven't even thought up yet.
> > We want a mechanism that relatively future proof. Having each package
> > defining a mechanism, as Steven mentioned below just moves
> > the problem.
> > This could potentially mean that there are several
> > queueing/synchronous
> > playing methods that need to be supported in the media
> > gateway adding to
> > development costs and complexity in the MC and MG. Also trying to
> > coordinate queuing/synchronous playing methods between packages could
> > present unknown interaction problems. A generic method in the protocol
> > would alleviate these problems.
> >
> > Having two root properties: one for queue length and one for number of
> > synchronous signals would control the complexity in the
> > gateway. Setting
> > each of these to one would effectively turn this functionality off.
> > Simple gateways would still be simple.
> >
> > Cheers, Christian
> >
> >
> > Steven Magnell wrote:
> > >
> > > Tom and list readers,
> > >
> > > I am a little bit behind in my list reading, but since I am
> > one of the
> > > named advocates it seems reasonable to comment on a couple
> > of points.
> > >
> > > At 02:58 PM 12/3/99 -0500, Tom-PT Taylor wrote:
> > > ......
> > > >The nub of the question is whether there is a real
> > requirement for dynamic
> > > >queuing of signals.  That is, is there a situation where
> > the MGC does not
> > > >know in advance which signals need to be played in
> > sequence, and where the
> > > >inter-signal timing requirements are so tight that there
> > is insufficient
> > > >time for a completion event to go to the MGC so the MGC
> > can return the next
> > > >signal to be played? Typically, by the way, discussion of
> > this problem area
> > > >involves announcements
> > >
> > > Aside from the case that I described in Washington, which involved
> > > announcements, there is another possible case involving
> > tones. In H.323
> > > signaling, it is possible to do overlapped signaling and
> > the requirement to
> > > support such has been discussed in other fora such as ETSI
> > Tiphon and the
> > > (now seeming ancient) IMTC VoIP Forum.
> > >
> > > If one is using H.323, for example, as the signaling
> > mechanism between two
> > > gateways, it is possible that the gateway at the calling
> > end is receiving
> > > digits and passing them using the methods for overlapped
> > signaling to the
> > > called end. If the called end gateway consists of an MGC-MG
> > pair where the
> > > MG happens to connect to tone signaled lines, then the MGC
> > would be send
> > > the digits to the MG as they arrive from the other end, if
> > the end-of
> > > string cannot be identified by the MGC. Under the current
> > rules, the MGC
> > > would always have to wait until the previous digits sent as
> > signals were
> > > acknowledged by the MG before sending the next received
> > rather than just
> > > passing them down.
> > >
> > > I know that this does not necessarily need the timing
> > requirements that I
> > > described for the announcement case, but it should still be
> > considered,
> > > particularly with respect to the scaling of the MGs and
> > MGCs. While the
> > > round trip time of an individual transaction may be small,
> > what is the
> > > effect of many small transactions in a large MG or many
> > small MGs connected
> > > to a single MGC.
> > >
> > > >This is where our customer advocate comes in.  He
> > identified such a customer
> > > >requirement.  He also pointed out that whether sequences
> > can be specified
> > > >all at once or only as they are played out depends to some
> > extent upon the
> > > >implementation.
> > > >
> > > >My conclusion from all this discussion, which began in
> > Redbank and has yet
> > > >to resolve itself, is that there may be real requirements,
> > but they are
> > > >specialized.  Accordingly, they should be met using
> > specialized mechanisms
> > > >until we get a better idea of how general they are.  The
> > "simple Gateway"
> > > >group would be very happy to relegate every situation of
> > queued signalling
> > > >to a package.  In other words, the queuing aspect would be
> > defined as part
> > > >of the behaviour of particular signals.  As a concrete
> > example, a signal
> > > >would be defined within the MF or R2 package to outpulse a
> > specified string
> > > >of symbols in the respective signalling alphabet.
> > > >
> > > >For the complex announcement case, the signal concerned
> > would presumably
> > > >have a signalID parameter and an optional "queue after
> > signalID parameter"
> > > >for use by subsequent signals in a sequence.  It would be up to the
> > > >interested parties to define the required package, and its
> > support would be
> > > >limited to those MGs willing to support it.
> > >
> > > Since the definition of the parameter is package dependent,
> > it just moves
> > > the problem, and the discussion, to each package. This
> > means that if one
> > > wanted to support the overlapped sending case that I described above
> > > without requiring the wait for acknowledgement, then a
> > similar parameter
> > > would have to be defined in the dtmf, r2, mf, etc. packages
> > as well. Now we
> > > have four or five debates instead of one.
> > >
> > > It seems that by allowing signal queues to be defined and
> > announcing the
> > > limits such as max number of queues and max number of
> > queued signals as
> > > root properties, we can satisfy both the "simple Gateway"
> > group (no queues)
> > > and the "complex" group (multiple signal queues and many signals).
> > >
> > > >Presumably we would discard the generic sequential signal
> > list mechanism for
> > > >now.
> > >
> > > I do not see this deletion as necessary.
> > >
> > > >Any further comments before I call the outcome?
> > >
> > > That's all for now.
> > >
> > > steve magnell
> > >
> > > Steven Magnell
> > > Chief Architect
> > > Dialogic, an Intel Company
> > > phone: +1 973-993-3000 ext. 6497; +1 781-383-0485
> > > fax: +1 781-383-2096
> > > mailto:[email-masked]
> > > http://www.dialogic.com
> >

---

From: Steven Magnell <[email-masked]>
Date: Tue, 7 Dec 1999 16:09:43 -0500

Peter, Brian and list members,

Needless to say I have to disagree with Brian & Peter. One of the
challenges of the megaco/h.248 protocol is that it must span an extremely
large range of media gateway implementations. It seems obvious to me that
an MGC controlling several trunking gateways, each terminating thousands
of lines is quite different from one that acts as a PBX controlling
hundreds or thousands of dumb IP phones.

The current draft of the protocol is far from simple and is definitely
extreme overkill for the simple dumb devices that Peter is interested
with. On the other hand it is quite crippled in the area of signals and
events where some programmable autonomy in large complex MGs would reduce
the traffic and delay between an MGC and its MGs. (there is only one
level of embedding, there is no way to send a signal or set an event on
another termination, etc.)

An MGC must cope with whatever limits are placed on it with respect to
the MGs that it controls. It is not limited to queuing. Virtually every
aspect of the protocol will have some limit associated with the MG
implementation: number of outstanding transactions, number of commands
that can be addressed in a transaction, size and number of active digit
maps, lengths of any of the variable length descriptors, limits on
terminations, contexts, streams, etc. Why is there this focus on signal
queuing?

The proposal allows a simple gateway to explicitly define its limits such
that an MGC can adapt to it. It allows a simple gateway to not implement
queuing, remaining simple, but also allows more complex gateways to
assume some greater level of functionality. If my environment expects to
support complex MGs, then the MGC can benefit from the function. If it
only supports simple IP phones then it cannot.

I do not believe that you can extend the semantics and syntax if the
protocol through the package mechanism to accommodate a generic service
such as this.

steve magnell

At 09:09 AM 12/7/99 -0600, Peter Blatherwick wrote:

<excerpt>

<fontfamily><param>Arial</param>I agree with Brian on this one.  Two
primary reasons:</fontfamily>

<fontfamily><param>Arial</param>1. Lets keep it simple until we know more
about the problem </fontfamily>

<fontfamily><param>Arial</param>   and see clearly that there are
sufficient cases (with </fontfamily>

<fontfamily><param>Arial</param>   multi-package interactions) to warrant
a general </fontfamily>

<fontfamily><param>Arial</param>   mechanism.  </fontfamily>

<fontfamily><param>Arial</param>2. I do not want to burden all MGs with
functionality needed </fontfamily>

<fontfamily><param>Arial</param>   by a few relatively complex ones.  I
see dynamic queuing </fontfamily>

<fontfamily><param>Arial</param>   and simultaneous play as not needed by
most applications.  </fontfamily>

<fontfamily><param>Arial</param>   At a minimum, they must be able to be
turned off, as </fontfamily>

<fontfamily><param>Arial</param>   suggested by others.  (And yes, the
sequential signal list </fontfamily>

<fontfamily><param>Arial</param>   should be optional to implement in the
MG for the same </fontfamily>

<fontfamily><param>Arial</param>   reason, as it is.)   </fontfamily>

<fontfamily><param>Arial</param>For now, I believe we should keep this
stuff contained in </fontfamily>

<fontfamily><param>Arial</param>packages that need it.  An excellent
topic to work through in </fontfamily>

<fontfamily><param>Arial</param>detail in the next revision, but lets
finish version 1 first.   </fontfamily>

<fontfamily><param>Arial</param>-- Peter Blatherwick,
minimalist</fontfamily>

<fontfamily><param>Arial</param>-----Original Message-----</fontfamily>

<bold><fontfamily><param>Arial</param>From:  </fontfamily></bold>
<fontfamily><param>Arial</param>Rosen, Brian [SMTP:[email-masked]]</fontfamily>

<bold><fontfamily><param>Arial</param>Sent:  </fontfamily></bold> <fontfamily><param>Arial</param>7 Dec, 1999 08:54</fontfamily>

<bold><fontfamily><param>Arial</param>To:    </fontfamily></bold> <fontfamily><param>Arial</param>[email-masked]</fontfamily>

<bold><fontfamily><param>Arial</param>Subject:       </fontfamily></bold> <fontfamily><param>Arial</param>Re: Signal Queuing</fontfamily>

<fontfamily><param>Arial</param>I think that this just highlights the issue that we</fontfamily>

<fontfamily><param>Arial</param>don't KNOW what future packages may need.  Simple</fontfamily>

<fontfamily><param>Arial</param>queuing may not be enough.</fontfamily>

<fontfamily><param>Arial</param>If you allow an MG to declare it has no queue, then</fontfamily>

<fontfamily><param>Arial</param>MGCs have to cope with no queuing.  If they can do</fontfamily>

<fontfamily><param>Arial</param>that, there is very little advantage to having the</fontfamily>

<fontfamily><param>Arial</param>queue (it would have to be something like a</fontfamily>

<fontfamily><param>Arial</param>reduction in the number of messages).  That kind of</fontfamily>

<fontfamily><param>Arial</param>optimization should be deferred until we understand</fontfamily>

<fontfamily><param>Arial</param>the problem better.</fontfamily>

<fontfamily><param>Arial</param>Brian</fontfamily>

<fontfamily><param>Arial</param>> -----Original Message-----</fontfamily>

<fontfamily><param>Arial</param>> From: Christian Groves [<underline><color><param>0000,0000,ffff</param><<mailto:[email-masked]>mailto:[email-masked]</color></underline>]</fontfamily>

<fontfamily><param>Arial</param>> Sent: Monday, December 06, 1999 3:51 PM</fontfamily>

<fontfamily><param>Arial</param>> To: [email-masked]</fontfamily>

<fontfamily><param>Arial</param>> Subject: Re: Signal Queuing</fontfamily>

<fontfamily><param>Arial</param>></fontfamily>

<fontfamily><param>Arial</param>></fontfamily>

<fontfamily><param>Arial</param>> G'Day Tom,</fontfamily>

<fontfamily><param>Arial</param>></fontfamily>

<fontfamily><param>Arial</param>> Well its the first time I've been called theoretical (maybe a</fontfamily>

<fontfamily><param>Arial</param>> thesis is</fontfamily>

<fontfamily><param>Arial</param>> in order :-) )but I think that Steven Magnell has highlighted</fontfamily>

<fontfamily><param>Arial</param>> some very</fontfamily>

<fontfamily><param>Arial</param>> practical issues.</fontfamily>

<fontfamily><param>Arial</param>></fontfamily>

<fontfamily><param>Arial</param>> Cases for both queing and synchronous playing have been highlighted.</fontfamily>

<fontfamily><param>Arial</param>> There may be other uses that other people haven't even thought up yet.</fontfamily>

<fontfamily><param>Arial</param>> We want a mechanism that relatively future proof. Having each package</fontfamily>

<fontfamily><param>Arial</param>> defining a mechanism, as Steven mentioned below just moves</fontfamily>

<fontfamily><param>Arial</param>> the problem.</fontfamily>

<fontfamily><param>Arial</param>> This could potentially mean that there are several</fontfamily>

<fontfamily><param>Arial</param>> queueing/synchronous</fontfamily>

<fontfamily><param>Arial</param>> playing methods that need to be supported in the media</fontfamily>

<fontfamily><param>Arial</param>> gateway adding to</fontfamily>

<fontfamily><param>Arial</param>> development costs and complexity in the MC and MG. Also trying to</fontfamily>

<fontfamily><param>Arial</param>> coordinate queuing/synchronous playing methods between packages could</fontfamily>

<fontfamily><param>Arial</param>> present unknown interaction problems. A generic method in the protocol</fontfamily>

<fontfamily><param>Arial</param>> would alleviate these problems.</fontfamily>

<fontfamily><param>Arial</param>></fontfamily>

<fontfamily><param>Arial</param>> Having two root properties: one for queue length and one for number of</fontfamily>

<fontfamily><param>Arial</param>> synchronous signals would control the complexity in the</fontfamily>

<fontfamily><param>Arial</param>> gateway. Setting</fontfamily>

<fontfamily><param>Arial</param>> each of these to one would effectively turn this functionality off.</fontfamily>

<fontfamily><param>Arial</param>> Simple gateways would still be simple.</fontfamily>

<fontfamily><param>Arial</param>></fontfamily>

<fontfamily><param>Arial</param>> Cheers, Christian</fontfamily>

<fontfamily><param>Arial</param>></fontfamily>

<fontfamily><param>Arial</param>></fontfamily>

<fontfamily><param>Arial</param>> Steven Magnell wrote:</fontfamily>

<fontfamily><param>Arial</param>> ></fontfamily>

<fontfamily><param>Arial</param>> > Tom and list readers,</fontfamily>

<fontfamily><param>Arial</param>> ></fontfamily>

<fontfamily><param>Arial</param>> > I am a little bit behind in my list reading, but since I am</fontfamily>

<fontfamily><param>Arial</param>> one of the</fontfamily>

<fontfamily><param>Arial</param>> > named advocates it seems reasonable to comment on a couple</fontfamily>

<fontfamily><param>Arial</param>> of points.</fontfamily>

<fontfamily><param>Arial</param>> ></fontfamily>

<fontfamily><param>Arial</param>> > At 02:58 PM 12/3/99 -0500, Tom-PT Taylor wrote:</fontfamily>

<fontfamily><param>Arial</param>> > ......</fontfamily>

<fontfamily><param>Arial</param>> > >The nub of the question is whether there is a real</fontfamily>

<fontfamily><param>Arial</param>> requirement for dynamic</fontfamily>

<fontfamily><param>Arial</param>> > >queuing of signals.  That is, is there a situation where</fontfamily>

<fontfamily><param>Arial</param>> the MGC does not</fontfamily>

<fontfamily><param>Arial</param>> > >know in advance which signals need to be played in</fontfamily>

<fontfamily><param>Arial</param>> sequence, and where the</fontfamily>

<fontfamily><param>Arial</param>> > >inter-signal timing requirements are so tight that there</fontfamily>

<fontfamily><param>Arial</param>> is insufficient</fontfamily>

<fontfamily><param>Arial</param>> > >time for a completion event to go to the MGC so the MGC</fontfamily>

<fontfamily><param>Arial</param>> can return the next</fontfamily>

<fontfamily><param>Arial</param>> > >signal to be played? Typically, by the way, discussion of</fontfamily>

<fontfamily><param>Arial</param>> this problem area</fontfamily>

<fontfamily><param>Arial</param>> > >involves announcements</fontfamily>

<fontfamily><param>Arial</param>> ></fontfamily>

<fontfamily><param>Arial</param>> > Aside from the case that I described in Washington, which involved</fontfamily>

<fontfamily><param>Arial</param>> > announcements, there is another possible case involving</fontfamily>

<fontfamily><param>Arial</param>> tones. In H.323</fontfamily>

<fontfamily><param>Arial</param>> > signaling, it is possible to do overlapped signaling and</fontfamily>

<fontfamily><param>Arial</param>> the requirement to</fontfamily>

<fontfamily><param>Arial</param>> > support such has been discussed in other fora such as ETSI</fontfamily>

<fontfamily><param>Arial</param>> Tiphon and the</fontfamily>

<fontfamily><param>Arial</param>> > (now seeming ancient) IMTC VoIP Forum.</fontfamily>

<fontfamily><param>Arial</param>> ></fontfamily>

<fontfamily><param>Arial</param>> > If one is using H.323, for example, as the signaling</fontfamily>

<fontfamily><param>Arial</param>> mechanism between two</fontfamily>

<fontfamily><param>Arial</param>> > gateways, it is possible that the gateway at the calling</fontfamily>

<fontfamily><param>Arial</param>> end is receiving</fontfamily>

<fontfamily><param>Arial</param>> > digits and passing them using the methods for overlapped</fontfamily>

<fontfamily><param>Arial</param>> signaling to the</fontfamily>

<fontfamily><param>Arial</param>> > called end. If the called end gateway consists of an MGC-MG</fontfamily>

<fontfamily><param>Arial</param>> pair where the</fontfamily>

<fontfamily><param>Arial</param>> > MG happens to connect to tone signaled lines, then the MGC</fontfamily>

<fontfamily><param>Arial</param>> would be send</fontfamily>

<fontfamily><param>Arial</param>> > the digits to the MG as they arrive from the other end, if</fontfamily>

<fontfamily><param>Arial</param>> the end-of</fontfamily>

<fontfamily><param>Arial</param>> > string cannot be identified by the MGC. Under the current</fontfamily>

<fontfamily><param>Arial</param>> rules, the MGC</fontfamily>

<fontfamily><param>Arial</param>> > would always have to wait until the previous digits sent as</fontfamily>

<fontfamily><param>Arial</param>> signals were</fontfamily>

<fontfamily><param>Arial</param>> > acknowledged by the MG before sending the next received</fontfamily>

<fontfamily><param>Arial</param>> rather than just</fontfamily>

<fontfamily><param>Arial</param>> > passing them down.</fontfamily>

<fontfamily><param>Arial</param>> ></fontfamily>

<fontfamily><param>Arial</param>> > I know that this does not necessarily need the timing</fontfamily>

<fontfamily><param>Arial</param>> requirements that I</fontfamily>

<fontfamily><param>Arial</param>> > described for the announcement case, but it should still be</fontfamily>

<fontfamily><param>Arial</param>> considered,</fontfamily>

<fontfamily><param>Arial</param>> > particularly with respect to the scaling of the MGs and</fontfamily>

<fontfamily><param>Arial</param>> MGCs. While the</fontfamily>

<fontfamily><param>Arial</param>> > round trip time of an individual transaction may be small,</fontfamily>

<fontfamily><param>Arial</param>> what is the</fontfamily>

<fontfamily><param>Arial</param>> > effect of many small transactions in a large MG or many</fontfamily>

<fontfamily><param>Arial</param>> small MGs connected</fontfamily>

<fontfamily><param>Arial</param>> > to a single MGC.</fontfamily>

<fontfamily><param>Arial</param>> ></fontfamily>

<fontfamily><param>Arial</param>> > >This is where our customer advocate comes in.  He</fontfamily>

<fontfamily><param>Arial</param>> identified such a customer</fontfamily>

<fontfamily><param>Arial</param>> > >requirement.  He also pointed out that whether sequences</fontfamily>

<fontfamily><param>Arial</param>> can be specified</fontfamily>

<fontfamily><param>Arial</param>> > >all at once or only as they are played out depends to some</fontfamily>

<fontfamily><param>Arial</param>> extent upon the</fontfamily>

<fontfamily><param>Arial</param>> > >implementation.</fontfamily>

<fontfamily><param>Arial</param>> > ></fontfamily>

<fontfamily><param>Arial</param>> > >My conclusion from all this discussion, which began in</fontfamily>

<fontfamily><param>Arial</param>> Redbank and has yet</fontfamily>

<fontfamily><param>Arial</param>> > >to resolve itself, is that there may be real requirements,</fontfamily>

<fontfamily><param>Arial</param>> but they are</fontfamily>

<fontfamily><param>Arial</param>> > >specialized.  Accordingly, they should be met using</fontfamily>

<fontfamily><param>Arial</param>> specialized mechanisms</fontfamily>

<fontfamily><param>Arial</param>> > >until we get a better idea of how general they are.  The</fontfamily>

<fontfamily><param>Arial</param>> "simple Gateway"</fontfamily>

<fontfamily><param>Arial</param>> > >group would be very happy to relegate every situation of</fontfamily>

<fontfamily><param>Arial</param>> queued signalling</fontfamily>

<fontfamily><param>Arial</param>> > >to a package.  In other words, the queuing aspect would be</fontfamily>

<fontfamily><param>Arial</param>> defined as part</fontfamily>

<fontfamily><param>Arial</param>> > >of the behaviour of particular signals.  As a concrete</fontfamily>

<fontfamily><param>Arial</param>> example, a signal</fontfamily>

<fontfamily><param>Arial</param>> > >would be defined within the MF or R2 package to outpulse a</fontfamily>

<fontfamily><param>Arial</param>> specified string</fontfamily>

<fontfamily><param>Arial</param>> > >of symbols in the respective signalling alphabet.</fontfamily>

<fontfamily><param>Arial</param>> > ></fontfamily>

<fontfamily><param>Arial</param>> > >For the complex announcement case, the signal concerned</fontfamily>

<fontfamily><param>Arial</param>> would presumably</fontfamily>

<fontfamily><param>Arial</param>> > >have a signalID parameter and an optional "queue after</fontfamily>

<fontfamily><param>Arial</param>> signalID parameter"</fontfamily>

<fontfamily><param>Arial</param>> > >for use by subsequent signals in a sequence.  It would be up to the</fontfamily>

<fontfamily><param>Arial</param>> > >interested parties to define the required package, and its</fontfamily>

<fontfamily><param>Arial</param>> support would be</fontfamily>

<fontfamily><param>Arial</param>> > >limited to those MGs willing to support it.</fontfamily>

<fontfamily><param>Arial</param>> ></fontfamily>

<fontfamily><param>Arial</param>> > Since the definition of the parameter is package dependent,</fontfamily>

<fontfamily><param>Arial</param>> it just moves</fontfamily>

<fontfamily><param>Arial</param>> > the problem, and the discussion, to each package. This</fontfamily>

<fontfamily><param>Arial</param>> means that if one</fontfamily>

<fontfamily><param>Arial</param>> > wanted to support the overlapped sending case that I described above</fontfamily>

<fontfamily><param>Arial</param>> > without requiring the wait for acknowledgement, then a</fontfamily>

<fontfamily><param>Arial</param>> similar parameter</fontfamily>

<fontfamily><param>Arial</param>> > would have to be defined in the dtmf, r2, mf, etc. packages</fontfamily>

<fontfamily><param>Arial</param>> as well. Now we</fontfamily>

<fontfamily><param>Arial</param>> > have four or five debates instead of one.</fontfamily>

<fontfamily><param>Arial</param>> ></fontfamily>

<fontfamily><param>Arial</param>> > It seems that by allowing signal queues to be defined and</fontfamily>

<fontfamily><param>Arial</param>> announcing the</fontfamily>

<fontfamily><param>Arial</param>> > limits such as max number of queues and max number of</fontfamily>

<fontfamily><param>Arial</param>> queued signals as</fontfamily>

<fontfamily><param>Arial</param>> > root properties, we can satisfy both the "simple Gateway"</fontfamily>

<fontfamily><param>Arial</param>> group (no queues)</fontfamily>

<fontfamily><param>Arial</param>> > and the "complex" group (multiple signal queues and many signals).</fontfamily>

<fontfamily><param>Arial</param>> ></fontfamily>

<fontfamily><param>Arial</param>> > >Presumably we would discard the generic sequential signal</fontfamily>

<fontfamily><param>Arial</param>> list mechanism for</fontfamily>

<fontfamily><param>Arial</param>> > >now.</fontfamily>

<fontfamily><param>Arial</param>> ></fontfamily>

<fontfamily><param>Arial</param>> > I do not see this deletion as necessary.</fontfamily>

<fontfamily><param>Arial</param>> ></fontfamily>

<fontfamily><param>Arial</param>> > >Any further comments before I call the outcome?</fontfamily>

<fontfamily><param>Arial</param>> ></fontfamily>

<fontfamily><param>Arial</param>> > That's all for now.</fontfamily>

<fontfamily><param>Arial</param>> ></fontfamily>

<fontfamily><param>Arial</param>> > steve magnell</fontfamily>

<fontfamily><param>Arial</param>> ></fontfamily>

<fontfamily><param>Arial</param>> > Steven Magnell</fontfamily>

<fontfamily><param>Arial</param>> > Chief Architect</fontfamily>

<fontfamily><param>Arial</param>> > Dialogic, an Intel Company</fontfamily>

<fontfamily><param>Arial</param>> > phone: +1 973-993-3000 ext. 6497; +1 781-383-0485</fontfamily>

<fontfamily><param>Arial</param>> > fax: +1 781-383-2096</fontfamily>

<fontfamily><param>Arial</param>> ></fontfamily><underline> <fontfamily><param>Arial</param><color><param>0000,0000,ffff</param><<mailto:[email-masked]>mailto:[email-masked]</color></fontfamily></underline>

<fontfamily><param>Arial</param>> ></fontfamily><underline> <fontfamily><param>Arial</param><color><param>0000,0000,ffff</param><<http://www.dialogic.com>http://www.dialogic.com</color></fontfamily></underline>

<fontfamily><param>Arial</param>></fontfamily>

</excerpt><<<<<<<<

---

From: Christian Groves <[email-masked]>
Date: Thu, 9 Dec 1999 15:04:14 +0100

G'Day Pete,

Well funnily enough I disagree.
1. I consider the overhead of implementating several different queueing
mechanism from different packages to be too much. Then when we find
there's problem I stuck supporting the mechanisms from different
packages (to be backwards compatible) and a new mechanism. Packages will
then have to be re-written to take this into account. Its a big job. One
that we can save.
2. With the mechanism proposed we can "turn queueing and simultaneous
playing off" why is this kept being brought up as an argument?
3. Both MG simple and complicated MG should be handled by the protocol.
I sure each vendor sees the value in producing one type or both. Is the
MEGACO group favouring one specific implementation?

Cheers, Christian