Subject: Re: NEW TOPIC: Enhanced Services using SIP and MGCP

From: "David Shrader" <[email-masked]>
Date: Tue, 9 Nov 1999 07:51:51 -0500

Greg,

I'm glad you brought this topic up on the list. I've been asking myself the
same types of questions. If I were building an enhanced services platform
and want to use "standard" protocols, which one(s) do I use? Because of the
differences between the two protocols, do I use one for some applications,
and the other for everything else? Would the softswitch even know ahead of
time what an application is going to require to adequately select the right
protocol when delivering the call to the server?

I need time to think through your questions, but I wanted to support and
encourage this topic on the list.

David

-------------------
David Shrader
Master Consultant, Inc.
[email-masked]

-----Original Message-----
From: Gregory D. Girard <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, November 09, 1999 7:31 AM
Subject: NEW TOPIC: Enhanced Services using SIP and MGCP

>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.
>
>
>
>
>
>
>
>