An Abstract Call Control Model for Modular SIP Implementations

The Message Bus (Mbus):

An Abstract Call Control Model

for Modular SIP Implementations

Jörg Ott [email protected]

Dirk Kutscher [email protected]

The Issue: Controlling an IP Telephone...

?

• HTTP?

• SIP?

• MEGACOP?

• …?

The Issue: Controlling an IP Telephone...

?

• HTTP?

• SIP?

• MEGACOP?

• …?

It’s not just about CTI-style control

of a telephone...

...it’s about creating

an integrated desk area environment!

Decomposing a Telephone...

Display

Keypad

Phone

Appl.

A

P

I

…further...

…and adding “external” entities

Desk

Environment

BTW: Mbus and (Telephony) APIs

User

Application

“Server”

Application(s)

Introducing Mbus (Message Bus)

… and Mbus is not...

u

MEGACO (or another form of wide area control)

u

CORBA

u

simply yet another RPC mechanism

u

...

Mbus is not an API…

u

but may well be used underneath emerging APIs

Mbus is a message-oriented coordination mechanism for

component-based systems.

Mbus Features (1)

u

Message-based communication between components

u

Simple(!) local group coordination

– autoconfiguration

– supports unicast, multicast, broadcast

u

Security mechanisms

– message authentication, encryption (optional)

u

Programming language independence

u

Capable of spanning multiple hosts (on a link)

u

Supports variety of interactions

– peer-to-peer, client-server, multipoint, ...

Mbus Features (2)

u

Collection of basic semantics

– synchronization, entity awareness, robustness

u

Building blocks for application semantics

– defined in guidelines documents

– voting/polling

– RPC-style

– transparent carriage of data

u

Extensibility through profiles

– to be defined for (classes of) modules and applications

Mbus Transport Overview

u

Tuple-based addressing

– (name:value) pairs

u

Group communication

– recipients flexibly chosen by destination address

– allows arbitrary grouping, semantics-based addressing, ...

u

Underlying Transport: UDP (multicast/unicast)

u

Mbus-layer Reliability

– provided for point-to-point only

– one-to-many is best-effort

u

Messages

– UTF-8 encoding

– header

Mbus Semantics: Profiles

u

Define generic building blocks

– e.g. voting/polling for policy modules

u

Define a framework for a particular type of application

– e.g. multimedia communication endpoints

– addressing scheme to use

u

Define Mbus “commands” for entities within a framework

– protocol engines, functional entities, etc.

– e.g. (G)UI, call/conference control, media channel, audio device

u

Profiles follow “Mbus guidelines”

Sample Message

<MESSAGE DIGEST BASE64 ENCODED>

mbus/1.0 4711 94593893434 R \

(module:ui media:audio id:[email protected]) \

(module:engine media:audio id:[email protected]) ()

rtp.ssrc (42)

rtp.source.cname (42 "[email protected]") rtp.source.name (42 "Dirk Kutscher")

security.encryption.algorithm ("des") security.encryption.key ("ABCDEF") security.encryption.state (1) audio.codec ("g711-u") audio.channel.coding ("redundant" "gsm") conf.transport.address (42 10.0.1.2 (50000 50001) 127) Header Configure RTP Configure codec Select codec Auth Info ENCRYPTED

Component Discovery and Identification

u

Components implement Mbus application profiles, sets of

– Mbus resource definitions

t RPCs

t events notifications t properties

– Naming schemes

t Use of Mbus addressing mechanisms

– Control Relations

u

Mbus entities announce their presence on the Mbus

– Mbus addresses used to express compliance to application profiles

u

Mbus entities enter control relationships with each other

– E.g.: A phone controller takes control of a call signaling engine

– Resources provided by an Mbus entity defined by application profiles it implements

Call Control Profile: Overview

Goal:

u Provide an abstraction from the specifics of a protocol e.g. (which SIP extensions are available)

– and allow simple applications to be protocol-agnostic

u But still preserve powerful features of individual protocols

– to support sophisticated applications (such as gateways) as well

Solution:

u Few general commands

u General commands: basic call control and supplementary services

u Protocol-specific commands

conf.call-control.xyz

Call Control Concept

u Controller/Controllee-Model

– Call control engine (e.g. SIP UA)

t implemenents call signaling protocol t has well-defined Mbus interface (“API”)

– Controller

t implements generic call control logic

t may interact with UI (if applicable), access user preferences, etc.

u Interactions

– RPCs

t controller requests actions from call control engine

– Event notifications

t call control engine reports call control events to controller (and others)

u Abstract Call Control Identifiers

– Call-leg

t differentiate multiple call-legs of a single call, e.g. for proxies

– Call identifier

t identifier of a single point-to-point call

– Conference identifier

Generic Basic Call Control Commands

Command issued by actor

u conf.call-control.call u conf.call-control.ring u conf.call-control.proceed u conf.call-control.accept u conf.call-control.reject u conf.call-control.redirect u conf.call-control.forward u conf.call-control.disconnect u conf.call-control.caps-set

Indication received by peer

u conf.call-control.incoming-call u conf.call-control.ringing u conf.call-control.proceeding u conf.call-control.connected u conf.call-control.rejected u conf.call-control.redirected u conf.call-control.forwarded u conf.call-control.disconnected u conf.call-control.caps-indicate

Outline: Mbus Interactions in an Endpoint

From a controller’s perspective:

u

Determine which (media) engines are available

u

Determine which features (codecs, etc.) they support

u

Inform SIP UA about these

u

Configure preferences into the SIP UA

u

Make SIP UA register with registrar

u

Place outgoing / accept incoming calls

u

Configure media engines according to SDP

u

Possibly re-configure media engines upon re-INVITEs

Call Setup

Traditional Telephony Services

u

Mbus commands for supplementary services

–

Focus on simplicity

–

Mapping to SIP (extensions)

u

Mbus abstractions for

–

Call Hold

–

Unattended Transfer

–

Attended Transfer

–

Call Park and Call Pickup

Example: Unattended Transfer

transferred (to C) REFER transfer (to C)

call (C) _{INVITE (C)}

A

B

Sample Application(s)

u

SIP endpoint

u

StarGate: SIP - H.323 - ISDN Gateway

u

AudioGate: ISDN - Mbone Gateway

u

SIP Redirect Server

u

Looking into stand-alone telephone sets as well…

u

Integration of awareness system ongoing...

All three use the same audio engine (RAT).

Conclusion

u

Mbus is a simple lightweight message-oriented

coordination protocol

– allows decomposing applications into components on a local link

– offers mechanisms for application extensibility and tailorability

– enables module re-use

– does not prescribe what to do with it

u

Abstract call-control model is a lean API for IP-Telephony

– small set of generic functions + protocol-specific extensions

– end systems, gateways, registrars, proxies/redirect servers, ...