Subject: Gateways and call routing

From: Dimitris Terzis <[email-masked]>
Date: Fri, 2 Jun 2000 12:24:13 +0100

Hi there...

After the short list breakdown and a number of e-mails with
Tom Taylor, relating to a previous message that was not
delivered, I am resorting to your patience for discussing a
not-so-core-technology issue that has been puzzling me after
reading the MEGACO and TRIP documents
(DISCLAIMER: Not a MEGACO/TRIP/H.323 expert).

My questions relate to the definition of a VoIP gateway,
and to how it is realised by MEGACO for call routing.

My current understanding is that, following the H.323
model, a VoIP gateway has three major functions:

(a) Signalling Gateway (SG), for connectivity to SCN

(b) Media Gateway (MG), for handling the media path

(c) Media Gateway Controller (MGC), for terminating
the SCN and IP signalling, translating between the two,
and managing the MG resources.

As Tom pointed out,

> This is consonant with the H.323 architectural framework
> within which SG 16 addressed Megaco/H.248.
> MG-MGC-SG are functional parts of an H.323 Gateway,
> and it is the MGC which does the H.245 signalling.

As I understand it, these three functions/entities can exist
in any number within the (potentially distributed) VoIP gateway,
with the restriction that each MG has a controlling MGC,
which also communicates with an SG for the SCN signalling
path. Also, as far as I understand, MEGACO only covers
the MGC-MG part.

Tom's comment on the above was:

> The starting point for discussion is the intention within
> our architecture for the MGC to be the source and
> destination of all call signalling.  The SG is just a mediation
> function, and the MG has a similar mediation role in the case
> of in-band signalling.

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?

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?

(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?

(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?

(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?

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?

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?

Thanks for your attention.

Regards,

Dimitris

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 6 Jun 2000 16:38:18 -0400

> > 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.
>
> 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.
The physical SG has to be co-located with the physical MG because the D
channel of the ISDN is the same facility as the B channels.  To work
in your definition, you are moving a lot of intelligence into the MG,
which we both seem to want to get away from.

>
> 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...
All kinds of systems are possible, and no one knows what the "right"
answer is -- it's going to be different for different networks.
What works for you may or may not work for small and large network
operators.

I do know that some MGC  vendors plan to co-locate an SG with the MGC.
Part of the reason why SGs are often thought of as simple low level
devices comes from a popular way of making SS7 systems, where local
intelligence on the interface card terminates MTP2, while code in
the host cpu terminates higher layers.  This architecture derives from
the real time nature of the signalling, although with overall faster
processors, this may be less of a driver than it was.  None the less,
many seem comfortable with the definitions.

>
> > 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.
>
> 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...
I think that there is a general agreement that Applications processors
need to be separate functional entities.  One good reference is the
MultiService Switching Forum's architecture (http://www.msforum.org).
When I describe how MGCs work, it is usually a signalling interworking
function - interwork between one subscriber and another, a subscriber
and another MGC, or MGC to external gateway signalling such as SS7.
In this way, your definition and mine tend to converge, but maybe
I think we are talking about the MGC, and you want to call it the SG!

Right at the moment, I think our definitions are well understood, and
generally agreed to, and we have a lot of work to actually build and
field these systems.  There will be better ways that emerge from our
experience.  I'm bent on producing interoperable components right now,
so my push-back on changing architectures may be more reaction to the
state of our efforts than anything else.

The wonderfull thing about protocols, and architectures, is there are
so many to choose from!

Brian