Subject: Re: jpegs in INFO messages?

From: "Pete Cordell" <[email-masked]>
Date: Tue, 23 Nov 1999 11:34:11 -0000

Henning,

Although we have an integrated network, I think we should still bear in mind
that control signalling will become more concentrated around proxies and
other service nodes than the media which will be more dispersed across the
entire network.  This makes it attractive to keep the signalling bandwidth
low if possible.

Also, in a managed network, links may be provisioned based on their expected
traffic flow.  Large JPEGs and GIFs flying around the place may make such
traffic estimates impossible, and so affect the economics of deploying such
systems.

I prefer the solution of including a URL which would allow a called party to
access a picture if desired without burdening the call signalling.

Pete

=============================================
Pete Cordell
[email-masked]
=============================================

-----Original Message-----
From: Henning Schulzrinne <[email-masked]>
To: Gregory D. Girard <[email-masked]>
Cc: Sean Olson <[email-masked]>; [email-masked]
<[email-masked]>
Date: 23 November 1999 01:16
Subject: Re: jpegs in INFO messages?

>"Gregory D. Girard" wrote:
>>
>> I would reject any image transfer via SIP on the simple grounds that the
>> message size would adversely affect the transmission timing for SIP
>> messages, particular if time-sentive signaling ( like DTMF digit
sequences
>> if that were in SIP). Thus a big lump of image data would convert SIP
into
>> file transfer protocol. Connections would time-out waiting for images to
>> load. While SIP may not require a real-time transmission medium, anything
>> more than a tiny latency (1/2 second) is bound to be percieved as delay
to
>> the end users in the form of call setup time an in many other ways. H.32x
>> protocols have provisions for image transfer, however they transfer are
>> executed through a logical channel specifically set-up for this purpose
to
>> the extent that it is interwoven with other transmission by other logical
>> channels in a way that does not expand the total bandwidth consumed by
the
>> connection. For example, audio and video are shut off while image data is
>> transferred using that bandwidth.
>>
>> A few bytes of DTMF sequences is one thing, but several kilobytes of
image
>> data hogging the signaling link is over the line for me.
>>
>
>Fortunately, we don't have "signaling links", but an integrated network,
>where the signaling paths are likely to have the same bandwidth as the
>rest of best-effort traffic. Thus, this is only a problem when
>SIP-as-web-page-carrier competes in traffic with http. That'll be a long
>time off (I hope).
>
>While SIP should not be a transport protocol, I see no reason to
>prohibit sending one's likeness as a JPEG or a web page if that makes
>service development easier (subject to MTU considerations). This clearly
>only works if SIP messages are best-effort rather than marked as
>high-priority traffic. The latter would encourage the "SIP for audio"
>bypass.
>
>Somehow this discussion/reaction reminds me of the ISDN UU field (which,
>so I'm told, European PTTs disallowed since they couldn't stomach the
>free bits that they would grant to their customers).
>
>--
>Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Nov 1999 08:06:49 -0500

> entire network.  This makes it attractive to keep the signalling bandwidth

This discussion is kind of theoretical. We don't restrict what protocols
can and cannot be used for. In some environments and for some
applications, this may be an issue, in others it just doesn't matter. 
Do you want to call the protocol police if I send a JPEG image and issue
a weight violation ticket? Users and application writers will figure out
pretty quickly that sending along a QuickTime movie introducing yourself
(with accordion and playing ping-pong) may not be the best way to
guarantee call success and speed. SIP has the status code to refuse
large messages, if needed.

If customers find a need for sending large SIP messages, I'm sure there
will be service providers to accommodate them. ("We allow you to see
who's calling, unlike that other company..."). Somehow, this doesn't
rank high on the list of my concerns, but somehow restricting usage
before we know what interesting services you can build, does.

> access a picture if desired without burdening the call signalling.

Indeed, that would be the preferred approach where feasible. It also
allows caching in the case of "JPEG caller id", but with the trade-off
that it may be a few seconds before the callee sees who's calling.

However, with dynamically generated web pages, this would be very
awkward and the caching benefit would not accrue, so it is perfectly
appropriate to include them in the message body.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 23 Nov 1999 11:26:09 -0500

> access a picture if desired without burdening the call signalling.

I agree. Note this is one of the applications of the Content-Disposition
header, to say that the content is for display. Thus, one would do
something like:

INVITE sip:user@host SIP/2.0
Content-Type: application/uri-list
Content-Disposition: display

http://www.host.com/myjpeg

This allows us to use HTTP as the transfer protocol, as it was intended.

We also need a way to indicate that a body is optional, in the case of
multipart. This will likely be needed for SIP-T as well. By optional I
mean that the receiving agent can ignore it. Normally, if a UAS receives
an INVITE with a body it doesn't understand, it returns an error.

One could also use "logical channels" for still image transfer. However,
I see uses for sending pictures and html, either by reference or
imbedded, if size allows, within INVITE and its responses. Thats because
they serve to provide additional information about the calling or called
parties, or about the call itself. This is different from DTMF, as we
are not trying to invoke call services with this content. Its also
different than dtmf because of the synchronization, voice-recognition,
and other issues that I have raised in past emails. I do agree, though,
that sending images in INFO mid-call is probably not the best idea, and
that a media stream for this is better.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com