Subject: Question: MGCP & SIP Interaction

From: Bobby Sardana <[email-masked]>
Date: Mon, 11 Jan 1999 13:50:54 -0600

Greetings:

Is there any available information which talks about:

a. If the signalling is SIP, then how will the MGCP inform the
   Gateway or any NE that SIP based URI's need to be forwarded to it
   for possible call control.

b. Or, can the MGCP perform call control if SIP is the signalling
   protocol.

It seems like MGCP relies on a digit map to be uploaded to the
gateway which is different than the combinations, URI's, email etc.,
like addresses of the SIP.

Any information on this is appreciated.

Thanks.

Bobby Sardana.
ObjectSoftware, Inc.
[email-masked]

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 11 Jan 1999 17:56:44 -0600

> b. Or, can the MGCP perform call control if SIP is the signalling

I'll try and summarize what I think I know of current thinking:

There are several proposals circulating (or not, as the case may be)
including SIP+ and some drafts in progress that are grappling with just
these questions.

The short answer is that SIP would appear to be most useful with MGCP in
an "interdomain" or "between peers" role.

Once can visualize each cluster of MGCP-using gateways and gateway
controllers as a "domain" (or autonomous system, or whatever) -- a
"peer" in the SIP world. Within the cluster, the controller uses MGCP to
drive the gateways, control number mappings, collect digits, and so on.
Each gateway is completely unaware that SIP is involved in the picture.
The controller, on the other hand, understands SIP and MGCP, and uses
SIP to talk to other controllers and to other native SIP devices, like
netphone appliances and so on. So, the SIP sessions are not maintained
by the gateway, and MGCP call control originating from a gateway gets
mapped to SIP call control by the controller as appropriate. Of course,
the controllers must be aware of call state . . .

obligatory ascii art:

            |------|        |------|
  |----|    |	 |  SIP   |      |    |----|
  | GW |----| CONT |--------| CONT |----| GW |
  |----| M  |      |        |	     |  M |----|
         G  |------|        |------|  G
         C             	              C
         P      	                    P

MGCP to SIP to MGCP call flows map out pretty easily. Going to MGCP, the
controller would have the task of taking the SIP URIs indicating the
source and destination addreesses and reformatting them into numbers
that MGCP could understand. Coming from MGCP, the controller would also
have to format digits collected by the gateway into a SIP INVITE that
would then pass upstream to some sort of "smarter" SIP user location or
call routing server, then be routed to an egress cluster. Similar
operations happen for call control functions.

I personally imagine an MGCP cluster to be on the order of the size of a
medium to large switch, perhaps a couple of hundred thousand ports --
and to provide service over some geographic region, perhaps a "central
office" area. From a SIP perspective, the whole cluster is just a
gateway with lots of ports -- i.e., a single node..

All the cluseters may be operated by one carrier -- or perhaps
eachclusters might be opearated by a different carrier. Once you add
ecommerce functions and a lot of lawyers, SIP provides a basis for a
settlement model betwixt and between carriers (Thanks, Francois).

Note that the problem becomes much hairier if you do a conversion to
ISUP or TUP or CAS somewhere in the process, and even more so if one
goes from PSTN to SIP and back again, say ISUP-SIP-ISUP, and worse yet
if different regional or vendor dialects are used on each side of the
SIP network This gives us the reason for SIGTRAN . . . and probably a
good reason for beer, too, so I'm leaving now.

--
Dean