Subject: NEW TOPIC: Enhanced Services using SIP and MGCP

From: "Gregory D. Girard" <[email-masked]>
Date: Tue, 9 Nov 1999 07:28:26 -0500

SIP versus MGCP for Interfacing Enhanced Services Platforms

*** DISCLAIMER: The following post is long one aimed at solving a much
larger problem than that immediately addressed by SIP. Please feel free to
ignore unless your interests lie in the interface between the softswitch and
an Enhanced Services Platform (based upon SIP an other protocols) ***

It is my observation that basic call completion and management operations
supported by SIP are not up to the level of control supported by MGCP.
Collection of DTMF digits according to a digit map stands as one example,
and while "possible" in SIP, is not a basic feature defined for SIP. At the
same time, MGCP provides excellent switching-matrix-oriented control over
low-level call control operations (including access to physical endpoints in
a matrix and DTMF digit maps) but does not provide the high-level signaling
required for more generalized "service-oriented" functionality. For example,
MGCP cannot tell me ultimately who the call came from nor to whom it was
directed, and is only capable of providing physical endpoint addressing.
As a result, it would appear that as an integration layer, neither SIP nor
MGCP alone would allow an enhanced services platform to receive a call and
render a complex service. Neither protocol has all the parts necessary to
support anything but the most simple, passively-activated enhanced service
(i.e. voice mail).

While it is understood that any number of SIP extensions could be created to
support such operations, it would basically require incorporating an MGCP
message set into SIP, along with some notion of local or virtual
"switching matrix" element to serve as a medium over which those
operations would be performed.

At the same time, MGCP could be exended as well, but being a simple
client/server protocol with a 1:1 mapping of call agent instance to MG, it
does not have all the relocation and proxy services of SIP. Besides, MGCP
associates a controlling element with some physical switching matrix
resource, thus resource contention and scaling problems would result by
presenting application-level call control as "bound" to some specific device
under control of the Softswitch, and the control element would not be
interfacing and not the softswitch itself.

***It is my impression that it is generally agreed that Enhanced Services
Platforms will work better if they talk to softswitches than MGs.

Where does that leave someone who wishes to tightly integrate an enhanced
services platform with a softswitch ? Does one extend one protocol to
incorporate features of the other ?  Does one establish and an MGCP
session for every SIP connection ? Is is feasible for SIP,
as will be specified in forthcoming embodiments, to incorporate low-level
call control features contained within MGCP, perhaps on a
session-by-session basis ?

Thus, for SIP-BCP-T to be useful as more than an inter-softswitch to
communictions mechanism for call setup/tear down, does it make sense
to rethink its mission in life with respect to enhanced services, or is that
capability
already inherent in SIP ? To say that any "SIP implementer" can add this
functionality
is not at all helpful because without general agreement of features it
becomes
impossible to promote vendor-specific extensions as any "standard" at all.
I am aware of the SIP call control extensions exist for blind transfer an
other such features.

I am also aware that the basic problem in putting SIP and MGCP together
relates to the fact that SIP is oriented to managing call sessions
whereas MGCP is oriented towards managing switching matrixes.
An Enhanced Service Platform needs to operate on both planes. But it
is the objective of my inquiry to avoid creating some ugly propriety
interface and instead rely upon standards as much as possible.

Basic features required for Enhanced Services Platform (ESP) intergration
with a softswitch include the following list below. This is an e-mail
message for general consideration written off the top of my head in 15
minutes and not an exhaustive treatment of the subject; so I would ask that
commentary of the items below focus on the general control issues as can
best be interpreted from the muddled presentation. The terms "call",
"connection" and "call leg" mean different things to different technology
domains. Keep in mind below that the ESP may incorporate the "announcement
server" in some cases, thus connections that require play/record of prompts
will potentially terminate on ESP.

1- Originate/Answer/Disconnect voice connections between any two network
addresses. Connections managed under control of Softswitch and potentially
even terminating on ESP for IVR purposes; all connections routed through a
MG under Softswitch control.

2- Monitor Q.931 (or equivelent) call state information for specified call
session under
control of Softswitch

3- Collect DTMF digits on specified connection

4- Generate DTMF digits on a specified connnection (for pager dialing
interface, for example)

5- Create/Add/Remove full or half-duplex call leg to call under control of
Softswitch, potentially terminating on ESP (all connections routed MG under
Softswitch control)

6- Transfer one call/connection to another

7- Originate/Answer/Disconnect connection under control of softswith with
media type of T.38 fax such fax image may be transmitted and received using
DSP fax algorithms residing in certain MGs under control of Softswitch.

Any commentary of accomplishing this level of interface using SIP would be
greatly appreciated. If nothing else, I offer to those thinking about SIP
some relevent context for the application of their work. It would seem that
interfacing
with ESP would be an important consideration for and future revisions of
SIP, and
thus this inquiry may stimulate some discussion of the topic.

Greg Girard
CTO
Iperia, Inc.

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 10 Nov 1999 06:51:00 -0600

> supported by SIP are not up to the level of control supported by MGCP.

For what it is worth, IMHO MGCP is very valuable to implement gateways to
PSTN while SIP has the promise of new services that go beyond what exists on
the PSTN, thus giving service providers reasons to invest in it. "S" stands
for any session and most Web/Internet real time services have yet to be
invented. The potential seems very big.

Henry

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Gregory D.
> Girard
> Sent: Tuesday, November 09, 1999 6:28 AM
> To: [email-masked]
> Subject: NEW TOPIC: Enhanced Services using SIP and MGCP
>
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Nov 1999 14:59:34 -0500

> supported by SIP are not up to the level of control supported by MGCP.

This is comparing apples and oranges. MGCP is about device
(specifically, gateway) control. SIP is about setting up calls and
sessions between participants, some of which may or may not happen to be
controlled by MGCP. It doesn't matter as far as SIP is concerned.

> support anything but the most simple, passively-activated enhanced service

Last I checked, SIP can support a whole host of enhanced services.
Perhaps you have some different definition of what these are.

> operations would be performed.

Why? A complete solution for IP telephony services might also include
RSVP, RTP, COPS, Diffserv, TRIP, and CPL, but I certainly wouldn't
advocate making these all one protocol. If you want to control a MG, and
then based on its input, signal setup of a call or some services, you
use both MGCP (to control the MG) and SIP (to signal the call
establishment).

> session-by-session basis ?

I don't see the issue here at all. All of the standard architectural
drawings for MGCP show the softswitch speaking megaco/mgcp to media
gateways, and SIP out to proxies and eventually to other softswitches.
The call services themselves aren't in MGCP. MGCP isn't about calls, its
about managing media connections. 

> already inherent in SIP ?

As I have mentioned above, numerous "enhanced services" are possible in
SIP. The presence of an ISUP payload does not change the ability of a
proxy to deliver these services. 

 To say that any "SIP implementer" can add this
> I am aware of the SIP call control extensions exist for blind transfer an

You seem to be implying that each service requires some kind of
extension ontop of SIP to work. That is just plain false. Services are
defined by the logic sitting on top of a SIP UA or proxy. The features
this logic invokes do not need anything beyond normal SIP services in
order to work. A simple example is call forward to voicemail on
no-answer. Lets say this service is being provided by a proxy. When it
receives a call, it looks up in its database the name of the called
party. Seeing that this customer subscribes to this service, the call is
forwarded to their currently registered address. Based on normal SIP
processing, the phone rings. After some time, the proxy decides that the
call is not answered. It sends a CANCEL, and per normal SIP rules, the
phone stops ringing. Then, the proxy forwards the INVITE to a specific
voicemail server, which answers and records a message. This service
didn't require any kind of special extension in the clients; its based
solely on logic that guides proxy operations.

> An Enhanced Service Platform needs to operate on both planes.

Why? Having no definition of "Enhanced Service Platform", its hard to
know what you mean. However, if you want call services, these reside on
SIP, since SIP handles call establishment. 

> thus this inquiry may stimulate some discussion of the topic.

You seem to have confused a lot of things together with this list. For
example, transferring a media connection (i.e., a MG first sends media
to A, then to B) is a clear MGCP function, but transferring a call is a
clear SIP function. To perform an actual call transfer using a
softswitch, you will need SIP to signaling the call transfer. The
softswitch then uses MGC to execute the connection transfer after the
new SIP call leg is set up.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: John Pickens <[email-masked]>
Date: Fri, 19 Nov 1999 21:17:31 -0800

I agree with Jonathan's comments.  I would add that an oversimplified set
of models for MGCP and SIP that shows both their differences and their
compatibility is:

MGCP is a protocol for remoting a (slightly smart) line card on a CO/PBX
across an IP network.

SIP is a protocol signaling from a user side PBX/CO to a network side
PBX/CO (when proxies are used, otherwise the user side PBX/COs talk to each
other directly)

Thus a client device implementing MGCP is a simple (slightly smart) line,
and routes media streams via the virtual media switch (aka IP)

Thus a client device implementing SIP is a PBX.

Thus a MGC/Call agent implementing MGCP is a Class5-CO/PBX.

Thus a proxy implementing SIP is a Class 4 CO.

This is oversimplified and slightly inaccurate, but maybe useful in helping
understand why MGCP and SIP work just fine in a network side server/proxy
CO/PBX and don't need any fundamental model extensions.

J

>new SIP call leg is set up.

John R. Pickens PhD 
COM21 VP Technology and CTO
408 953 9228, 510 459 4878 Cell