Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified behaviour)

From: [email-masked]
Date: Tue, 24 Oct 2000 14:03:55 +0530

Arnoud> In my opinion, I think that this is just a case of UA
Arnoud> behaviour and not SIP. What I would suggest is thus that
Arnoud> Content-Length has to be mandatory for UAS or UAC that
Arnoud> put multiple messages in one UDP datagram.
Arnoud> And then if there is no Content-Length given, the
Arnoud> receiving UA can then act as in the RFC "(...)If a server receives
a
Arnoud> UDP request without Content-Length, it MUST assume that the
Arnoud> request encompasses the remainder of the packet."
Arnoud> Maybe it is a good idea to add to the bis-draft that
Arnoud> Content-Length MUST  be included by the UA when there are
Arnoud> Multiple messages placed into one UDP datagram. AND when
Arnoud> messages are (likely) to be split over 2 or more datagrams.

Actually the presence of Content-Length for multiple message in a UDP
packet, although
not explictly mentioned in the draft seems to be implicitly stated by the
para:

(pg 45, 6.18)
"If a response does not contain a Content-Length, the client assumes
that it encompasses the remainder of the UDP packet or the data until
the TCP connection is closed, as applicable."

This means that if the sender did want to send multiple messages in a UDP
message, if he did not specify a content-length, the recipient would treat
it
as one full message anyway, and probably throw an error if he tried to
parse
the body or at best include the entire bunched messages as one body (incase
the Content-Type said some body type which the recipient did not
understand),
which is not something the sender wanted in anycase. So if you wanted the
recipient
to interpret it as multiple messages, this para seems to state you dont
have
any other option but content-length .

Arnoud> Splitting SIP messages over 2 or more datagrams for TCP
Arnoud> would not matter at all since the message would be pieced
Arnoud> together in one whole piece. Thanks to TCP, right? (just
Arnoud> as long that the Content-Length is given, the server knows where
Arnoud> the new message starts)

Not directly related to your point, but here goes:

My main point of concern with TCP is more to do with the buffer the user
specifies
while reception. My worry is more to do with application reassembling
rather than
TCP/IP stack re-assembing. The current logic of finding out message length
for TCP is
read a buffer, grep for Content-Length,say value X. if bytesRead < X read
X-bytesRead
more bytes, cat it as a complete message and then go ahead to do a parse.
However, what if the recipient does a read() with a buffer B. It is
possible that in
the first read, he does not get the content-length header. Or maybe he gets
half of it.
Then what does he do ? He has to add more code to handle these scenarios
just to ensure
that he has the complete message. All this stems from the fact that the
header that actually
may specify length of the message can occur anywhere in between the header
section. So,
the user can never be sure that there will not be a scenario where he
cannot figure out the
length of the message after the first read(). Also in this method, his read
buffer
must be large enough to accomodate the first content-length header - which
is a heuristic
value.Since he does not know how big a message is, he cannot do an alloc
just for that much
(if he wants to).
Things are relatively fine if we assume that the first read gets the
complete
C-Len header. All this could be avoided if for stream
oriented protocols we have a concept similar to TPKT. I think this point
has been
raised several times, but it was decided not to do anything similar to
TPKT.
The bad part is that this makes is protocol specific. Good part is that it
avoids
these application level re-assembling worries.
So the question is, how important is each, relatively ?
I would like some comments from other implementors too - do you find the
existing
mechanism sufficient for you, do you find it inappropriate,
or is there a neat solution which someone has out there which you can share
?

Regds
Arjun

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

---

From: Howard Hart <[email-masked]>
Date: Tue, 24 Oct 2000 10:06:53 -0700

Hi Arjun,

I think this is covered (implicitly) in sections 3 and 4 of 2543:

generic message =
          headers...
          CRLF
          [message body]

By implication, you haven't received the complete header section (including
Content-Length) until the first empty CRLF line, so buffer processing needs to
wait until the remainder of the packet is received or the connection is
lost/times out. Corrupted Content-Length headers should probably be handled by
throwing the entire message out with a 400 class response, keeping in mind
that a TPKT byte sequence is as no more or less likely to be corrupted then
the Content-Length header.

Henning, if you're out there, any chance we can be even more explicit in 6.18
and specify there must always be a CRLF even in messages with
Content-Length=0, and the Content-Length counter does not include that CRLF?

Howard Hart
ipDialog, Inc.