Subject: PSTN and SIP (or its replacement/adjunct)

From: Ken Carlberg <[email-masked]>
Date: Wed, 24 Nov 1999 08:24:38 -0500

> From: "Gregory D. Girard" <[email-masked]>
>
> SIP (Or
> its replacement/adjunct) must cover the basics before any fancy stuff even
> matters a damn to anyone anywhere.

Absolutely agreed.  A number of my customers/clients are U.S. government 
agencies (DoD and non-DoD), of which several are populated with  die-hard 
bellheads.  If its not possible to present an IP-based solution that works 
seamlessly with the existing PSTN baseline set of functions, then these 
folks will ignore SIP (or its adjunct).  I have an added desire to have 
High Probability of Completion (HPC) incorporated in the baseline set, but
first things first.

If a particular vendor doesn't want to support the baseline, fine.  In my
role as a systems integrator, I'll be happy to select another vendor that
does.

cheers,

-ken

---

From: Michael Thomas <[email-masked]>
Date: Wed, 24 Nov 1999 07:51:42 -0800 (PST)

Ken Carlberg writes:
 > seamlessly with the existing PSTN baseline set of functions, 

"The set" or "a set"?

I don't think anybody disagrees with the general
proposition that there exists a general set of
features which are useful, produce revenue, etc,
etc, which must be accommodated. The question is
whether every feature is on an equal footing and
no progress can be made until the ocean is boiled.

By way of analogy, with the transition from horses
to cars, it's certainly true that cars needed to
accommodate quite a few of the good features of
horses: the ability to make them go, the ability
to stop them, the ability to steer them, etc. That
did not place a requirement on car designers to
emulate *every* feature of horses: cars don't
need to eat hay, poop roadapples, or install nerve
endings in the bumper so that buggy whips work.
For those who insist on these features, there
will always be horses.

The raison d'etre for cars was to keep the good
features of the old technology, but vastly expand
on the possibilities which were not possible with
the old (like going 160Mph, etc). The same thing is
going on here: there are certainly a lot of very
worthwhile features of the old technology which
need to be preserved. That does not mean that we
should exactly emulate it; like the horse, if you
really want something that eats and poops hay and
feels the sting of a buggy whip, you might as well
get a horse since it is, after all, the real
thing. 

Like the car, however, functionality enabled by
the new technology will become far more important
than a procrustean emulatation of the old. What's
interesting here, as with any techology at a
transition point, is that we're not really certain
what the new world really looks like. All we
really know is that beyond accommodating some
obvious must have features, the future is
uncertain but the way forward is clear.

		    Mike

---

From: Ken Carlberg <[email-masked]>
Date: Wed, 24 Nov 1999 11:31:42 -0500

> "The set" or "a set"?

a set (though i would imagine that we're involved with most federal,
agencies one way or another -- i don't really keep count because i'm
only interested in the technical stuff).  check with your business 
manager in charge of the federal market concerning SAIC.

> emulate *every* feature of horses:

poor analogy.  my original note did not state the need to support *every*
feature, nor did it imply so.  the item i agreed with is a necessity 
to transparantly support a baseline set (ie, one has to support the
installed base).  if Jonathan feels that is being done with SIP as it 
stands today, fine.  however, in looking at the recent thread, that did 
not seem to be the case.

having said our peace, lets take this offline if you wish to continue.

-ken

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Nov 1999 15:12:02 -0500

> stands today, fine.  however, in looking at the recent thread, that did

This thread has been full of high level handwaving, without a lot of
real technical discussion. Lets look at some services that *can* be done
with SIP that are in the PSTN:

call forwarding
call transfer (call control spec)
caller ID
call hold
multiparty conferencing (call control spec)
*69
follow-me
find-me
call waiting 
IVR systems

there are others, but these are some of the most critical and commonly
used ones. That probably covers a very large percentage of what most
people do.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 24 Nov 1999 15:20:15 -0500

Jonathan Rosenberg wrote:

> used ones. That probably covers a very large percentage of what most

Just to add a few (see the new SIP FAQ item...):

call waiting (clearly done differently in VoIP)
call queueing
automatic call distribution
call park (with some details to be worked out)

A more complete list is in the tech report on 5ESS feature
implementation available on the SIP web site.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 28 Nov 1999 22:22:21 -0500

Jonathan,

I'm not convinced that all of these can be achieved with SIP as it stands.

Consider call hold.  I read a draft that suggested that a SIP device would
send an INVITE with a special "c=" SDP line (and the 200 and ACK are
exchanged) and media stops flowing.  That's all there is to "call hold".

I point out two problems with that approach:
1) It's a "hack" on the current spec.  I have no problem with that approach
if that's the agreed direction, but are we going to make all features
"hacks"?
2) What happens if I turn off my SIP device, unplug it, or otherwise-- how
does the party on hold know that I am gone?

I'm not sure how some of the other features are going to be implemented.
They're not specified in the SIP document proper.

Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 29 Nov 1999 03:10:13 -0500

> if that's the agreed direction, but are we going to make all features

That is the solution. The spec says so:

B.5 Putting Media Streams on Hold

   If a party in a call wants to put the other party "on hold", i.e.,
   request that it temporarily stops sending one or more media streams,
   a party re-invites the other by sending an INVITE request with a
   modified session description. The session description is the same as
   in the original invitation (or response), but the "c" destination
   addresses for the media streams to be put on hold are set to zero
   (0.0.0.0).

The motivation for this "hack" is thats its a freebie... a UAS receiving
a request without an Ip address in the SDP cannot send media anyway. It
also allows us to hold individual streams, which is why its not done in
SIP itself. 

> does the party on hold know that I am gone?

There is a draft on session timer:
http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-00.txt

which addresses this. Its going to be a SIP extension.

-Jonathan R.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 29 Nov 1999 12:04:22 +0200

Hi,

> multiparty conferencing (call control spec)

Just a small comment. In the States I think that *69 means "re-call"
service, but in Europe does not mean anything.

I can write "112 service" and nobody in the States will understand (it
means emergency call in Europe).

Let's try do use terms understandable on both sides of the pool :o)

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  [email-masked]
Finland

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 29 Nov 1999 19:52:17 -0500

Jonathan,

I stand corrected about this "hack"-- thanks for pointing that out to me.
I'm not sure how I missed it!

Best Regards,
Paul

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>
Cc: "Ken Carlberg" <[email-masked]>; "Michael Thomas"
<[email-masked]>; <[email-masked]>
Sent: Monday, November 29, 1999 3:10 AM
Subject: Re: PSTN and SIP (or its replacement/adjunct)