Subject: [SIP] Static Images

From: "Adam B. Roach" <[email-masked]>
Date: Thu, 15 Jun 2000 11:16:09 -0500 (CDT)

I'm trying to get a feeling for what most people think the most
appropriate way of sending static pictures (generally, at a frame
rate too slow to constitute animation, and definitely not at a
fixed frequency) in the course of a SIP session.

For a frame of reference, some of you may have seen consumer phones
that use some extrodinarily slow and proprietary transfer protocol
to send greyscale images during the course of a phone conversation.
("I've got a picture of Annie right here. She's just started walking.
I'll send it to you" sort of applications).

As I see it, there are a few options for doing this sort of thing:

1) In the signalling path: use a SIP INFO (or similar) message with a
   type image/jpeg body. Since SIP isn't really meant as a transport
   protocol, this doesn't necessarily seem appropriate.

2) As a new, variable frame-rate video codec with packet-loss
   correction (without multiple frames per image, packet loss
   can be a serious issue).

3) By using an existing video codec, but just sending the same frame
   over and over (until a new picture is sent). This is, of course,
   a bit heavyweight for what should be a simple application.

4) As a short-lived TCP "stream" set up with a re-INVITE message;
   this would require an additional transport type to be defined 
   for SDP, but could easily look something like:

   INVITE sip:[email-masked] SIP/2.0
   To: "Mom and Dad" <sip:[email-masked]>;tag=abcde
   From: "John Smith" <sip:[email-masked]>;tag=99999
   Contact: <sip:138.85.60.124:5060>
   Call-ID: [email-masked]
   CSeq: 9986 INVITE
   Accept: application/sdp
   Content-Type: application/sdp
   Content-Length: 119

   v=0
   o=jsmith 95659121152363266 0 IN IP4 138.85.60.124
   s=-
   p=+1 214 555 1212
   c=IN IP4 138.85.60.124
   t=0 0
   m=audio 5000 RTP/AVP 0
   m=image 5098 tcp jpeg
   a=sendonly

5) As a special function of a whiteboard program. I consider this
   punting, as it wouldn't work very well for the embeded type
   phones I mention in the introduction to this mail.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Colin Perkins <[email-masked]>
Date: Thu, 15 Jun 2000 17:27:00 +0100

>fixed frequency) in the course of a SIP session.
...
>As I see it, there are a few options for doing this sort of thing:
...
>   o=jsmith 95659121152363266 0 IN IP4 138.85.60.124

Is it too disgusting to use...

	v=0
	m=image 80 http jpeg
	a=sendonly

to indicate fetchming image/jpeg using http? Weird, but fits existing usage
of the m= line...

Colin

---

From: Billy Biggs <[email-masked]>
Date: Thu, 15 Jun 2000 13:00:09 -0400

Colin Perkins ([email-masked]):

> >   [...]
>       [...]

  I agree that it is definitely a session description issue and not a SIP
issue.

  You need to define a protocol for the exchange of a slow stream of
images.  One method is to use http.  Then you need to describe it in the
description protocol.

  It really is a new protocol, since you want to be able to indicate when
the next image is available, if at all, etc...  Definitely do-able.  This
is one of the applications I was working on last summer when I was
investigating alternate description protocols.

-- 
Billy Biggs                         [email-masked]
http://www.div8.net/billy       [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 15 Jun 2000 13:04:48 -0400

Why couldn't an RTP-over-TCP stream be used here? Telling the client to
go fetch it seems strange, particularly since it also requires that you
somehow upload the image to another server or run a web server on your
PC/phone.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Colin Perkins <[email-masked]>
Date: Thu, 15 Jun 2000 23:38:45 +0100

>somehow upload the image to another server or run a web server on your

Yeah, that's probably a better solution for the audio with accompanying
video snapshot scenario...

We probably have to think about how to include downloadable content for
other scenarios, but I guess that's something for the SDP++ folks to worry
about, not a SIP problem.

Colin

---

From: "Adam B. Roach" <[email-masked]>
Date: Fri, 16 Jun 2000 02:32:26 -0500 (CDT)

>somehow upload the image to another server or run a web server on your

If you're using TCP, I don't quite see what RTP gains you. I agree
with Sean that HTTP may be a bit heavy.

Anyway, I offered 5 scenarios, and everyone seems to have latched onto
one. If I don't hear otherwise, I'll assume that the method of
doing something special in the SDP to indicate a TCP connection of
some sort (possibly with some protocol on top of it, like RTP or HTTP)
is the preferred choice, and take this discussion to MMUSIC.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Jun 2000 02:02:14 -0400

> is the preferred choice, and take this discussion to MMUSIC.

I think it depends on what the purpose is.

If you want to include an image to be displayed before the call is even
accepted (like a jpeg snapshot for new caller ID), I believe this to be
very much a SIP thing, not SDP. You can think of it as a really long
"subject" header - information for the purposes of determining what to
do with the call. We have discussed these things on the list as well,
and debated including the content in sip vs. indirection via a URL, and
also whether it goes in a body or a header. There was no conclusion to
this debate; it would be nice to finish it.

If you want to do some kind of slow motion video after the call is set
up, I'm unsure why this is anything different from very traditional
video over RTP (UDP even). Why TCP? Sounds like you want a motion JPEG
codec.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 18 Jun 2000 11:09:06 -0400

> this debate; it would be nice to finish it.

There is one additional argument (not sure whether this was made last
time around...) for a URI header: body parts are very difficult to add
by proxies, but it might be nice to allow a proxy to go into (say) an
LDAP database or private photo collection and add this information. 

> video over RTP (UDP even). Why TCP? Sounds like you want a motion JPEG
The only reason to use TCP here is that since delay isn't that important
in this image transfer application, one might as well get the benefit of
reliability. The only reason to use RTP rather than just "raw bits" is
that you might want the encapsulation (e.g., for JPEG or H.261 frames)
and might want to re-use existing fast-motion code [I don't see these as
particularly compelling arguments]. As a side remark, one should
probably weigh the advantage of having a separate mechanism vs. only
using RTP/UDP in very low frame-rate mode. The latter gives you this
frame-on-demand or one-frame-a-minute pretty much for free, without
having to wait to upgrade everyone.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 18 Jun 2000 23:14:50 -0400

> LDAP database or private photo collection and add this information.

This point was made last time around. We had several candidate ways to
include data by reference:

1. a body type of application/uri-list
2. a new header, URI, as you suggest

for content included directly, there is clearly only one way, in the
body with multipart MIME.

I initially supported (1) for indirect references to content. This was
because it would be nice to have the same basic encapsulation
independent of whether the body is indirectly references or actually
included. However, you are correct that practically speaking, this makes
it very hard for manipulation by proxies and application servers. As you
point out, adding something like a URL to a prestored picture of the
caller, after doing proxy-authentication to verify the identity of the
caller, would be a nice feature, and much harder if the proxy has to
much with bodies. Related to that, APIs like CGI and servlets don't play
that well with multipart, which then becomes mandatory for such
services.

So, I am basically saying that I have pretty much (although not 100%
sure yet) changed my mind on this, and would prefer a header like URI:
or something, as Henning proposes. Other comments?

> having to wait to upgrade everyone.

I really don't see the need for having a completely separate way to
support streaming media that is high latency, as opposed to low. If you
want TCP, how about:

m=video 21375 RTP/AVPT 31

where AVPT refers to a TCP encapsulating profile of RTP. 

You can then use a pitifully slow motion JPEG, and reuse the RTP
encapsulations, code, codecs, etc.

-Jonathan R.

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 19 Jun 2000 14:31:22 -0500

What is the URL for the I-D on SIP and SCTP?

Sorry for the trouble, Henry

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Jun 2000 11:41:23 -0400

I have written a preliminary draft on the subject, which I hope to send
in shortly (next few days or so).

-Jonathan R.