Subject: Re: jpegs in INFO messages?

From: Sean Olson <[email-masked]>
Date: Mon, 22 Nov 1999 17:25:35 -0600 (CST)

> 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: Chip Sharp <[email-masked]>
Date: Mon, 22 Nov 1999 20:20:27 -0500

I see that we are close to repeating the arguments from the late '80s in 
T1S1 and ITU over carrying User-User Information Elements in SS7 messages.

In fact, all this argument over carrying information in the signaling 
network vs the data path is causing serious flashback to ISDN.

Chip

At 04:26 PM 11/22/99 -0600, Schroeder, Tim wrote:

>This e-mail and any files transmitted with it are the property of SBC,
>are confidential, and are intended solely for the use of the individual
>or entity to whom this e-mail is addressed. If you are not one of the
>named recipient(s) or otherwise have reason to believe that you have
>received this message in error, please notify the sender at
>[email-masked] and delete this message immediately from your
>computer. Any other use, retention, dissemination, forwarding, printing,
>or copying of this e-mail is strictly prohibited.
>

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.			
--------------------------------------------------

---

From: "Gregory D. Girard" <[email-masked]>
Date: Tue, 23 Nov 1999 05:03:35 -0500

See my comments below marked "GG:"

>"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).

GG: I knew somebody would get wrapped around the "signaling links"
reference. I should have chosen a different word. I meant more like sausage
links (connections between units, in this case "switches"), or more
specifically as in (American Heritage 2a.) "A unit in a transporation or
communication system". Sorry for the confusion.

I don't believe bandwidth is the only issue here, but more the latentcy
between transmission elements. A tiny 2" square JPEG would be at least 20K
of data payload; maybe that is ok, but speaking as someone who has been
working in video phone technology for years, it sounds like a slow motion
video phone to me. More specifically, an ITU-T "still image transfer" is
what I remember the term to be. In the ITU-T H.32x model we already have,
this is in the media pathway via logical channel set to a specific
asynchronous transfer mode. Besides, no matter how much transmission
capability lies in the back-end of the network, the connection between the
user station and the switch will still likely proceed via ISDN or some
limited bandwidth pathway in many cases (particularly wireless), and
restrict us to a "D" channel or less for signaling.

*** It is my opinion that the signaling model used on the next-generation
network architecture should have at least some reasonable level of natural
compatibility with the world's existing infrastructure ***

In my own view, pics in the signal channel will break that model (besides
being just bad form). For example, I calculated that it would take roughly
12-15 seconds to transmit that JPEG through and ISDN "D" channel if one were
to map SIP to a standard ISDN Basic Rate Interface. Hardly workable. So the
image would have to be extracted from the SIP signaling link and reinserted
into the media stream according to something like H.32x, which has the
capacity to deliver an image to the terminal, but not through a signaling
channel. And then it is only a matter of time before common practice expands
the SIP image transfer to file transfer, and soon we pumping multi-megabyte
packages through the signaling channel. And then we would be forced to set
limits on the bandwith used by SIP and be right back to where we started
with the ISDN restrictions on "signaling link" bandwith to ensure call
setup/teardown timeliness. I support a model in which  what goes through SIP
is: (1) signaling directly related to the state of the connection, (2)
addressing info related to the connection, and (3) primitive user stimulus
during the session. Now, if one wants to use SIP to signal image transfer,
then I'd go along with that.

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

GG: See reasons above. Henning, I thought I saw you name on orignal SIP IETF
papers and other work on SIP going way back. You tell me, doesn't still
image transfer breaks the model ?.  I'm just putting in my two cents, but
cleary I'm on the periphery. I cannot fully understand why the idea of DTMF
digits in the SIP pathway has gone against the grain of so many, but images
! There is no signaling case at all for this usage.

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

GG: I'm less well versed in this field use in Europe, so I can't comment.
>
>--
>Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>

---

From: "Gregory D. Girard" <[email-masked]>
Date: Tue, 23 Nov 1999 07:38:31 -0500

Pete,

I agree with your perspective.

Greg Girard

-----Original Message-----
From: Pete Cordell <[email-masked]>
To: Henning Schulzrinne <[email-masked]>; Gregory D. Girard
<[email-masked]>
Cc: Sean Olson <[email-masked]>; [email-masked]
<[email-masked]>
Date: Tuesday, November 23, 1999 7:31 AM
Subject: Re: jpegs in INFO messages?

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