Subject: Re: Gateways and call routing

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 2 Jun 2000 09:13:35 -0400

> Given the previous, I have the following questions:
>
> (a) Is there a central entity within a distributed VoIP gateway,
> consisting of a number of SG's, MG's and MGC's, which
> would serve as its "representative" to the outside world
> (e.g., by advertising its capabilities to TRIP Location Servers),
> so that the gateway could be visible as an integrated entity
> by the outside world? Or an external mechanism would be
> used to discover (how?) these capabilities?
It is the MGC that is known to the outside world.  TRIP would point
to the appropriate MGC.

>
> Given that the MGC is (essentially) the Gateway Controller,
> one would expect that it would do this job, but what happens
> in the case of multiple MGC's? Is there any "leader" election
> process defined/implied?
There are several reasons to have multiple MGCs.  For reliability,
there might be more than one.  At any time however, only one
controls an MG.  The MG is connected to subscribers.  So, if you
think in terms of conventional telephone systems, the phone is connected
(somehow) to one MG, that MG is connected to one MGC, and the
directory number of that phone in the TRIP database would point
to the MGC that controlled that MG that was connected to that phone.

>
> (b) What is the preferable internal capability discovery
> for a VoIP gateway? There is, for instance, the MGC-MG
> Resource Discovery mechanism that allows the MGC to
> know of the media capabilities of the gateway, but what
> happens with signalling?
That is clearly outside the domain of Megaco.  In most circumstances
it is defined by the MGC-MGC signalling.  If you were to use SIP
for example, each phone would have a SIP URI, and the SIP UA
would be the MGC.  Nothing, of course, prevents one device (the MGC)
from looking like a million SIP UAs!

>
> (c) Where does a Signalling Server, and particularly
> an IP one (e.g., a SIP Proxy) fit in this gateway model?
> Is it part of an MGC?
Well, in the sense that one physical device can be both a UA and
a Server (of various kinds), and MGC can be a SIP server.  It
might not be a proxy server, since it has the UAs in it.

>
> (d) Is there any compelling reason why we should have
> Signalling Gateways that are (essentially) SCN clients
> (Signalling Processors), following the H.323 model,
> and then need mechanisms like SIGTRAN (RFC 2719)
> to communicate with the MGC?
Oh most definitely.  Suppose that the MG was connected to a PBX.
Suppose the PBX used ISDN signalling.  In this case, the MGC would
terminate Q.931.  However, the MG is the one that has the physical
connection, so the MG would terminate the signalling at Q.921,
and send the Q.931 to the MGC via SCTP.  In this case the SG is
collocated with the MG.

The other obvious case is where the MGC is doing interwork to the
PSTN.  In this case you might have SS7 links which are terminated
in a device which is not the MGC.  So, the SG terminates SS7 at, say
MTP2, and sends MTP3 to the MGC via SCTP.

>
> Why wouldn't we want to move all the external signalling
> functions to the SG (i.e., ask _it_ to do the translation
> between SCN and IP signalling), and only use the
> MGC as an internal management function, which also
> collects and advertises the gateway capabilities to the
> outside world?
We currently define the SG as a relatively dumb device, as we
define the MG as a relatively dumb device.  Your definition of
the SG as being a complete signalling interwork function overlaps
with our current definition of MGC.

Note that your definition could be made to work with the latter example
of PSTN signalling interwork, but not the former example of ISDN
signalling interwork.

At any rate, you are trying to redefine terms that we have
gradually come to consensus on, and, despite the fact that there
isn't a "right" or a "wrong" way to define anything, I believe that
you might be better off accepting the current definition.

>
> From the definition of a SG in RFC's 2719 and 2805,
> translation is one of the envisioned functions (at least
> for some cases).
>
> (e) Is the above model suitable for "pure IP" gateways?
> What happens, for example, when we want to connect an
> H.323 subnet to a SIP one? Or when we want to use only
> the media resources of a gateway (e.g., its codecs) in the
> middle of a call?
In the former case you need a SIP-H.323 interwork function,
which is neither an MGC or MG.  It could use an SG, but I suspect that
it would simply interwork H.323 to SIP.  There is effort to define
such an interworking function underway.

In the latter case of codec change in the middle of a call, it would
be very reasonable to have the codecs in an MG.  The controlling
MGC would have to somehow be in the middle of a signalling path.
The SIP/H.323 signalling mechanisms don't have explicit ways to do
that, but it can be constructed as a set of connections.  Use of
Megaco for this application is a very good use of the protocol.
Of course nothing stops you from making a single box with both the
MG and MGC functions, just like a current H.323 gateway, and then
you wouldn't need Megaco.  I'd be inclined to keep them separate,
but that's a product design decision.

---

From: Dimitris Terzis <[email-masked]>
Date: Tue, 6 Jun 2000 12:18:46 +0100

Hi Brian...

> MTP2, and sends MTP3 to the MGC via SCTP.

To clarify a bit my initial question, I didn't wonder if we need SIGTRAN,
but rather whether the SG could be something more generic/powerful...

> of PSTN signalling interwork, but not the former example of ISDN

I don't quite understand this... Why wouldn't it work for ISDN? Unless you
are referring to the need for a SG-MGC protocol (Q.931 in your example),
which is of course true but does not necessarily need to be (part of) the
GSTN signalling protocol, everything else is just a
point of view - i.e., where and how we define the network elements inside
the gateway.

If we don't insist that the SG be just a SCN termination point, I believe it
should work (with perhaps different scaling, path optimisation and
distributed processing needs/behaviour), as a matter of fact I 've
implemented a simple testbed (a GSTN-IP gateway) for the needs of my PhD
that does exactly that...

> you might be better off accepting the current definition.

Not redefine, just wonder if this is really the best way. Even the current
(H.323-biased) gateway model seems under alteration, as Jonathan Rosenberg
pointed out in a relevant discussion we 've recently had in the IPTEL list.
The idea is to extract the Application Server from the MGC and SoftSwitch,
as he said, does exacltly that...

> such an interworking function underway.

I think that a generic SG model, were the SG does all the signalling
(including conversions) wraps nicely around this.

> MGC would have to somehow be in the middle of a signalling path.

Agreed.

> but that's a product design decision.

I am also of the opinion to have these items separate. As I wrote above,
having a gateway with very few generic internal types of components (SG, MG,
MGC) and well-defined ways (API's, protocols) of interaction among these
components, seems to me as good enough a simplification of the IP Telephony
network model, leaving only Location Servers (Call Routers), Gateways and
Terminals to worry about...

Cheers,

Dimitris

---------------------------------------------------------------
    Dimitris Terzis
    PhD Candidate - Department of Computer Science, UCL
    E-Mail: [email-masked]
    URL : http://www.cs.ucl.ac.uk/staff/D.Terzis/
---------------------------------------------------------------