Subject: Re: [SIP] Static Images

From: Sean Olson <[email-masked]>
Date: Thu, 15 Jun 2000 17:29:15 -0500 (CDT)

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

That is of course assuming that you don't support HTTP over port 5060 :)
If you can build SIP, why not HTTP as well? (I'm being sarcastic of course.
HTTP 1.1 is not to be underestimated)

--
Sean Olson <[email-masked]>

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

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 15 Jun 2000 20:52:55 -0700

Do you think that will require a new SDP profile (like RTP/AVP) or does an
adequate "tcp" SDP profile already exist ?

If this is a multiparty SIP conference you've got the problem of reliable
multicast transport and so simple tcp may not cut it (there are other
multicast transport protocols which address this problem). 

Cheers,

Robert.

---

From: Sean Olson <[email-masked]>
Date: Mon, 26 Jun 2000 08:24:12 -0500 (CDT)

> "Fairlie-Cuninghame, Robert" wrote:
> > 
> > Perhaps this Display-Info field could also be used to describe inline
> > content. This means that all information regarding optional content is in
> > the same place.
> > 
> > Display-Info:
> > http://www.example.com/picture;purpose=picture,inline:2;purpose=aboutme
> > 
> > where inline:2 means that the content is contained in the second multipart
> > body. [Although this would place a requirement on proxies adding multipart
> > bodies to place them at the end.]
> > 
> > Do you think that a mime type parameter is required (especially for URL's)?
> > eg
> > Display-Info: http://www.example.com/picture;purpose=picture;type=image/tiff
> 

This is not a road we want to go down. Especially with deeply nested
multipart bodies. 

sean

---

From: Sean Olson <[email-masked]>
Date: Thu, 29 Jun 2000 11:57:33 -0500 (CDT)

> Adam,
> 
> The "sprog" behavior reminds me of push advertising content.  I am 
> incredibly alarmed at the idea of displaying "sprog", or playing "sprog", 
> or continually prompting me if I want to see "sprog".  It's bad enough when 
> I surf with cookie protection turned on.  IMO, This non-semantically 
> defined rendering is more appropriate for Instant Messaging.
> 
> Now if you really want your UA to always display whatever content your peer 
> barfs down to you, then I suggest we use headers, but create a convention 
> that all the header names end with -Info.  Then, when you get the headers:
> 
> Sprog-Info: http://www.spam.com/annoying-animated.gif
> Sprog-Info: http://www.spam.com/annoying.wav
> 
> Your UA can match against unknown *-Info headers and a) happily render 
> them, b) prompt for them, or c) ignore them.

It can quite easily do the same when matching unknown "purpose=" parameters
on a Display-Info: header. This is just a syntactical difference, not a
semantic one. You might argue that it can be more efficient to filter based
on the header name. You can also argue that it's easier to just look for
all the Display-Info: headers and not have to worry about possible namespace
collisions if someone adds a SIP extension header that uses a *-Info header.
Both approaches have problems. 

There seems to be some confusion here about what you are trying to convey
either with a header or with a parameter on that header. There seem
to be three pieces of information that are needed and only two are being
addressed.

1) A URL identifying some resource potentially to be accessed
2) The purpose of that resource
3) The mechanism for presenting that resource

What I would propose then is a compromise:

Use the header name to indicate the purpose of the resource as in:

Alerting-Info:  special ring or display
From-Info:      CallerID photos, .vcfs, spoken names, etc.
Error-Info:     Dave's pointer to error messages
Context-Info:   stuff relevant to the call (presentation, web page, photo, 
etc.)

Use a "disposition=" parameter to indicate the mechanism for presenting that
resource.

For example, a caller ID image that is meant to be rendered in parallel
with call setup would be

From-Info: http://www.cow.com/~bob/id.jpg ; disposition=inline 

sean