Subject: RE: Making SIP HTTP/1.1 Compliant -- RTSP???

From: Yaron Goland <[email-masked]>
Date: Wed, 29 Apr 1998 13:36:13 -0700

I scanned RTSP but unfortunately I don't have the time to provide a detailed
analysis. However reviewing the section on how RTSP differs from HTTP
demonstrates to me that RTSP could be made HTTP compliant with even less
effort than SIP.

To be clear, my interest in SIP has absolutely nothing to do with multimedia
over the Internet or IP telephony. My interest is strictly in the
notification, udp transport, and encryption features that SIP provides. That
is why I won't be investing time in helping RTSP become HTTP compliant.

			Yaron

-----Original Message-----
From: Scott Petrack [mailto:[email-masked]]
Sent: Wednesday, April 29, 1998 6:02 AM
To: Yaron Goland
Cc: [email-masked]
Subject: RE: Making SIP HTTP/1.1 Compliant -- RTSP???

I agree with Yaron. I mean, compare the cost and effort in deploying such
firewall support compared to the cost and
effort in deploying not-quite-HTTP-compliant SIP proxies or (uh) H.323
proxies.

The main problem is getting people to allow UDP through of course, and this
is a real problem, but you can start up Iphone today via an iphone:// URL
(not standard I know) and you're pretty much left with the UDP firewall
problem. Once you configure your browser or whatever to recoginze the
iphone:// URL -- no SDP required. I'm not at all trying to push a product
(though of course if you ask ;-)....) I'm just saying that the fact that
making it truly complaint doesn't solve every single problem doesn't mean
that it doesn't have great value. (I'm at TIPHON, so I'm allowed to write a
sentence with 4 negatives in it).

BTW, Yaronushka, what about RTSP??? How close is that to real live HTTP?

Scott

[email-masked] on 04/28/98 06:13:53 PM

To:   [email-masked]
cc:   [email-masked] (bcc: Scott Petrack)
Subject:  RE: Making SIP HTTP/1.1 Compliant

I think it is plausible that a user who wants to send an invitation with
SIP
may be behind a firewall that doesn't support SIP but may support some type
of v/IP.
Imagine your network already supports vocal tech's or Intel's or someone
else's product but doesn't support SIP yet. No problem, you can still send
the invite via SIP (since it is just HTTP, assuming your admin allows users
to send out arbitrary methods) and then specify the vocal tech product as
the communication medium.
There are also other scenarios where your administrator may support both
SIP
and v/IP but their SIP proxy sucks. After all, SIP never specified how to
actually build up its networks of proxies and hook everything together. It
is like NNTP, people have to set things up by hand. If your administrator
is
lousy he may have done a bad job of it. In that case if you know a better
SIP proxy you may want to be able to skip your administrator's proxy all
together and go to another one. By using an HTTP URL the message will be
delivered to your desired proxy instead of your administrator's proxy.
Choice is a good thing.
          Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, April 28, 1998 8:32 AM
To: Yaron Goland
Cc: [email-masked]
Subject: Re: Making SIP HTTP/1.1 Compliant

>The really cool thing about adopting HTTP URLs for the request-URI is that
>Mike could send the following message:
>
>INVITE http://sipproxy.com/proxy HTTP/1.1
>From: sip://[email-masked]
>To: sip://[email-masked]
>
>Bam! The request goes through his HTTP/1.1 proxy to his SIP proxy at
>http://sipproxy.com/proxy and gets properly handled. Joe gets his invite
and
>everyone wins.
>
>Now, you can't tell me that isn't cool. =)
This is very interesting, but probably not practically useful (at least,
not in the context you have presented it). If a user is behind a firewall
with an HTTP proxy, but his system admins haven't made provisions for a
SIP proxy, it is unlikely that the admins have provided *any* support for
V/IP communications. I may be able to invite [email-masked] through
my HTTP proxy, but frustration ensues when we are completely unable to
set up a voice channel (unless you want us to use a persistant connection
through the proxy for streaming audio -- probably a bad idea).
I do, however, agree with you that it seems unnecessary to reinvent the
wheel. If the work required to add SIP proxy functionality to an HTTP
proxy is minimal, we'll have them deployed faster. We also avoid taking
yet another port from the increasingly crowded <1024 range.
Just my 2 cents worth...
--
Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS
L-04
Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
[email-masked]    |                  <*> | USA

---

From: Christian Huitema <[email-masked]>
Date: Wed, 29 Apr 1998 17:05:21 -0400 (EDT)

Yaron,

If I understand correctly, you would mostly be intersted by an "HyperText 
Datagram Protocol", i.e. something that does HTTP over UDP.  This is
clearly a very good idea.  However, it looks a little bit like "wrong
group, wrong time" to me.

Most of the MMUSIC group's expertize is in the synchronization of
multimedia sessions.   An HTTP over UDP effort, IMHO, should include
some input from the HTTP working groups in the IETF and in the WWW
consortium.

Then, the most prominent problem that this group faces today is delay.
We have to get the damn spec out of the door, or we may as well forget
about it.  I a not sure that a fully fledged HTTP compliance effort
can be completed in an adequate time frame.

I would rather get the spec out, experiment, and maybe propose a revision
in a year.  Better still, if within a year from now we have defined
HT/UDP, then we could seriously consider drastic changes.

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 29 Apr 1998 18:13:29 -0400

> HT/UDP, then we could seriously consider drastic changes.

I couldn't agree more. Lets worry about http compliance for the next
version.

-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: Masataka Ohta <[email-masked]>
Date: Thu, 30 Apr 98 11:03:52 JST

Christian;

> multimedia sessions.

Let's not forget that MMUSIC has two Ms, and the other is for
multiparty. SIP covers multicast.

Though MMUSIC protocols, in general, are no good, the multicast
makes SIP unnecessarily complex for unicast communication, the
combination of multicast and firewall is loop prone, MMUSIC
protocols, in general, do not scale w.r.t. the number of
receivers.... There is no reason to further waste time trying
to make them worse.

> about it.

IMO, The latter is the best thing to do.

> in a year.

Considering that all the shortcoming are derived from the experiment
on a toy Mbone only to make SIP bloat, what is the point of further
experiment?

						Masataka Ohta

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 30 Apr 1998 07:05:46 +0200

> > HT/UDP, then we could seriously consider drastic changes.

Christian is right, let's lock in the progress made so far.
Quite an accomplishment, given its astonishing potential !

Henry

Henry Sinnreich
MCI, 901 International Parkway
Richardson, Texas 75082

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 1 May 98 10:50:04 JST

Henry;

> Quite an accomplishment, given its astonishing potential !

Just consider internet telephoney, first.

There are two ways to evaluate an accomplishment.

One is to favour the thick document and rich features and
astonishing potential of its own.

Here, H.323 is THE accomplishment. If you mind that H.323 consume
too much RTTs, H.323 should be expanded further to have an optional
feature to reduce RTTs. H.323 has its own astonishing potential.

The other is to favour the thin document and slim features
relying on astonishing potential of existing protocols.

Here, any document longer than 20 pages will not considered from
the beginning.

Now, let's consider session management in general.

According to the former way of evaluation, H.323 should be expanded
through its own astonishing potential.

According to the latter way of evaluation, Yoram made a point
that separate functionalities should be separeted as much
as possible.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 1 May 98 17:18:25 JST

> According to the latter way of evaluation, Yoram made a point

Oops, he is Yaron, not Yoram. My apologies.

							Masataka Ohta