Subject: Re: JPEG in INVITE

From: [email-masked]
Date: Thu, 23 Dec 1999 20:40:17 +0530

Hi,
 I have one question:
This is not protocol related. but  I guess its more implementation related,
and is relevant for UDP only:
As it is, when a SIP message is received, the reciever does not know the
size of the received message and hence I guess must allocate some fixed
space for it before doing the n/w read as allocating 64k for a message may
not always be desirable.

However, a typical _single_ sip message takes approx < 500 bytes. However,
if we allow JPEGS/(bitmaps - oops)  inside, the size of the message body
can widely fluctuate.

Then the only way for a person who really does not want to allocate 64k is
to read from the n/w till he gets a content-length, figure out
the size and then read the rest of the body. this is kludgy at best.

So basic point is: as it is, the receiver does not know the size of the
message he is receiving  - but normal sip messages, he should be
safe in most cases with a moderate size (~3000 bytes ?) - but that is not
so when images are embedded.

So worst case what will happen is that many apps might read till a set
number of bytes, therefore chopping the body, and would
probably discard the message ?

In that respect, isnt it better to use the uri-list type as a pointer to
the http image ?

In this way, we dont stuff a lot of image data directly in the message and
an app can decide if it really wants to pick up the image, instead of it
being forced to him (ofcourse, the delay of doing yet another http get is
there for the image)

Just wondering, does the question of 'how much of an allocated  SIP message
size am I safe with' really  bother anyone, or is it that
64k is too less to worry so much about ? ( I for one have come across
embedded sys. vendors who want voip protocols on h/w cards. who scream at
every extra couple of bytes added....)

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems

Jonathan Rosenberg <[email-masked]> on 12/23/99 08:15:29 PM

To:   Taji Rachid <[email-masked]>
cc:   "'Alvir Alisic (ECS)'" <[email-masked]>,
      [email-masked]

Subject:  Re: JPEG in INVITE

There are two basic ways to do this, both of which have now been
mentioned on the list. The first is to treat the image as part of the
signaling, and include it somehow in the INVITE. This would be
accomplished, as Scott has suggested, using MIME multipart, with one
type possibly being image/jpeg. We have discussed using the MIME
Content-Disposition header to allow the UAS to know the purpose of the
MIME content. To date, we have seen MIME bodies needed for several
reasons:

1. for session descriptions
2. for display
3. for tunnelled signaling (ISUP)
4. for billing/accounting (OSP tokens)

The reason I mention this is that I think rather than including the
image in SIP itself, its a bit better to include the type text/uri-list,
which is just a list of URIs. Then, one of the URIs is an http URL that
points to the JPEG image. When one does this, the Content-Disposition
header becomes important. This is because the URI might point to any one
of the 4 content disposition types above, and to know how to handle it,
the UAS needs to know which before its even fetched. We will also need,
I think, an additional parameter which indicates whether the body is
optional or mandatory. Scott has suggested that for multipart, any
unknown bodies are discarded. I'd rather be explicit about that.

The second approach is to have the image be a media stream. This would
be done by including an additional m line in the SDP. The formatting
suggested by Taji is not quite right though. It would look like:

m=image 49170 RTP/AVP 55
a=rtpmap:55 jpeg
c=IN IP4 10.1.1.1

So, whats the difference? Which is the "right" way? In this case, I
believe inclusion in SIP is the right way. There are several reasons for
this:

1. The purpose of the image is to assist the user in deciding whether to
accept or reject the call. We have headers like Subject in display name
which serve a similar function; these are part of the signaling
function.

2. Security can be better when this is placed in signaling. When a UAC
includes a jpeg image or URL, its outgoing proxy can verify these as
being correct (based on a preconfigured list of allowed content and
URLS, perhaps), and then resign the request. This provides a form of
enhanced caller ID service, as the identity of the caller is verified by
a service provider now, whose key a called party is more likely to have.

3. We save the complexity and overhead of establishing a media channel
just for a single image.

The line between what to do in SIP, and what to do in a media stream, is
hard to draw. If the content is not interactive (like a static image
that already exists), it affects how the user is likely to handle the
call, and it can be obtained through redirection, SIP might be the
better choice.

-Jonathan R.

Taji Rachid wrote:
>
> Hi alvir,
>
> I think you can do that in SDP part like this:
>
> c= "IN"  "rfc2543"  IpAdressOfReceiver
> m= "image" portOfThisIPAdress "UDP" " JPEG"
> a= "fmtp:JPEG"  "uri:"http://mycampany/xxx.jpeg
>
> portOfThisIPAdress :  is the port to wich the image will be sent
> uri   : is the uri of the image
> IN    :stands for internet.
> You can get more information in RFC 2327 SDP protocole
>
> Merry christmass an Happy new Year
>
> > -----Original Message-----
> > From: Alvir Alisic (ECS) [SMTP:[email-masked]]
> > Sent: Donnerstag, 23. Dezember 1999 10:13
> > To:   [email-masked]
> > Subject:      JPEG in INVITE
> >
> > Hey!!!
> >
> > I want to send JPEG pictures in my INVITE messages, but I don't know
how I
> > can do that. Is there anyone who can help me???
> >
> > Marry Christmas and Happy New Year
> >
> > Kind Regards
> > Alvir
> >
> > Alvir Alisic
> > M. Sc Candidate - Datacom Software
> > Ericsson Mobile Communications AB
> > Lund, Sweden
> > mailto:[email-masked]
> > phone:+46 (0)46 19 38 39
> >
> >

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

---

From: Bobby Sardana <[email-masked]>
Date: Fri, 24 Dec 1999 00:01:16 -0600

Greetings:

> space for it before doing the n/w read as allocating 64k for a message may

Just curious. I would like to know why you would allocate a buffer of 64K. You
can perform dynamic allocations or use collections and the size of the message
becomes immaterial.

> the size and then read the rest of the body. this is kludgy at best.

I would like to know why this is kludgy? To me, it's the only technique that
makes sense. Unless you know the length, the hint of which is provied by the
Content-Length header,  there is no other way to approximate the length of the
body. If I am missing something here, let me know.

Merry Chrismas and Happy Millenium to all!

Bobby Sardana.
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 23 Dec 1999 17:39:26 -0500

> the size and then read the rest of the body. this is kludgy at best.

SIP has a response code that is "message body too large". If you wish to
impose restrictions in your implementation, you can just read enough
bytes to get the header. This will tell you the size of the body. If
thats too much for your tastes, reject the message.

I agree that since SIP is not meant as a transfer protocol, including
lots of data in UDP can be bad for small implementations. There is
another issue, which is UDP message fragmentation at the IP layer.
Fragmentation causes an amplication effect in the loss probabilities, so
that a small loss probability can result in significant packet loss
(this is only true for independent packet losses; its not as bad for
highly correlated packet loss). Using lots of data in UDP will cause the
messages to be fragmented.

-Jonathan R.