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

From: "Agarwal, Aseem" <[email-masked]>
Date: Tue, 24 Oct 2000 09:25:02 -0700

Hi Henning,
    I have a different viewpoint. Collating EACH TCP message, searching
for CRLF CRLF, waiting for Content-Length bytes, etc., can be avoided by
adding
message length to each SIP message.
    In my implementation, I do not want to use fgets, I wish to be able to
read
whatever data is available in my TCP socket. So I am forced to search for
CRLF
CRLF sequence in EVERY TCP read call and then exercise TCP collation logic.
I see 
this as an extra overhead.

    In my previous email, TPKT was quoted as a suggestion. SIP can very well
have
a new general header "Message-Length" or this parameter may be added on to
"Request-Line" 
and "Response-Line".

    Computing and adding this header should not be an overhead.  It shall
definitely
simplify logic on the receiving end. Since an implementation can know how
many bytes
to wait for in all cases.

Regards,
aseem

-----Original Message-----
From: Henning G. Schulzrinne [mailto:[email-masked]]
Sent: Monday, October 23, 2000 2:23 PM
To: Agarwal, Aseem
Cc: 'Jonathan Rosenberg'; 'Piotr S. Kossowski'; [email-masked]
Subject: Re: [SIP] Multi-message UDP datagrams (probably not specified
behaviour)

"Agarwal, Aseem" wrote:
> 
> Hi all,
>   Is there a realistic situation where some implementation will
> send multiple messages in a single datagram ? If NOT, then is it
> not better to remove this source of confusion from the new version
> of the draft.
> 
>    Another related point is about transport of SIP messages using
> TCP. Since it is possible to receive partial or more than one SIP message
> in one TCP-recv() call, an implementation has to put in extra logic to
> determine the end of the message, e.g. find out the CRLF CRLF sequence,
> then check for Content-Length header, wait for the remaining bytes and
> so on..
> 
>   One option may be to have an application level framing mechanism
> (something similar to TPKT -rfc 1006) to simplify things. What is the
> general opinion about this issue ?
> 
> -regards,
> aseem
> 
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Monday, October 23, 2000 10:50 AM
> To: 'Piotr S. Kossowski'; unlisted-recipients
> Cc: [email-masked]
> Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified
> beh aviour)
> 
> 
> 
> > -----Original Message-----
> > From: Piotr S. Kossowski [mailto:[email-masked]]
> > Sent: Monday, October 23, 2000 1:42 PM
> > To: unlisted-recipients
> > Cc: [email-masked]
> > Subject: [SIP] Multi-message UDP datagrams (probably not specified
> > behaviour)
> >
> >
> >
> > Hello,
> >
> > After further studying of Multiple response per UDP datagram issue,
> > and Content-Length header, I suppose that inaccuracy may appear.
> >
> > Scenario: first let's forget about single UAC that sends
> > many messages in one datagram.
> > Let's assume that in UDP datagram received by UAS there are
> > two messages,
> > however (perhaps, because of unique implementation of proxy that
> > multiplexes messages to one datagram...). These messages may
> > be not correlated and both did NOT contatin Content-Length,
> > and both have correct syntax (and semantics, as well).
> > Their orginators assumed that UAS would distinguish body
> > from message according to section 6.18 of the spec:
> >
> > "(...)If a server receives a UDP request without Content-Length,
> > it MUST assume that the request encompasses the remainder of
> > the packet."
> >
> > So UAS starts parsing of message and it assumes that the body
> > is to the end of the packet. And this is not true because
> > such body will contain body from the first message and all the
> > remainder: headers from the second message plus the second
> > body etc.
> 
> Well, thats because the implementation that has sent multiple responses
has
> erred. If it puts multiple responses in a packet it has to use
> Content-Length, else what you have
> described will happen.
> 
> > I have also another question:
> >
> > Table 4 from section 6.4 of the spec. assumes for Content-Length
> > in Methods to be "m*", what indicates that the header SHOULD be sent,
> > but servers need to be prepared to receive requests without
> > that header
> > field.
> >
> > Is there any important reason for "m*" instead of "m" for
> > this header ?
> 
> Yes. It was not mandatory in rfc2543. So, for backwards compatibility,
> you must be prepared to deal with that (of course, an rfc2543
implementation
> would still need to put CL in the response if it were sending multiple
> messages per datagram).
> 

In my view, bad idea. It diverges from what's being done in HTTP and
RTSP, for no gain. Also, as soon as you add RFC 1006, it's no longer a
text protocol, so you loose some of the advantages. It also adds yet
another error condition, where the Content-Length disagrees with the RFC
1006 length. In practice, as discussed previously, TCP parsing is 50
lines of code: read lines until blank line (using fgets or whatever),
then parse header, then read message body, or some variation on this
theme.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

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

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 24 Oct 2000 12:58:57 -0400

The time for such proposals was about three years ago. Let's not waste
time on proposing changes that break every existing SIP implementation
to save 50 lines of code. That's the last I say about this.