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

From: "Scott Petrack"<[email-masked]>
Date: Wed, 29 Apr 1998 15:02:15 +0200

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: Yaron Goland <[email-masked]>
Date: Wed, 29 Apr 1998 20:52:01 -0700

Actually that would be third on my list. First would be notifications, which
is what SIP does. SIP likes to call it "invite" but the end result is the
same. It is the group's experience in that area that is desired.

Next on my list would be the encryption header, which were it broken out
into a separate spec could then be reused by a larger audience than just
SIP.

Last, but not least, comes UDP/Multicast.

As for "just shipping it", I sympathize. But imagine if you will the program
manager trying to convince his management to implement SIP:

"You see, we need to do notifications and there is this SIP protocol and it
does it and we should use it. Oh and um.. well o.k. the protocol is
basically identical to HTTP but not really so we have to roll our own
clients, proxies, and servers. Oh and um.. yeah.. well... you see.. um.. it
doesn't work with the currently deployed infrastructure so administrators
have to manager SIP proxies separately from their already deployed HTTP
proxies and well actually duplicate everything."

If he is lucky they won't laugh.

			Yaron

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: Wednesday, April 29, 1998 2:05 PM
To: Yaron Goland; 'Scott Petrack'
Cc: [email-masked]
Subject: Re: Making SIP HTTP/1.1 Compliant -- RTSP???

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/