ietf-openproxy
[Top] [All Lists]

RE: Direct Communication between Client and Callout Server (comme nt on opes-spcs-01)

2002-04-11 21:28:59


-----Original Message-----
From: Eric Burger [mailto:eburger(_at_)snowshore(_dot_)com]
Sent: Wednesday, April 10, 2002 9:56 AM
To: IETF OPES
Subject: Direct Communication between Client and Callout 
Server (comment
on opes-spcs-01)



The OPES Engine redirecting the client to a call-out server is 
more than an
artifact, it is a requirement.

For real-time or high-density, low-latency, real-time 
transcoding services
(e.g., transcoding a http chunked fetch of an mp3 to RTP 
delivery of GSM),
it is incredibly inefficient and unrealistic to route all 
packets through
the OPES Engine.

yes, you are right. There was some discussion on this list some weeks ago
about the reasons for using a callout server. WE found out that scalability,
flexibility and segmentation covered up pretty much all the reasons.


One model for this sort of interaction is the IMAP CHANNEL 
mechanism.  See
draft-nerenberg-imap-channel-01.txt .

The "connection" is already in Figure 1, the UPIF flow.  
However, UPIF is
for something entirely different.  I would propose a dotted connection
between the User Agent and the other Call-out server, with 
text along the
following lines:

"The OPES Engine may redirect the User Agent to retrieve 
content directly
from a call-out server.  It can do this to satisfy requests 
which are more
efficiently delivered via a direct connection.  [we can insert 
the example I
gave above]"

I will add your suggestion.




P.S., should "User Agent" be "OPES Client"?


<Prev in Thread] Current Thread [Next in Thread>
  • RE: Direct Communication between Client and Callout Server (comme nt on opes-spcs-01), Reinaldo Penno <=