Subject: Re: Signal Queuing

From: Peter Blatherwick <[email-masked]>
Date: Wed, 8 Dec 1999 08:45:57 -0600

Steve, list:

Just a quick note to clarify some of the words Steve is putting in my
mouth...

I do not make my Signal Queuing  minimalism comments from the perspective of
IP Phone only as implied.  Although I believe this is an important
application, it is certainly not the only simple gateway.  Same minimalism
considerations apply for example to any small residential/SOHO gateway,
cable/xDSL modem, control of non-gateway media appliances, etc, etc, etc.
In the grand scheme of things, I believe there will be very large numbers of
simple gateways out there in the real world, so I don't want to make Megaco
awkward to use for these.

Also, I am not really saying don't do the fancy queuing stuff it at all.  I
just think we need to work through it more carefully, and wish to move on to
completion of version 1, leaving the more complex and less understood to
version 2.  If there really is very urgent demand, and lots of cases to
warrant the extra work and delay (which I am not seeing myself), I can live
with a mechanism we can turn off and is optional to implement in the MG.
Starting simple and working up to complex only as proven needed is a better
way to design IMHO.

(I also don't think Megaco is extreme overkill for simple gateways, although
there are things I would like to see optional.  And I don't see IP Phone as
part of a PBX-like big box system, but rather a further distribution of an
already distributed Internet communication system.  I guess that's beside
the point for now.  ;-)

Nothing new said here, just clarification.

-- Peter Blatherwick, devout minimalist

> -----Original Message-----
> From: Steven Magnell [SMTP:[email-masked]]
> Sent: 7 Dec, 1999 16:10
> To:   [email-masked]
> Subject:      Re: Signal Queuing
>
> 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:
> >>>>
>
>
>       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
[snip]

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 8 Dec 1999 09:10:54 -0600

RE: Signal Queuing>And I don't see IP Phone as part of a PBX-like big box
system, but rather a further distribution of an already distributed Internet
communication system.  I guess that's beside the point for now.  ;-)

Actually Peter makes a an excellent point: Besides simplicity, standard SIP
IP phones as have surfaced at the last VON show are part of such globally
scalable distributed systems.

Henry

Henry Sinnreich
MCI WorldCom
400 International Parkway
Richardson, Texas 75081, USA

  -----Original Message-----
  From: Media Gateway Control (megaco)
[mailto:[email-masked]]On Behalf Of Peter Blatherwick
  Sent: Wednesday, December 08, 1999 8:46 AM
  To: [email-masked]
  Subject: Re: Signal Queuing

  Steve, list:

  I do not make my Signal Queuing  minimalism comments from the perspective
of IP Phone only as implied.  Although I believe this is an important
application, it is certainly not the only simple gateway.  Same minimalism
considerations apply for example to any small residential/SOHO gateway,
cable/xDSL modem, control of non-gateway media appliances, etc, etc, etc.
In the grand scheme of things, I believe there will be very large numbers of
simple gateways out there in the real world, so I don't want to make Megaco
awkward to use for these.

  Also, I am not really saying don't do the fancy queuing stuff it at all.
I just think we need to work through it more carefully, and wish to move on
to completion of version 1, leaving the more complex and less understood to
version 2.  If there really is very urgent demand, and lots of cases to
warrant the extra work and delay (which I am not seeing myself), I can live
with a mechanism we can turn off and is optional to implement in the MG.
Starting simple and working up to complex only as proven needed is a better
way to design IMHO.

  (I also don't think Megaco is extreme overkill for simple gateways,
although there are things I would like to see optional.  And I don't see IP
Phone as part of a PBX-like big box system, but rather a further
distribution of an already distributed Internet communication system.  I
guess that's beside the point for now.  ;-)

    -----Original Message-----
    From:   Steven Magnell [SMTP:[email-masked]]
    Sent:   7 Dec, 1999 16:10
    To:     [email-masked]
    Subject:        Re: Signal Queuing

    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:

  [snip]

---

From: Steven Magnell <[email-masked]>
Date: Wed, 8 Dec 1999 11:50:43 -0500

Peter et al,

At 08:45 AM 12/8/99 -0600, Peter Blatherwick wrote:

<excerpt>

<fontfamily><param>Arial</param>Steve, list:</fontfamily>

<fontfamily><param>Arial</param>Just a quick note to clarify some of the
words Steve is putting in my mouth...</fontfamily>

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

Sorry. I didn't mean to put words in your mouth.

<excerpt>>>>>

<fontfamily><param>Arial</param>I do not make my Signal Queuing
minimalism comments from the perspective of IP Phone only as implied.
Although I believe this is an important application, it is certainly not
the only simple gateway.  Same minimalism considerations apply for
example to any small residential/SOHO gateway, cable/xDSL modem, control
of non-gateway media appliances, etc, etc, etc.  In the grand scheme of
things, I believe there will be very large numbers of simple gateways out
there in the real world, so I don't want to make Megaco awkward to use
for these.

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

While not all of these devices a connected to a IP-PBX, they all have the
same model, a simple device with some kind of centralized control.
Whether it is enterprise control with an MGC as IP-PBX or public network
control with an MGC fulfilling the role of a CO switch is irrelevant. The
point that I was making is that the protocol is expected to service a
wide-range of MGs with a wide range of capacities and capabilities. I
don't want to make megaco awkward for either end of the spectrum.

steve

<excerpt>>>>>

<fontfamily><param>Arial</param>Also, I am not really saying don't do the
fancy queuing stuff it at all.  I just think we need to work through it
more carefully, and wish to move on to completion of version 1, leaving
the more complex and less understood to version 2.  If there really is
very urgent demand, and lots of cases to warrant the extra work and delay
(which I am not seeing myself), I can live with a mechanism we can turn
off and is optional to implement in the MG.    Starting simple and
working up to complex only as proven needed is a better way to design
IMHO.

</fontfamily>

<fontfamily><param>Arial</param>(I also don't think Megaco is extreme
overkill for simple gateways, although there are things I would like to
see optional.  And I don't see IP Phone as part of a PBX-like big box
system, but rather a further distribution of an already distributed
Internet communication system.  I guess that's beside the point for now.
;-)

</fontfamily>

<fontfamily><param>Arial</param>Nothing new said here, just
clarification.  </fontfamily>

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

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

<bold><fontfamily><param>Arial</param>From:  </fontfamily></bold>
<fontfamily><param>Arial</param>Steven Magnell [SMTP:[email-masked]]</fontfamily>

<bold><fontfamily><param>Arial</param>Sent:  </fontfamily></bold> <fontfamily><param>Arial</param>7 Dec, 1999 16:10</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>Peter, Brian and list members, </fontfamily>

<fontfamily><param>Arial</param>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.

</fontfamily>

<fontfamily><param>Arial</param>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.)

</fontfamily>

<fontfamily><param>Arial</param>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?

</fontfamily>

<fontfamily><param>Arial</param>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.

</fontfamily>

<fontfamily><param>Arial</param>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.

</fontfamily>

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

<fontfamily><param>Arial</param>At 09:09 AM 12/7/99 -0600, Peter Blatherwick wrote: </fontfamily>

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

<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>[snip]</fontfamily>

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

---

From: Christian Groves <[email-masked]>
Date: Wed, 8 Dec 1999 17:27:36 +0100

G'Day Peter and list,

I am coming from the point of view from very large MG and MGCs. The
functionality to queue and play synchronous events is something which is
needed from version 1 of the protocol. We can not afford to wait for
another year for version 2.

I believe the mechanism that we propose can be turned off by setting two
properties (synchronous and queue) to 1. I do not believe that having
two variables/constants is too awkward or clumsy for a simple
implementation. It allows simple gateways to do what they want and large
gateways to do what they want.

I do not buy the argument that this solution is immature. It has been
around since the SG16 RedBank meeting and nobody has been able to find
an error with it. The only concern/desire that has been expressed is to
be able to turn off queueing and synchronous playing which I believe has
been accomodated by adding the two properties to the root package. The
current functionality in the whitepaper doesn't allow this.

Let's not delay further and fix this...now.

Cheers, Christian

Peter Blatherwick wrote:
> I do not make my Signal Queuing  minimalism comments from the
> perspective of IP Phone only as implied.  Although I believe this is
> an important application, it is certainly not the only simple
> gateway.  Same minimalism considerations apply for example to any
> small residential/SOHO gateway, cable/xDSL modem, control of
> non-gateway media appliances, etc, etc, etc.  In the grand scheme of
> things, I believe there will be very large numbers of simple gateways
> out there in the real world, so I don't want to make Megaco awkward to
> use for these.
>
> Also, I am not really saying don't do the fancy queuing stuff it at
> all.  I just think we need to work through it more carefully, and wish
> to move on to completion of version 1, leaving the more complex and
> less understood to version 2.  If there really is very urgent demand,
> and lots of cases to warrant the extra work and delay (which I am not
> seeing myself), I can live with a mechanism we can turn off and is
> optional to implement in the MG.    Starting simple and working up to
> complex only as proven needed is a better way to design IMHO.
>
> although there are things I would like to see optional.  And I don't
> see IP Phone as part of a PBX-like big box system, but rather a
> further distribution of an already distributed Internet communication
> system.  I guess that's beside the point for now.  ;-)
>
>      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
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 8 Dec 1999 16:05:29 -0500

I have now read most of the messages posted on this track, and, frankly, I
am a bit puzzled by the scope of the discussion. Pretty soon, we seem to be
developping an all encompassing queue management protocol, when we don't in
fact need whether there is a real need for it. For example, I heard that
there would be no need for queue management in simple IP phones, but that
there would be an obvious need in big complex trunking gateways. Well, this
is in no case obvious to me. The only practicals examples of "queue
management requests" I know of arised precisely in simple IP phones. They
were related to the need of outputting several DTMF digits for outgoing
calls...

If we go back to ground zero, the basic need is that the MGC shall be able
to instruct the MG to play a sequence of signals on a termination. The MGC
shall be able to predict and control the behavior of the MG. In some cases,
the MGC shall be able to interrupt an existing sequence of signals. Any
solution that achieves that meets the first order requirements. There are
indeed many such solutions, which all have different trade-offs and
different costs. On the other hand, interoperability dictates that there
should be at least one solution, implemented in all MG.

A solution that basically meets all requirements is the "no queue"
solution. The MGC can push exactly one signal on the termination, and can
ask the MG for a notification when the signal has finished playing out. In
MGCP, we can use the "operation complete" event to that effect. This is
enough to place the MGC in control. The MG will always erase all existing
signals when receiving a new request. If the MGC wants to make sure that a
signal completes, it will wait for the notification before issuing a new
signal.

That solution can be easily extented in two ways, which are already defined
in the protocol. First, it is possible to capture the "operation complete"
event and use it to trigger an embedded request, thus getting rid of the
roundtrip delay between the completion of one signal and the issuance of
the next one. Second, it is possible, in a package, maybe in a root package
understood by all MG, to define an "atomic sequence" construct, a container
for a list of events that are to be executed in sequence. The operation
complete event would only be used when the sequence is complete; reception
of a new request would abort the sequence.

I contend that these two mechanisms are very probably sufficient in the
short term, until we know more about the requirements. In the longer term,
we will probably think of extension. Obviously, the "operation complete"
event could be captured by a script, allowing for a very precise management
of the queue. In fact, it seems that the most complex queue management
proposals that we have seen amount to a weak form of scripting, are only
half as good as a real script, and are thus not something that we should
rush in the spec.
-- Christian Huitema