Subject: [IPTEL] Re: CPL's timeouts

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:20 +0530

Since CPL scripts can explicitly provide timeouts, server-based defaults
don't offer significant policy control to the server. However, they do
open up weird interoperability issues ("my script worked fine yesterday,
you upgraded the server and suddenly all my calls go to voice mail").
Given that we specify default for parameters in SIP, I would argue that
defaults in the spec aid interoperability and portability of scripts.
Too many tunable server parameters aren't in anybody's interest. Having
default parameters also allows "script testers" to reason about overall
script behavior, e.g., with several proxy attempts, how long will it
take overall until the call gets sent to voicemail.

Jonathan Rosenberg wrote:
>
> None defined right now as I recall. I'm not sure there needs to be a
> standard default. It might be OK for the proxy to set the default
> administratively.
>
> -Jonathan R.
>
> Kenny Hom wrote:
> >
> > Regarding the Call Processing Language (CPL) draft, are there default
> > timeout values for the elements that accept timeout as an argument if
> > the user does not specify a value?
> >
> > --
> > Kenny Hom
> > Senior Software Engineer
> > Vovida Networks, 2150 Trade Zone Blvd. 105, San Jose, CA 95131
> > [W] (408) 941-1790 / [F] (408) 941-1791
> >
> > ---------
> > This message came from the IETF IPTEL Working Group Mailing List.

---------
This message came from the IETF IPTEL Working Group Mailing List.

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 14 May 2000 23:14:40 -0400

Folks,

TRIP provides addressing information for SIP and H.323.  The addressing
information may be propogated for individual gateways or for "aggrigation
points".  Along with the address, the protocol is specified.  Currently,
that protocol is specified as "SIP" or "H.323".

I believe that H.323 alone may not be sufficient to convey how to get a call
routed when using H.323.  There are a number of protocols available in the
H.323 series of protocols.  There are three primary protocols that would,
and I propose should, be advertised along with the addressing data.  They
are: H.225.0 Call Signaling, H.225.0 RAS, and H.225.0 Annex G.

Currently, the support in TRIP is assumed be limited to H.225.0 Call
Signaling.  That works well when trying to connect directly to a gateway.
However, the aggrigtion point for H.323 devices or networks may be an H.323
Gatekeeper for a Border Element (as defined in Annex G of H.225.0), and
neither may support H.225.0 Call Signaling.

So, I would like to propose that provisions be added to TRIP to allow
addresses to be advertised along with three different supporting protocols
for H.323:
   H.225.0 Call Signaling
   H.225.0 RAS
   H.225.0 Annex G

The latter two, as I mentioned, are extremely important for build larger
networks where the aggrigation point is not an H.323 call signaling entity.

Best Regards,
Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 14 May 2000 23:15:01 -0400

Folks,

Best Regards,
Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 May 2000 23:18:36 -0400

This issue has come up a few times now, and we have had various H.323
experts come forward to provide input. Regarding RAS, we heard from a
few people that there was no need to handle RAS differently. My
understanding, which is admittedly limited, is that most RAS messages
weren't even sent between zones.

Also, regarding your comments on Annex G, the point of TRIP is to figure
out where to route protocol messages when they arrive at a proxy or
gatekeeper. It is not true that TRIP only works when you try to connect
directly to a gateway. The whole point of the protocol is that you pass
through aggregation devices.  I was not aware that gatekeepers and
border elements did not need to speak H.225.0. But, in these cases, why
would they care about routing, since they won't receive call signaling?

Can you give a concrete example where we need to advertise different
routes for H.225.0, RAS, and/or Annex G?

Thanks,
Jonathan R.

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 18 May 2000 20:11:06 -0400

Jonathan,

Sorry for the late response.  I'm in Japan this week on business and have
had limited access to my e-mail.

When building scalable networks, elements on the edge may not desire to take
part in call signaling.  Many people have the view that a routing Gatekeeper
is not appropriate for the edge of the network.  However, that Gatekeeper
(and/or Border Element) may be perfectly suitable for accepting LRQ or
AccessRequest messages.  Those devices, in that case, would return the
address of either a Gateway, Gatekeeper, or other entity that can handle the
call.

However, as TRIP is currently defined, it forces the H.323 entity that is
acting as the aggregation point to route call signaling.  This is very
expensive, in comparison to merely handling RAS or Annex G messages for the
purposes of routing the caller.  In addition, since an H.323 call may
require 2 sockets, a total of 4 sockets may be required by the aggregation
point to route a single call.  While the socket issue can resolved in
various ways, the aggregation point is unnecessarily forced to maintain call
state and to route calls to completion.

If the aggregation point were allowed to advertise RAS or H.225.0 Annex G as
a protocol, the aggregation point (being a GK or a Border Element) could
provide addressing data to the caller without being forced to route the call
signaling.  This has obvious advantages with respect to scalability and
flexibility within H.323 networks.

Best Regards
Paul E. Jones
Editor, H.323

---

From: "Hussein F. Salama" <[email-masked]>
Date: Fri, 19 May 2000 01:04:09 -0700

> flexibility within H.323 networks.

I agree with Paul. There is no reason to restrict the next hop
application protocol to be a signaling protocol, SIP or Q.931. With RAS
and Annex G as next hop application protocols, the scalability of H.323
aggregation points will be enhanced significantly. The only effect on
call routing is that the route look up operation becomes recursive.
First the Local TRIP LS is queried for the next hop domain, then the
Annex G Border Element, or the RAS Gatekeeper, of the next hop domain is
queried for the appropriate signaling server in that domain. Recursive
lookups are not uncommon in IP routing and I don't see why we shouldn't
allow them in call routing.

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: Fri, 19 May 2000 17:13:36 -0400

> address of either a Gateway, Gatekeeper, or other entity that can handle the

So if I understand correctly, what you want is a way to route LRQ
messages, just as you would route signaling messages, so that the LRQ
travels to the gatekeeper closest to the detination gateway, and that
the response to the LRQ contains the address of the gateway, and then
the originating gateway does Q.931 signaling directly to the remote
gateway?

Or, is it LRQ between terminal/GW and the gatekeeper, and then an Annex
G equivalent query between gateekeepers?

-Jonathan R.

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 22 May 2000 00:12:46 -0400

Jonathan,

Again, I have to apologize for the delayed response.  I'm finding it very
hard to keep up with e-mail while traveling in Asia.

What I was suggesting is along the lines of your first question.  It is
desirable in H.323 networks not to force the aggregation point to perform
call routing.  It may be that it can resolve addresses, but it may not wish
to take part in any routing of the call.  The goal is to allow the
aggregation points or other entities within the network to respond to
changing traffic conditions quickly.  The aggregation point or other entity
could then perform load balancing more precisely, re-route traffic when a
device failure occurs, etc.

Routing call signaling at the aggregation points is obviously one way to
handle these issues, but such routing is not desirable in many
circumstances.  The better solution for H.323 in many cases would be to
allow the aggregation point to dynamically resolve the address without
actually performing any call signaling.  For this, we need to add LRQ and
Annex G/H.225.0 support to TRIP.

Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 May 2000 17:02:53 -0400

> Annex G/H.225.0 support to TRIP.

OK. Is there a need for one codepoint for H.225.0, and another for Annex
G + RAS? Or do we need three, one for each?

Are there any issues with consistency of the databases between the
H.225.0 and the AnnexG/RAS routing tables? I understand your desire to
separate the two, but the fundamental routing tables used in the
underlying system should be the same. Its just an issue of accessing
them. However, using a separate protocol identifier will make it
possible for the two databases to be different.

-Jonathan R.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 26 May 2000 03:15:28 -0400

Jonathan,

> possible for the two databases to be different.

We would have to have a codepoint for each protocol: H.225.0 RAS and H.225.0
Annex G.  They are different protocols and an indicator would necessarily
have to be supplied to allow the calling or resolving entity to know how to
access the remote server.  Also, it is entirely possible that a network may
have support for one protocol, but not the other.  Moreover, consistency is
not an issue.  In most cases (or at least I would recommend that) a network
will adopt one or other of the two protocols for address resolution to
external entities and would have little or no support for the other
protocol.  Data consistency is an issue, of course, but that should be left
to the service provider and equipment manufacturer.  We just want to supply
the necessary tools.

Best Regards,
Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 28 May 2000 02:05:40 -0400

So - here is peoples last chance to object (as they have during the
meetings). Unless I hear otherwise, we will add codepoints to TRIP for
H.225.0 signaling, RAS, and Annex G.

-Jonathan R.