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

From: "Agarwal, Aseem" <[email-masked]>
Date: Mon, 23 Oct 2000 11:54:51 -0700

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

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

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

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 23 Oct 2000 17:22:58 -0400

> would still need to put CL in the response if it were sending multiple

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