Subject: IN call models and CPL (Was Re: IPTEL meeting time)

From: "David Gurle"<[email-masked]>
Date: Thu, 26 Nov 1998 22:33:21 -0200

Dear Jonathan,

I recall we discussed the issue of call model during the BOF of IPTel. Let
me try to give a short answer (sorry even more questions) to your first
question:

>So, I have the following questions, to start things off:
>1. For the IN call models document, is it a requirement for the CPL to
>operate that there be an underlying call model, visible to the CPL? If
>so, need it or should it be the BCSM standardized in the IN
>specifications?

First, IMHO I believe that we will need to define a call model in order for
CPL to access "hooks"  in the IP telephony and allow third party call
control.

The second question is which call model? Will it be AIN 0.1 or 0.2 or will
it be IN CS2 or even CS3, how to handle specific call related features in
SIP and H.323 and why should be forget about MGCP call model or any new
standard? Or we will use TAPI 3.0? So I suggest that we:

1/ Try to understand what we want to achieve with CPL? Will it be similar
to the proprietary service creation tools (these are often based on SDL by
the way, since most of the call models in ITU and ETSI standards are being
specified in SDL) available in SCEs but with a standardized XML grammar and
syntax? If yes please consider that it is a very ambitious goal to achieve
consistency between different call models. I would appreciated Igor's wise
advice here. Igor please wake up.

2/ Understand if the market is ready to go in this direction (I recall that
this question was asked already but I failed to an answer)?

3/ As we will talk about call models, we'll find out that we will need
deeper understanding network elements, their interaction, different type of
services, etc...

We may also need to define various functional roles (sorry for using these
terms here ;-))  involved in a CPL processing, define some interfaces to
enable competition.

I just wanted to make sure that I understand where we are going.

Best regards

     David

Jonathan Rosenberg <[email-masked]> on 11/25/98 02:49:32 PM

To:   list iptel <[email-masked]>
cc:    (bcc: David Gurle)
Subject:  IPTEL meeting time

Folks,
I have just received word about the time of our slot at IETF:
> This is to confirm one session for IPTEL as follows:
>
>         Thursday, December 10 at 1530-1730
>                 other groups scheduled at that time: conneg, ipngwg,
newsnmp, manet
>                         sigtran
I had asked not to conflict with sigtran, but scheduling is tight as
always and it couldn't be avoided.
I'll need to submit an agenda soon. The current outlook is:
Agenda for Iptel meeting in Orlando:
1. Agenda Bashing [5 mins, J. Rosenberg]
2. Open Issues in GLP framework [J. Rosenberg]
3. Location of Local Gateways [5 mins,L. Slutsman]
4. PGRP and GLP [R. Davis]
5. CPL Framework Issues [J. Lennox]
6. IN call models and the CPL [J. Voelker]

If you're not here, and would like to speak, please contact me asap.
Some of the above presentations are based on some drafts that have been
submitted recently, in particular the PGRP and IN call models are both
associated with drafts:
http://www.ietf.org/internet-drafts/draft-ietf-iptel-pgrp-framework-00.txt
http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-iptel-in-00.txt
I'd really like to see some discussion on these before the meeting. The
purpose of the meeting is *not* to present drafts in a tutorial fashion,
but rather to discuss issues raised by the draft.
So, I have the following questions, to start things off:
1. For the IN call models document, is it a requirement for the CPL to
operate that there be an underlying call model, visible to the CPL? If
so, need it or should it be the BCSM standardized in the IN
specifications?
2. For PGRP; PGRP is positioned as an intra-domain protocol, which is
not within the scope of our efforts at the moment. However, portions of
it are applicable to inter-domain location, in particular parts of the
initialization and keepalives. What parts are relevant to GLP? Should
PGRP be the starting point for specification of our protocol?
Thanks,
Jonathan R.
--
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen
---------
This message came from the IETF IPTEL Working Group Mailing List.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 28 Nov 1998 12:41:27 -0500

> advice here. Igor please wake up.

I agree that an understanding of what we want to do is critical before
making any decisions. I also agree that a replacement for SCE's is very
ambitious, and IMHO NOT what we are after.

What I do think we are after is a mechanism for allowing END USERS to
create services, not a generic mechanism which can encompass all
features. These services, I think, should be VERY SIMPLE for the CPL v1.
I believe that KISS is the overriding principal here. Making the focus
on services for end users also implies that simplicity, safety, and
restriciton on capabilities is preferred over flexibility and
generality.

Jonathan Lennox's draft outlines some basic services as a first step -
so I ask, are these the right ones? My own personal feeling is that some
of them are too ambitious for the first cut. I'd prefer to focus on
basic services related to call routing, call redirection, and call
screening based on some simple logic, including time of day, caller, and
other message information. 

> this question was asked already but I failed to an answer)?

Not sure which direction you mean - if you mean using CPL as a
replacement for all of the proprietary SCE's, well probably no. If you
mean a syntax for end user expression of preferences, with neat but
limited features, I hope so. In any case, it is not our job to direct
industry directions. There was consensus to form iptel and work on this
item (which is why we are here). I hope that, if we do a good job,
people do begin to implement it, but thats not our job to make it
happen.

> deeper understanding network elements, their interaction, different type of

True; the current draft does just this. Within our smaller scoped
problem, the number of such element is quite small (pretty much just
call servers (aka gatekeepers or SIP servers)). I'd welcome comments on
whats missing/wrong/etc.

> terms here ;-))  involved in a CPL processing, define some interfaces to

Again, I think this is already there in the framework - please clarify
what you feel is missing. Also, let me clarify WE ARE NOT developing a
complete solution for IP telephony service creation. WE ARE NOT defining
all of the interactions between all elements in an IP telephony system
(such as media servers, billing servers, gatekeepers and SIP servers,
gateways, bridges, etc). WE ARE trying to solve a small part of this
problem.

-Jonathan R.

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 30 Nov 1998 14:11:40 -0500 (EST)

> advice here. Igor please wake up.

I agree with Jonathan R. that my list of services in my initial requirements
draft was over-ambitious -- I was essentially tossing in a large number of
useful services so as to inspire thought about the kinds of things a CPL
could do.  If we throw out some of the more elaborate items (such as trying
to implement a whole call-center with the thing) and restrict it to
simple user-defined services, I think the whole thing becomes much more
tractable.

I've never quite understood why we need "call models" per se for the CPL, as
I seem to be able to design fairly plausible-looking service descriptions
without having specified one.  Maybe I'm using one implicitly, but it seems
to me that describing services in terms of what proxies/gatekeepers actually
*do* with signalling information is more directly understandable than a
high-level abstract description of calls which ignores the distributed
nature of the system.
 
> terms here ;-))  involved in a CPL processing, define some interfaces to

For those of us who are coming at this more from the Internet side, can you
explain what "functional roles" actually means?
 
> I just wanted to make sure that I understand where we are going.

Well, that's what we're trying to figure out.  The more discussion, the
better.

-- 
Jonathan Lennox
[email-masked]
---------