Subject: Re: jpegs in INFO messages?

From: "Gregory D. Girard" <[email-masked]>
Date: Mon, 22 Nov 1999 19:55:08 -0500

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.

Greg Girard

-----Original Message-----
From: Sean Olson <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Monday, November 22, 1999 6:29 PM
Subject: Re: jpegs in INFO messages?

>> 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.
>>
>
>I believe the application was more of a still picture than video streaming.
>I think everyone realizes that SIP is NOT a transport protocol. If I
>understand what Dean was proposing, this application would be akin to some
>of the information passed in RTCP.
>
>> 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.
>
>No more than any other SIP message. What happens if a UAC issues an
>INVITE request with a multipart body that includes SDP and some other
>unknown MIME type? Would you consider this abuse? Would you reject the
>request? You of course have to restrict some usages of the INFO message
>or any other SIP message but this is not a problem unique to the INFO
>message.
>
>>
>> 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".
>>
>
>Again, SIP is NOT a transport protocol. Large payloads like JPEG/TIFF/etc.
>would be inappropriate and should be restricted in some cases. But I don't
>believe this is the intended usage of the INFO message.
>
>> 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.
>>
>
>Depending on the intent/usage of the INFO message, it may very well be that
>they are delivered directly to the UAC/UAS. If you wish to segregate the
>signalling and media networks then you may have to enforce certain
>restrictions on the SIP signalling to ensure certain characteristics as you
>mention. In general, however, since SIP is not a transport protocol, there
>are no provisions for fragmentation. So sending INFO messages with huge
>bodies is really not an option in many cases....
>"413 Request Entity Too Large"
>
>> Tim Schroeder
>
>-----------------------------------------------------------------
>Sean Olson            E-mail: [email-masked]
>Ericsson Inc.         Voice: (972) 583-5472
>                      FAX: (972) 669-0154
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 22 Nov 1999 20:11:04 -0500

> 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