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

From: "Gardell, Steve" <[email-masked]>
Date: Mon, 15 Nov 1999 09:02:15 -0500

An insightful description and a good start
at a list of basic requirements. I would 
prefer to think of the Enhanced Services 
platform as managing a set of connections,
some of which might involve MG's. e.g. a
network of SIP phones talking to each other
and to MG's.

Steven Gardell
GTE Laboratories
Voice: 781-466-2681, Fax: 781-466-3375

> -----Original Message-----
> From: Gregory D. Girard [mailto:[email-masked]]
> Sent: Tuesday, November 09, 1999 7:28 AM
> To: [email-masked]
> 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.
> 
> 
> 
> 
> 
> 
>

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 15 Nov 1999 09:04:26 -0600

>I would 

Agree 100%.

Henry

Henry Sinnreich
MCI WorldCom
400 International Parkway
Richardson, Texas 75081, USA 

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Gardell,
> Steve
> Sent: Monday, November 15, 1999 8:02 AM
> To: 'Gregory D. Girard'; [email-masked]
> Subject: RE: NEW TOPIC: Enhanced Services using SIP and MGCP
> 
>