Re: MMUSIC minutes

[Henning Schulzrinne <[e-mail]>]

Joerg Ott wrote:

>
> Message Bus for Call Control
> ----------------------------
> 
> 
> Joerg also reviewed the concepts for Mbus message semantics and
> described the simple command naming scheme allowing for generic as
> well as protocol/tool-specific commands to be described without the
> risk of name clashes.  He noted that protocol/media and tool-specific
> commands are defined for RTP, audio streams, and the Robust Audio Tool
> (RAT), respectively.  Then he focused on Mbus commands for call
> control presenting a set of elements common to H.323, SIP, and ISDN
> and designed to be suitable for building gateways as well.
> (Protocol-specific messages are yet to be defined.)  As an example, he
> presented a call setup message (conf.call-control.call) along with its
> parameters in more detail.  Similar messages are defined for incoming
> call, accepting and rejecting calls, redirection, etc. as well as for
> event notifications (ringing, accepted, etc.).  Using ladder diagrams
> Joerg described sample call flows with Mbus-controlled SIP engines on
> both sides of a call.  Further call flows for other scenarios were
> shown as well.  He noted that the first revision of the call semantics
> Internet Drafts are likely to be targeted for Experimental to gain
> more experience before a Standards Track document will be pursued.
> 
> An issue was raised that the Message Bus commands for call control
> seem very similar to an API -- a seemingly similar work item was
> rejected by the Area Directors in the meeting of the SIP WG (SIP
> servlet API).  The chair agreed to discuss this subject with the Area
> Directors.  It was also noted that much more functionality as
> presented during the meeting (and specified in the draft so far) will
> be needed for e.g. call center applications.  Joerg pointed out that
> further commands were already under investigation (such as conveying
> DTMF, controlling announcements, etc.) and there were more to come.

Pardon me if I rehash things said at the meeting, but if one were to
replace "message bus" with "MGCP" or "Megaco", the paragraph would still
largely make sense. How much overlap is there between these? Obviously,
a message bus does multicast, but it may well be possible to use MGCP in
multicast mode.

> 
> Joerg also outlined a number of potential application scenarios for
> the Message Bus.  The fundamental idea is that Mbus enables modular
> system design (with components exchangeable at run time) and allows

such as the separation of MGC and MG...

> independence of programming languages.  The Mbus concept can be used
> to implement minimal browser plug-ins that use Mbus messages to talk
> to a powerful call control engine / conferencing system.  Also, Mbus

Reads like the motivation for MGCP :-)

> allows to create an open interface for remotely controlling
> stand-alone devices (such as IP telephone sets) from PCs/workstations.
> Many further areas of application are conceivable.
> 

I don't think we need three device-control protocols in the IETF. The
latter exactly duplicates the "residential gateway" application of
MGCP/Megaco.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs