Subject: Design Team Conference Minutes

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 22 Nov 1999 23:14:08 -0500

A Megaco design team conference call was held today from 11:00-13:00 EST.
The attendees were myself plus those people listed in the "cc:" list of this
message.  The business of the call was not completed; a continuation call
will be held tomorrow morning starting at 9:00 am EST.  Call details are as
follows:

Phone Number:                             260-6338,     Passcode 727674 #
Alternate Phone Number:       919 905-6338      Passcode 727674 #
Duration 60 minutes
Number of Lines 15

Today's discussion generally followed the outline provided by Brian Rosen's
message "Washington Issue Roundup", sent Friday afternoon at 3:40 pm EST.

1. "Audit of Ephemerals at Startup (name pattern)".  Name pattern as a root
property agreed in principle.  Details on the description language are still
being worked.  (Action: Christian Groves and Brian Rosen) Get around the
64-character limit by listing separate items.  Tom noted that current trunk
group naming practice in telephone offices exhibits a moderate amount of
hierarchy (CLLI begins with name of far-end office, suffixes sort out
individual trunk groups to same destination, individual trunks identified by
member number within group), but there can still be several hundred root
name prefixes.  Lines are easier - identified by physical location or
telephone number.

Flowing from this item there was a brief discussion of the current position
that the same termination can support different transports on a per-stream
basis.  Brian Rosen was adamant that this was necessary to coordinate
streams bound to the same user, while John Segers earlier presented a case
where the same user received different streams through different
terminations.  This seems to be a matter of style of usage.  Danny Levin
raised his point that the semantics of an ephemeral termination are unclear.

Synchronization of streams is an open issue related to this discussion.
Danny suggested there is another open issue related to the manipulation of
streams using the topology descriptor -- at the moment routing is
all-or-nothing for a given termination.  Further work on multistream
operation is clearly needed to resolve these issues.  (Action: Tom Taylor,
John Segers, Danny Levin)

2. "Controlling output of Audit".  Agreed on the "W-" qualifier, union of
capability values, as proposed by Brian.

3. "Packages adding properties to root".  It was accepted in principle that
packages defining per-termination properties can also define aggregate
properties related to the same package.  The open issue is whether such
aggregate properties should be properties of all of the terminations
supporting the package concerned, of ROOT, or of some intermediate entity.
Tom Taylor is allowed one message to convince the skeptics that the first
answer is definitely the wrong one.

4. "Events".  Lots of discussion, more research needed.  (Contradictory
accounts have been received from MGCP specialists.)  As summed up by John
Voelker, there are two issues:
(1) How to determine which events get buffered while the MG awaits an update
to the EventDescriptor following a notification;
(2) Whether the next or all eligible events are passed to the MGC when the
new EventDescriptor arrives.

The first issue arises because it may take explicit assignment of hardware
resources in the MG to allow detection of some events.  The EventDescriptor
which caused event buffering to begin may not indicate all of the events
which may be of interest when the new EventDescriptor arrives back from the
MGC.  MGCP reportedly includes a DetectedEventsDescriptor which optionally
names additional events to be detected during the buffering period beyond
those in the old EventDescriptor.  The question is whether such a mechanism
is really needed in practical situations.

With regard to the second issue: Brian Rosen proposed a strict FIFO queue
model of event processing: when event buffering is terminated by the arrival
of a new EventDescriptor, buffered events are processed in order of arrival
until one is found which generates a notification.  At that point buffering
begins again, possibly without clearing all of the events accumulated during
the previous buffering period.  Some concerns were expressed over how much
delay might accumulate according to this model, with the alternative being
that all notifiable events in the buffer be reported in the same message.
Brian's approach does have the advantage of guaranteeing that the MGC always
has precise control over which events are reported to it, and in the most
common buffering case, digit collection, the digit map will absorb multiple
events at once so that delays will not accumulate as feared.

In response to the expressed concerns, Brian proposed an alternate model
where the MGC has explicit control over whether buffering happens.  While
buffering is enabled, events are processed according to Brian's head-of-line
model.  When it is turned off, all events in the current EventDescriptor are
notified to the MGC in the same message and the buffer is cleared.

5. "Signals".  Discussion deferred.

6. "Extensions".  Brian made the point that if an MG or MGC does not
understand an extension, it will generally return an error identifying the
extension, regardless of whether the extension is flagged by preceding it
with "X-" (or binary equivalent).  We should therefore reserve the use of
"X-" to cover cases where the extension should simply be ignored (??? - and
generate a warning) rather than causing a command to fail.  (Action: Brian
and Abdallah to check our ABNF for places such as error codes where this
sort of indication would be useful.  John Segers to follow through on binary
side.)  Danny Levin noted that extension markers are useful in cases where
an intervening system has to pass on information understood only by the
endpoints.  However, Megaco does not (yet) operate under such conditions.
(Proxying was identified early on as a matter for future work.)

7a. "Generic error event".  Christian's proposal accepted in principle.
"Normal release of bearer" should instead be called "unexpected release of
bearer".  Tom Taylor noted that the event will typically be related to a
particular stream, so that streamID is a required parameter.

7b. "Time format".  8 character UTC.  Last two characters give tens of
milliseconds (AKA hundredths of a second).  Optional timestamp may be
included in the ServiceChange command.

8. "Deleting multiplexed bearers".  Accepted in principle -- Brian and
Christian still working details.

9. "Wildcards in SDP".  Discussion deferred.

10. "Whitespace in SDP".  Consensus to follow the SDP specification (no
leading white space).

11. "ATM bearer descriptions in SDP".  Tom related discussions he has been
having with Joerg Ott (Chair of MMUSIC) and Scott Bradner over Megaco
requirements for changes to SDP.  Scott prefers that MMUSIC control SDP.
Joerg wants MMUSIC to control the SDP mechanisms and protocol, but leave
detailed syntax additions up to other groups.  Action: Tom Taylor and Brian
Rosen to assemble a clear view of what Megaco needs and how we can get it.

12. "Synchronization of Streams".  See discussion following point 1.
Action: Tom Taylor, Danny Levin, John Segers to work the issue.

13. "Receipt of Duplicate Request when Pending".  Closed.

14. "Errors while parsing".  Closed.

15. "Scope of names".  Closed.

16. "Confusion on Virtual MGs".  Opinions on this one seemed to range
widely.  Christian saw the section as essential to show that we had at least
thought about the issue, while others saw the whole thing as an
implementation issue at this point, and the section as something we could
leave out.  Resolution at this point is to take deletion of the section as a
working hypothesis, but see as a low-priority effort if it can be made
sufficiently clear to be of value.  Action: Michael Brown to pass Tom Taylor
the criticisms his developers have come up with.  Tom to look at how the
section could be clarified in the light of these criticisms.

17. "Use of Choose in Property Values".  Accepted.  Also agreed that
wildcard "ALL" is NOT meaningful when specifying property values.

18. "Wildcard Subtract".  Will allow Subtract * * as a reset mechanism, but
with warning text to point out that it means that all existing connections
are lost.

19. "Arbitrary wildcard".  Closed.

20. "Return of Termination ID".  Brian prevailed -- it's optional when
commands succeed.

21, 21a, 22 not discussed -- time ran out.

Tom Taylor
Advisor -- IPConnect Standards
E-mail: [email-masked] (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961

---

From: John Segers <[email-masked]>
Date: Tue, 23 Nov 1999 12:40:38 +0100

> 2. "Controlling output of Audit".  Agreed on the "W-" qualifier, union
> of capability values, as proposed by Brian.

Yesterday I missed the discussion on this subject.  I agree that we need
a way to reduce the information returned upon Audit, and allowing
wildcards is a good idea.

However, I'm not comfortable with the syntax for it.  In my view, the
Audit command should take parameters to specify what results the MGC
wants.  These parameters specify which descriptors to include in the
response.  I feel that an optional parameter specifying whether a
detailed or wildcarded response is desired is a better solution than
introducing command prefixes.

We can debate whether such a parameter makes sense for other commands as
well.

John

--
John Segers                                  email: [email-masked]
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

---

From: John Segers <[email-masked]>
Date: Tue, 23 Nov 1999 13:48:02 +0100

All,

I noticed in Tom's meeting notes that I have work to do.  Earlier today
I posted a message to the megaco list (in response to Chip Sharp's
message) about the synchronization issues.  In that message I proposed
roughly the following

1) (outgoing) streams to one user that have to be synchronized have to
be on one Termination
2) All (outgoing) streams on the same Termination are synchronized by
default.

Maybe 2) has to be restricted a little: synchronize streams that use the
same transport and have real-time properties (audio, video, not data).

Streams that go to one user and do not have to be synchronized can be on
different terminations.

I think these are reasonable for initial multimedia capabilities and
they don't require any changes to the syntax.

I missed the discussion on naming patterns in yesterday's call.  I feel
that including a naming pattern property is not sufficient for
establishing control relationship between an MGC and a trunking MG;
maybe it's different for residential GWs.

John

> 1. "Audit of Ephemerals at Startup (name pattern)".  Name pattern as a
> root property agreed in principle.  Details on the description
> language are still being worked.  (Action: Christian Groves and Brian
> Rosen) Get around the 64-character limit by listing separate items.
> Tom noted that current trunk group naming practice in telephone
> offices exhibits a moderate amount of hierarchy (CLLI begins with name
> of far-end office, suffixes sort out individual trunk groups to same
> destination, individual trunks identified by member number within
> group), but there can still be several hundred root name prefixes.
> Lines are easier - identified by physical location or telephone
> number.
>
> Flowing from this item there was a brief discussion of the current
> position that the same termination can support different transports on
> a per-stream basis.  Brian Rosen was adamant that this was necessary
> to coordinate streams bound to the same user, while John Segers
> earlier presented a case where the same user received different
> streams through different terminations.  This seems to be a matter of
> style of usage.  Danny Levin raised his point that the semantics of an
> ephemeral termination are unclear.
>
> Synchronization of streams is an open issue related to this
> discussion.  Danny suggested there is another open issue related to
> the manipulation of streams using the topology descriptor -- at the
> moment routing is all-or-nothing for a given termination.  Further
> work on multistream operation is clearly needed to resolve these
> issues.  (Action: Tom Taylor, John Segers, Danny Levin)