Subject: Re: SIP

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Jan 1999 20:09:59 -0500

Paul E. Jones wrote:
> 
> Henning Schulzrinne wrote:
> >SIP does not control network resource usage; that's the role of RSVP,
> >diff-serv, etc. Indeed, it likely avoids the signaling overload problem
> >encountered by traditional PSTN services as it may bypass all but the
> >final end system. Since SIP can transmit limited out-of-band data, the
> >California earthquake situation would actually handled much more readily
> >by SIP:
> >
> >INVITE [email-masked]
> >From: [email-masked]
> >Subject: I'm fine but all the china is in pieces
> 
> Are there any efforts going on inside the IETF or in other groups to define
> a complete IP telephony solution using SIP?  That is, are there any
> documents in existence or under construction that provide guidance to
> implementers or service providers that address bandwidth issues, user
> location, security, roaming, etc.  Is anyone addressing the issues of lawful
> interception or access to emergency services in the SIP environment?

Some of these issues are being addressed; SIP itself addresses security,
relying in part on existing mechanisms, such as TLS or IPSEC. User
location is one of the features of SIP; work is going on in the enum
group (not yet a working group) around doing it for telephone numbers. I
know of efforts regarding roaming services and emergency services (a
REALLY hard problem in an Internet context), but nothing at the
standards level.

However, there is currently no IETF effort to specify a "complete
solution" for IP telephony. In general, this is not something IETF does.
It is good at making nice, general purpose, modular protocols, and the
job of putting it all together for a complete solution is something that
the service providers and vendors do, as there is more than one right
way, and it leaves room for growth and value add. 

Seems to have worked so far; there are many applications on the net
which involve a mix of protocols. THe web is certainly one example - it
relies on http, of course, but also on back end directory services for
dynamic content, HTML, Java, Javascript, HTTP-CGI, cache replication
protocols, and lots of media types and plugins. There is no one spec
which tells vendors what to implement in their servers.

> 
> In order to deploy a global IP telephony solution based on SIP and related
> technologies, we must have a standard that addresses the "loose ends" that
> the protocols by themselves do not.

I'm not yet convinced that we "MUST" have such a standard. I agree there
must be solutions to the various component problems, but not all in one,
birthday wrapped solution. Grandiose, all encompassing solutions have a
bad habit of never making it.

-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

---

From: Douglas Clowes <[email-masked]>
Date: Fri, 22 Jan 1999 13:57:30 +1100

>way, and it leaves room for growth and value add. 

And there are any number of almost, but not quite, entirely
non-interoperable implementations. While there is more than one way that
might be right, there are far more that are not right.
Product-differentiation, market-fragmentation, or customer-lockin: call it
what you will.

>which tells vendors what to implement in their servers.

And there are so many ways that these things can and do break. With the
latest browser version available, I still got a site that told me my
browser was too old and I should get an update before I come back. It breaks.

>bad habit of never making it.

The solution seems to be the "Implementation Agreement" where, instead of
the standards body picking and choosing, a group of vendors, implementors,
or customers (or all three) get together and make the choices. Sometimes
each group gets together separately and we get three or more IAs.

IMTC has an IA on VoIP telephony. ETSI TIPHON is a selection and tightening
of the standards. There's also iNOW! and TIPIA. And some others that escape
me ...

>From the box builder's POV, he wants to build boxes with any damn standard
he want to, and update to the latest protocols to remain "whiz bang". From
the box buyers POV, he wnats to buy boxes from different vendors and have
them work in his existing installation. He doesn't want to find that of the
two new boxes he bought, one uses RADIUS while the other one, with the
higher serial number uses DIAMETER and that neither works with the same
models he bought last year from the same vendor that use TACACS+.

Some people want to sell boxes. Some people want to buy systems.

Douglas

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

---

From: Ping Pan <[email-masked]>
Date: Thu, 21 Jan 1999 22:42:26 -0500

> models he bought last year from the same vendor that use TACACS+.

Sure. That's why some of us (from multiple vendors) are working hard
toward a single standard protocol that can provide accounting,
authentication and admission control for many emerging internet
applications (IP telephony included). Actually, some of us are not
interested in "whiz bang", rather the market itself.
 
> Some people want to sell boxes. Some people want to buy systems.

Yep, we want to sell the boxes now so that the customers can get into
the service games as soon as possible. As the protocol and development
evolving, the sellers can always send software versions to keep the
customers up to date.

> Douglas

Regards,

--
Ping Pan    phone: (732)-332-6744   fax: (732)-834-5379

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 22 Jan 1999 08:35:05 -0500

Douglas Clowes wrote:

> Product-differentiation, market-fragmentation, or customer-lockin: call it

There may well be value in agreements beyond protocol specs. However,
there's often the suspicion that many of these industry bodies are
clean-up crews for standards that could have been clearer, been based on
more implementation experience or more layered/modular to begin with.
The abundance of these organizations also raises the cost of entry, so
they are probably at best a necessary evil, not a model to strive for.
Note also that the traditional telecom world is hardly a model to
emulate here, if you recall trivial things like the number of different
phone plugs, dialing plans or ringing patterns (see a previous
discussion on rem-conf) in the world or the number of ISUP/TUP/other
signaling variants. At least email and web access from India to the US
works without gateways and translators and interoperability agreements
and I don't have to be certified as compliant in each of those countries
:-)

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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 22 Jan 1999 14:59:36 -0500

> each group gets together separately and we get three or more IAs.

We exchange here e-mail and web pages by using IETF standard protocols. Am
not aware that our applications, whatever they are, went through implementor
agreements and the like.

Henry

---

From: Douglas Clowes <[email-masked]>
Date: Mon, 25 Jan 1999 14:27:50 +1100

Henry,

The number of people that I hear cursing Microsoft, and Netscape too,
because they don't implement each other's features *today* is not small.
Each browser only gets best effect when used with their own server. What
works in a Netscape browser, only when served by a Netscape server (and
v.v.) is an implementation agreement within the vendors browser and server
teams - same for MS.

Often, when I send a message to a mail exploder, I get back one or more
non-delivery notices. Sometimes I get one mail message more than once. I
suspect I get some messages not at all.

On the latest available version of MS Explorer, I loaded a web page last
week that told me my browser was too old. It was wrong. It was broken, just
like the mail system.

I can't send SMTP mail messages when I'm "off-net" because my provider will
not allow it, because it has inadequate security. I can't use NTP/SNTP
through firewalls because people block it. There are no end of ways the
Internet, and IETF protocols, break or are broken.

It really depends on your expectations, and those of your paying customers,
whoever they may be. From consumers who expect to pick up a handset, push a
button and talk to mom, without retarting their handset and redialling
three times. From service providers who want to be able to buy a new box,
and just plug it in, without hiring a consultant to tell them what support
servers they will need and will it be compatible with their existing
infrastructure.

Incidentally, e-mail and web exchanges only occur under two specific
circumstances: either you are lucky that there is a chain of commonality,
or your software has implemented a great number of almost, but not quite
the same protocols. My old POP/UUENCODE mail client has problems with the
IMAP post office, and the MIME attachments. The free mail clients that
support them are brain dead, so one day I'll fork out for a new one. Until
then, I'll plod on and curse these IETF protocols. [The nice thing about
standards is that there are so many of them from which to choose.]

Douglas