Subject: RE: [SIP] Static Images

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Sun, 18 Jun 2000 20:43:40 -0700

This discussion is not only limited to images but also the transferring of
executable objects, scripts and just about any other non-streaming entity in
a SIP session. I can foresee that some objects (perhaps call preference
scripts or display objects) may be desired during call setup (as Jonathan
mentioned) and others form part of the session content. 

For transferring content during call setup:
Inline content has undesirable size limitations and deleterious effects on
call-setup time. For referenced content: using HTTP to _fetch_ the content
during call setup seems the way to go as no two-way session information
needs to be exchanged (which defeats the purpose of SIP).
The question is should the URL be in a MIME body or SIP header ? MIME seems
the most flexible but also required multipart support in all proxies. Do we
need both ?

The same problem exists for file-based session content: If MIME multipart
support is not mandatory on all proxies then we need to look at SDP.
Transferring objects in SDP is somewhat limited unless we come up with a=
extensions as someone suggested (from PINT). Otherwise, let's consider the
case where each object transferred is separate and so requires a different
SDP m= line (although not all at once). Now you cannot reuse PT values
within the same SIP call (correct?) and so you are limited to 120 or so
object transfers (if you use the static RTP payload range as well). Of
course what we really need is SDPng but until then I think its is worthwhile
in stretching the current SDP a= usage to perform object based transfer -
this is a potentially huge application area of a SIP session. 

.... Just my thoughts.

Robert.

-----Original Message-----
From:	Jonathan Rosenberg [mailto:[email-masked]]
Sent:	Saturday, June 17, 2000 2:02 PM
To:	Adam B. Roach
Cc:	Henning Schulzrinne; Billy Biggs; Colin Perkins;
[email-masked]
Subject:	Re: [SIP] Static Images

"Adam B. Roach" wrote:
> 
> Henning Schulzrinne writes:
> >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.
> 
> 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.

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

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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Jun 2000 16:15:29 -0400

The problem with having proxies add body parts is (a) complexity, (b)
that now all clients have to understand multipart, even if they have no
interest in the information (I would guess that most current SIP clients
don't understand multipart) and (c) that it doesn't work with signed
requests. Headers containing a reference (http:, say) avoid these
problems. The only drawback is that such references require http support
in clients (which may be an issue for a very light-weight clients, but
most of these are probably graphically challenged anyway) and requires
that the information is available on a publically accessible web page. I
suspect that most corporate users would have difficult uploading their
likeness or other images to a web page, and not everyone wants to have
their likeness framed by an advertisement from geocity or kin. These
are, more or less, the arguments that were made the last time this topic
came around, I believe.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Jun 2000 03:58:22 -0400

So, in the interests of coming to consensus, let me propose that:

1. inline content MAY be included, possibly using multipart. This would
obviously include MIME types like application/URI-list which are
themselves indirect references
2. we define a new header, called URI or something, which contains
indirect references to content that is to be displayed. The header is
totally optional to process at UAS. It cannot be used for content that
is critical for processing the request properly.

We also RECOMMEND that proxies use the URI header when inserting
content. A UA inserting content can use either, but indirect references
are RECOMMENDED for content over 500 bytes (or some other number). In
this way, if a UAC sends content inline using multipart, and the UAS
doesn't support it, the 415 response will indicate that multipart isn't
supported. The UAC can then resubmit the request using the URI header. 

This keeps things open and flexible, but makes concrete recommendations
to guide implementors (i.e, supporting the URI header would be your
first choice).

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 23 Jun 2000 09:41:35 -0400

This sounds find (I'll incorporate it), but I do wonder if one wouldn't
want to be more specific in the purpose of the header, rather than just
"URI". For the 'visual caller id', something like '*-Info' (with a
suitable value of *, TBD) seems more evocative. I don't want to follow
the INFO tradition of dumping everything into one header. This may be
relevant, for example, as to whether the UA uses this information to
update some kind of address book.

---

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

>themselves indirect references

I agree with your goal, but my originally posed question
seems a bit unanswered still. If you'll remember, the goal
was to send arbitrary-sized still images (or a single
image) after a conversation has been set up. This can be
generalised into the problem of sending arbitrary data
during the course of a conversation, where the data
has no realtime characteristics. I prefer this problem
description, since it avoids being mired down with
the realtime stuff like low bitrate codecs (which I don't
think address my problem; they all aim towards error
concealment instead of error correction).

If I read the ongoing conversation so far, the consensus
would seem to point to a solution of sending an INFO
midcall (or possibly a re-INVITE, to keep the number of
required extensions somewhat lower); this INFO or INVITE
would contain a new header (Display-Info has been proposed)
with a URL. Since the image in this case is expected to
originate from the terminal sending the INFO or INVITE,
it would be an HTTP URL pointing to itself, with some sort
of identifier to tie back to the call or resource 
(implementation dependant, but chosen to be the call ID in
this example).

INVITE sip:[email-masked] SIP/2.0
From: Adam Roach <sip:[email-masked]>;tag=99999
To: Bob Example <sip:[email-masked]>;tag=44444
Call-ID: [email-masked]
Display-Info: http://b04a24.exu.ericsson.se/12345

Bob's terminal would then contact mine using HTTP to get the
picture:

GET /12345 HTTP/1.0
Accept: image/jpeg, image/png, video/mpeg, audio/ulaw

So, the terminals would need a minimal HTTP implementation
for this purpose. I have no problem with this; I just wanted
to make sure that, given this information, the consensus
remains the same.

Finally, I pose a quick straw poll: INFO or INVITE? INFO 
requires much less processing (since it can't change 
callstate), while INVITE will already be implemented on 
all clients. (Consider: what does your implementation
do if it gets a re-INVITE with no SDP present? With unchanged
SDP? Are you sure everyone else has done the same thing?)

-- 
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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Jun 2000 13:46:11 -0400

> concealment instead of error correction).

The difference is artificial. You can no doubt use RTP over TCP and
obtain reliable, non-real time transport.

> (implementation dependant, but chosen to be the call ID in

The URL need not point to itself, of course.

If you are doing a slide show of your kids, I still think that TCP/RTP
is better. If it is something more aynchronous and "one shot", I see no
fault in using INFO. In fact, INFO already allows this with content in
the body:

> If a server receives an INFO request with a body it understands,
>       but it has no knowledge of INFO associated processing rules for
>       the body, the body MAY be rendered and displayed to the user. The
>       INFO is responded to with a 200 OK.

I would prefer INFO to re-INVITE in this case; re-INVITE is meant to
have some affect on session state. This does not.

> SDP? Are you sure everyone else has done the same thing?)

re-INVITE with no SDP mid-call is probably an error. If you want to add
a stream, you add an m line. If you want to remove one, you set its port
to zero and re-INVITE. Sending no SDP at all is not right. If the SDP is
unchanged, its unchanged. This is a session refresh, as per session
timer.

-Jonathan R.