Subject: jpegs in INFO messages?

From: "Schroeder, Tim" <[email-masked]>
Date: Mon, 22 Nov 1999 16:26:58 -0600

Dean Willis [mailto:[email-masked]] writes
> I could, for example, see an application wherein each end point
periodically
> snaps a jpeg image of the speaker, mimes it, and ships it via INFO to the
> other end for display as a "speaker icon". The proxies in between don't
> care, they just ship the message along. Yeah, you could do it in RTP. You
> could do it a lot of ways -- but INFO is easy for asynchronous stuff.

Was this a serious suggestion for an application?  It sounds like a crude
implementation of a video-phone service, where the audio is sent via a media
channel, but the video is sent via the signaling network.

The idea of letting end systems (UACs or UASs) send INFO messages on the
signaling network seems to open up quite a potential for abuse.  

For one thing, as your JPEG example shows, the amount of data could be large
-- unbounded actually.  In that case, it seems like some one needs to pay
for those messages.  That opposes the idea (popular in Washington, at least)
that nothing is charged for until a call is "completed". 

Also, it may be that to keep the signaling network "healthy", that end
system signaling (as in an INFO message) might be kept separate from (or
sent with a different class of service than, or whatever) the other more
bounded SIP signaling messages.  This would mean INFO messages might not be
able to flow through the same set of network proxies as the other SIP
signaling messages, or they might arrive with more latency, less
reliability, etc.

Tim Schroeder

This e-mail and any files transmitted with it are the property of SBC,
are confidential, and are intended solely for the use of the individual
or entity to whom this e-mail is addressed. If you are not one of the
named recipient(s) or otherwise have reason to believe that you have
received this message in error, please notify the sender at
[email-masked] and delete this message immediately from your
computer. Any other use, retention, dissemination, forwarding, printing,
or copying of this e-mail is strictly prohibited.

---

From: Dean Willis <[email-masked]>
Date: Mon, 22 Nov 1999 20:42:45 -0600

> > snaps a jpeg image of the speaker, mimes it, and ships it via
. . .
> that nothing is charged for until a call is "completed".

Many people also objected to letting users send large amount of email
without additional charges. Come to think of it, we used to get $1 US per
page of email.

Then the users realized they were buying BANDWIDTH, not email service, and
stopped using our mail servers. That really scuttled the profit boat, you
know? Just think -- my IETF mailing list bill would be like $10,000 a day!
Think they won't route around call control servers if there is an economic
reason to do so?

> signaling messages, or they might arrive with more latency, less

One might wish to design a network and application that minimizes the number
of end-to-end proxies. In fact, I believe the DCS architecture REQUIRES that
there be no proxies remaining in-path by the time of the final 200 OK, so
any INFO messages sent in such a case would be end-to-end.

While I admit that this may be a little extreme, I can certainly predict
that the norm will be for only proxies that really NEED to stay in-path
(like firewalls, anonymizers, proxy-service-nodes, and the like) to do so.
Other proxies will bail out as soon as their task is done.

This makes the signaling path very close to shortest-path between two nodes
in an established session. We already had to hole the firewalls to pass the
SIP traffic, so using INFO for generic asynchronous-but-immediate
application messaging is actually pretty efficient. And if you use
persistent TCP, it's pretty easy on the network too. Not to mention the fact
that one gains the utility of every intervening proxy (like IP address
anonymizing and firewall passage) quite transparently.

If you want your signaling (and JPEGS and IMs and other stuff somebody might
shove in an INFO) transmitted at a higher preference, well, I'll be happy to
arrange to charge for those high-priority packets . . .

--
Dean