Subject: [IPTEL] TRIP questions

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

Hi there...

I am trying to figure out how the establishment of the end-to-end paths
for signalling and media will happen, in an IP Telephony network using
TRIP for call routing.

Given the generalised definition of a VoIP gateway, as provided by
MEGACO (RFC 2805 etc.), the Signalling Gateway, the Media Gateway
and the Media Gateway Controller can be completely independent
components, even substantially spaced apart.

Suppose that I run TRIP. Then, at each hop, the relative LS can give me the
NextHopServer, which (presumably) is the signalling server of the protocol
defining this route (destination), apart from the first hop, where the
enquiry may come from the user terminal (e.g., a SIP UAC). This way,
signalling messages can reach the other end of the path, which can be
several hops away from the caller.

I am not clear as to what the implied behaviour, AFTER the
acceptance of the call at the signalling level, will be. How is the media
path
determined? Not by TRIP, of course, but is TRIP's position that "we just
assist in finding the signalling path, then let the signalling servers deal
with
the establishment of the media path"?

Also, what is the anticipated number of gateways participating in a
GSTN-to-IP call, for the TRIP routing model? Is it always one per different
network cloud traversed ("The selection of an egress gateway for a telephony
call, traversing an IP network towards an ultimate destination in the PSTN"
(and vice versa), as mentioned in Section 3 (Introduction))?

Finally, at the start of Section 3, the text reads "TRIP can be used to
exchange attributes necessary to enforce policies and to select call routes
based on path or gateway characteristics." Is it at all envisaged that the
advertised (signalling) routes will/could also contain media-realted
attributes (e.g., codecs) of a gateway (for example, using the
Capability Information parameter)?

Thanks for the 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/
---------------------------------------------------------------

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 02 Jun 2000 12:10:41 -0400

Dimitris Terzis wrote:
> determined?

The purpose of the signaling messages is to exchange, between end
systems (PCs, softphones, softswitches, or whatever), the IP addresses
to use for media. Thus, "routing" of media itself is handled directly by
the IP network. 

> Not by TRIP, of course, but is TRIP's position that "we just

Signaling servers have no role in the establishment of the media path,
nor does TRIP.

> (and vice versa), as mentioned in Section 3 (Introduction))?

TRIP would not help in a GSTN to IP call, rather in an IP to GSTN call.
How many gateways in such a scenario? Not sure what that means. Clearly
only one gateway terminates the call. The number of gateways that can be
propagated through TRIP itself is huge, and thats the point for having
TRIP in the first place.

> Capability Information parameter)?

We discussed this. It would not be part of the capability information in
TRIP itself, as that refers to TRIP capabilities negotiation between
peers. The problem with such attributes is that they are not
aggregatable, and so we decided to leave them out of TRIP for now. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Dimitris Terzis <[email-masked]>
Date: Fri, 2 Jun 2000 23:25:38 +0100

Jonathan,

Thanks for your comments. I have a rather different model of operation in
mind, which (on a second reading), I have to admit made what I was asking
much less clear (mea culpa). So, I 'll try to give it another run...

> to use for media. Thus, "routing" of media itself is handled directly by

Of course, but what happens _above_ the network layer? Suppose that, for
some reason, I want to have a _specific_ set of gateways in my media path
during a call. Is there any way to build such a path with TRIP information?
This rather gets closer to source routing...

> > assist in finding the signalling path, then let the signalling servers
> > deal with the establishment of the media path"?
>

I just mean that they will distribute the IP addresses for the media, as you
point out above. As for the role of TRIP, please refer to my previous
question.

> propagated through TRIP itself is huge, and thats the point for having

Of course only one gateway terminates the call, but would you completely
rule out the possibility of needing more than one gateway on an end-to-end
call path? Or a "pure IP" call, where the gateway would be needed for, say,
media conversion only? (You can also see this as a special case of
GSTN-to-IP, or GSTN-toIP-toIP if you prefer, although I did not mean any
direction in the original message).

> > exchange attributes necessary to enforce policies and to select call
> > routes based on path or gateway characteristics." Is it at all envisaged
> > that the advertised (signalling) routes will/could also contain
media-realted
> aggregatable, and so we decided to leave them out of TRIP for now.

Sure, and this philosophy is clearly mentioned throughout the TRIP spec.
I was just trying to figure out whether we could find a way of deciding
to include some gateway(s) in the media path, based on advertised
capabilities (a source route maybe?) I am referring to the generalised
generalised concept of a gateway here, where you would expect even the
signalling servers to be part of a gateway (its MGC, to be exact)...

Cheers,

Dimitris

---

From: "Hussein F. Salama" <[email-masked]>
Date: Fri, 02 Jun 2000 16:09:55 -0700

> This rather gets closer to source routing...

Routing the media is outside the scope of TRIP, but the signaling
servers involved in call setup can do source routing by manipulating the
transport addresses of the media streams.

> > Signaling servers have no role in the establishment of the media path,

We've discussed this before. In some cases, it is desirable to control
the media path, and to insert media proxies along that path. For
example, QoS and Accounting at intermediate domains. However, this is
definitely outside the scope of TRIP.

> direction in the original message).

A call with multiple intermediate signaling servers (signaling proxies)
is possible, that's what TRIP is about. Having multiple media proxies
along the media path is also possible, but outside the scope of TRIP. 

A pure IP call is also possible, if the IP destination has an E.164
number assigned to it, because E.164 is the only destination address
family TRIP currently supports.

Hussein

-- 
Hussein F. Salama
Cisco Systems
Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 03 Jun 2000 00:03:56 -0400

> This rather gets closer to source routing...

What do you mean by set of gateways? IP-PSTN gateways? The TRIP model is
a call that begins in some entity with IP access (could be a gateway
itself), terminates on one IP to PSTN gateway, and then ends within the
PSTN. There is no provision for routing calls that are
IP->PSTN->IP->PSTN->IP..... this is nearly impossible since it requires
integration with PSTN routing.

If you mean location servers - well, you could have them modify the
signaling messages to force the media through them, as Hussein suggests.
I still argue that in most cases this is a bad thing.

> direction in the original message).

Then these are not gateways in the sense as defined by TRIP. Maybe you
can explain the application you have in mind?

-Jonathan R.

---

From: Dimitris Terzis <[email-masked]>
Date: Sat, 3 Jun 2000 11:15:14 +0100

> What do you mean by set of gateways? IP-PSTN gateways?

More closer to MEGACO gateways (see also description at the end of this
message).

> The TRIP model is
> PSTN.

Is therefore TRIP only "unidirectional"? We already could do the other way
using phone numbers for terminals (which doesn't sound a bad idea at all to
me), but also I don't see why an expansion of the supported advertised
address families to IP would harm the protocol...

> There is no provision for routing calls that are

Absolutely...

> I still argue that in most cases this is a bad thing.

For Location Servers, I agree, if only because they 're not supposed to do
that... I actually have in mind gateways, but more general than the ones we
currently have in mind (see text a few paragraphs below).

> can explain the application you have in mind?

Yes. I am thinking of a (perhaps theoretical) global IP Telephony Network,
where terminals (either GSTN or IP) are reachable in any combination.
Addressing is dual: There is one E.164 address per IP destination, and every
GSTN number is reachable via a corresponding IP address (the one of its
access gateway).

The concept of a gateway also puzzles me. One good thing in the plain
vanilla telephony network is that all the "gateways" (i.e., the switches)
are integrated (or tightly coupled) devices, by contrast to IP, where, at
the application layer, we have Location Servers (to use TRIP terminology - I
prefer the expression "Call Routers"), Signalling Servers, Signalling
Gateways (with varying opinions as to what they do), etc., etc., etc., let
alone the multiplicity of devices at the network layer and below (which we
can ignore, though).

My opinion is that, if we are ever to see global IP Telephony (which I
personally doubt), we need a more clear framework, at least for the core
components of the network, which means, among other things, unifying all
these devices according to their role. Now, it might not be conceivable
making a combined LS + gateway (i.e, an IP Telephony corresponding of the
GSTN switch), but at least we could do that about the gateways.

Given the different types of signalling and media entities in an IP
Telephony call, a unified gateway (a gateway framework , if you prefer) can
only be perceived as an entity general enough to enclose all these entities
in one "package". This should be generic enough as to allow us, with very
little additional logic, to "mutate" it to anything from a single SIP Proxy
to a full-blown network of multiple signalling and media components,
advertised to the outside world as a unique entity. There is, of course, the
concept of the MEGACO gateway, but this is so closely modelled after the
H.323 one, that I am not absolutely convinced it is the answer (possibly
with a bit more work on it).

In the above (perhaps ideal) model, the type of terminals on either end of a
connection is irrelevant and you might expect that, for a "long-distance"
call, you will have _several_ gateways on the path, the same way it
currently happens in GSTN.

Of course, I realise that TRIP's model is much more specific (down to earth,
if you like) than the one I describe (hence the double figure of "this is
outside the scope of TRIP" comments I 've already got in this thread! :-),
but the original intention of the message was to verify how much of this we
could do with TRIP. I 've been watching this whole effort since TBGP and GLP
and went through all TRIP's drafts, but (to the expense of being considered
an... alien) I thought I could resort to the source for best information!
:-)

Thanks for the time and the very useful comments.

Regards,

Dimitris

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 04 Jun 2000 23:11:45 -0400

Dimitris Terzis wrote:
> me),

In this case it is not a routing problem, but a naming problem. See the
ENUM working group for a solution to that.

> but also I don't see why an expansion of the supported advertised

It would not; and the set of families is indeed extensible.

> GSTN switch), but at least we could do that about the gateways.

?? THis is exactly the opposite of the trend, which is to decompose
these monster gateways into now FOUR components - signaling gateway,
media gateway, gateway controller, and applications server.

-Jonathan R.

---

From: Dimitris Terzis <[email-masked]>
Date: Mon, 5 Jun 2000 12:07:05 +0100

Hi...

> media gateway, gateway controller, and applications server

I know... Well, it's another point of view. I think the important part is
the larger picture, i.e., how to provide for a trully large-scale ISTN (IP
Switched Telephone Network), and this rather depends more on routing, than
on how you define the gateway _internally_...

Cheers,

Dimitris

---

From: "Rishi Choudhary" <[email-masked]>
Date: Mon, 5 Jun 2000 16:41:40 +0530

I would need your help to understand the interoperability issue between
different VoIP stacks.

Are there any design issues to be considered , while developing an
independent stack , so that we do not have problems later when you try to
introduc einteroperability of this stack with any other stack. Moreover,
does Interoperability functionality sits on top of the stacks. What I mean
is, can we develop two stacks independently and work on interoperability
between the two at  a later period of time.

Are there any guidelines on that ???

Regards
Rishi Choudhary

Wipro Technologies
Bangalore

---

From: "Dave Oran" <[email-masked]>
Date: Mon, 5 Jun 2000 13:16:44 -0400

> integration with PSTN routing.
Well, if you think of the PSTN as either a single hop for which you inject a
static route into TRIP, or an IGP-based thing where you get the information
separately (e.g. from an SCP) and inject it, then actually this isn't so
hard. In fact, I think it's kind of neat that TRIP could do this fairly
easily as long as you make sure that each signaling hop is in the media path
and capable of packet/circuit conversion.

Of course the practical value of this is highly questionable, because the
intermediate transcoding and de-jittering at each PSTN interconnect point
will quickly add up to pretty poor voice quality and rather long delays.

Dave.

---

From: "Bob Wise" <[email-masked]>
Date: Tue, 6 Jun 2000 00:43:16 -0600

The APIs and message sets on top of the stacks are not
standarized, but I do suggest you look at the JAIN work
which is attempting to do that for Java applications.

<troll> Of course, for really high-performance applications, Java
is not appropriate. </troll>

We have been able in our softswitch system
to not only abstract between different H.323 implementations,
but also between H.323 and MGCP stack implementations,
so it can be done.

-Bob

-----------
Bob Wise
Chief Architect
Vsys, Inc. - "The Softswitch Company"
www.vsys.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Rishi Choudhary
Sent: Monday, June 05, 2000 5:12 AM
To: iptel
Subject: [IPTEL] Regarding Interoperability between VoIP Protocol stacks

Regards
Rishi Choudhary

Wipro Technologies
Bangalore