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

From: "Arnoud van Wijk (ELN)" <[email-masked]>
Date: Tue, 24 Oct 2000 09:48:59 +0200

I was watching this thread with interest.
It is indeed a good question if there is an implementation that sends multiple messages in one single datagram.
I think that it is possible. Perhaps some dedicated SIP server that has to send many small messages to a centrally located SIP proxy. Thus instead of sending 40 UDP packets, it may be possible to place them all inside just one datagram (message size depending ofcourse).

So I would in this case make the Content-Length mandatory for that server. 

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

In my opinion, I think that this is just a case of UA behaviour and not SIP.

What I would suggest is thus that Content-Length has to be mandatory for UAS or UAC that put multiple messages in one UDP datagram.
And then if there is no Content-Length given, the receiving UA can then act as in the RFC "(...)If a server receives a UDP request without Content-Length, it MUST assume that the request encompasses the remainder of the packet."

Maybe it is a good idea to add to the bis-draft that Content-Length MUST be included by the UA when there are Multiple messages placed into one UDP datagram. AND when messages are (likely) to be split over 2 or more datagrams.

Just my 2 Euro cents :-)

Arnoud
_______________________________________________________________
ERICSSON EUROLABS NETHERLANDS BV
Arnoud van Wijk
ABACUS Lab
Research & Development (ELN/V)
Fax: +31-161 247569
_______________________________________________________________

-----Original Message-----
From: Agarwal, Aseem [mailto:[email-masked]]
Sent: maandag 23 okt 2000 20:55
To: 'Jonathan Rosenberg'; 'Piotr S. Kossowski'; unlisted-recipients
Cc: [email-masked]
Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified
beh aviour)

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: "Agarwal, Aseem" <[email-masked]>
Date: Tue, 24 Oct 2000 09:06:37 -0700

Hi Arnoud,
    Please find my comments below:

-rgds,
aseem

-----Original Message-----
From: Arnoud van Wijk (ELN) [mailto:[email-masked]]
Sent: Tuesday, October 24, 2000 12:49 AM
To: 'Agarwal, Aseem'; 'Jonathan Rosenberg'; 'Piotr S. Kossowski'
Cc: [email-masked]
Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified
beh aviour)

I was watching this thread with interest.
It is indeed a good question if there is an implementation that sends
multiple messages in one single datagram.
I think that it is possible. Perhaps some dedicated SIP server that has to
send many small messages to a centrally located SIP proxy. Thus instead of
sending 40 UDP packets, it may be possible to place them all inside just one
datagram (message size depending ofcourse).

[ASEEM] Theoretically possible, but I was looking for a more realistic
example. 
Will an application ever like to delay sending out a "small UDP datagram" in
order
to club it with other such smaller datagrams ??

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

What I would suggest is thus that Content-Length has to be mandatory for UAS
or UAC that put multiple messages in one UDP datagram.
And then if there is no Content-Length given, the receiving UA can then act
as in the RFC "(...)If a server receives a UDP request without
Content-Length, it MUST assume that the request encompasses the remainder of
the packet."

Maybe it is a good idea to add to the bis-draft that Content-Length MUST be
included by the UA when there are Multiple messages placed into one UDP
datagram. AND when messages are (likely) to be split over 2 or more
datagrams.

[ASEEM] I concur with you on this point.

Just my 2 Euro cents :-)

Arnoud

-----Original Message-----
From: Agarwal, Aseem [mailto:[email-masked]]
Sent: maandag 23 okt 2000 20:55
To: 'Jonathan Rosenberg'; 'Piotr S. Kossowski'; unlisted-recipients
Cc: [email-masked]
Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified
beh aviour)

Hi all,

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

---

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 24 Oct 2000 12:57:07 -0500

Actually, if you were going to do it, why not get the information in a
manner that solves a couple of problems:

generic-message = start-line
			length-header
                  *message-header
                  CRLF
                  [ message-body ]

length-header = Length: SP [message-length]/[message-body start]

Example:

     INVITE sip:[email-masked] SIP/2.0
     Length: 500/234
     ...

Where message-length is the total message length, and message-body start is
the byte offset that the message body actually begins at. This would help
for a couple of reasons:

1. If you just say that it's a message header, then it can appear at
basically anywhere in the message. Instead of searching for CRLF CRLF every
time for TCP, now you'll need to search for "Length: " which is even worse.
If you require it up front then you know exactly where to expect it.
Moreover, you'll know exactly when you're not going to get it (so you can
stop looking) and so you can switchover to looking for CRLF pairs again
because the sender doesn't support that header.

2. If you give the message length early on, then you will know how much
buffer to reserve right away. No more guessing, or dynamic buffer resizing
problems. You get your message in, you see the length, and you can
immediately create the right sized buffer knowing you're not going to be
wasting space or have to resize your buffer. This isn't a big problem for
small systems, but every little bit of efficiency you can squeeze into the
message helps for larger systems.

It would be best (in my mind) to include the message length/start as the
first token in the start-line, but I imagine doing that would seriously
confuse the SIP parsers that are already out there and cause problems.
Pretty much, you're stuck with the current tokenization scheme for the
start-line from now on, unless there's a requirement that parsers look for
the sip version (i.e. look for the "SIP/2.0" in the first line) before doing
anything else.

MTP/SCCP is nice in this respect because they have pointers embedded in the
message that tell you the start offsets and data lengths that you're dealing
with.

Brian Stucker
Nortel Networks

-----Original Message-----
From: Agarwal, Aseem [mailto:[email-masked]]
Sent: Tuesday, October 24, 2000 11:25 AM
To: 'Henning G. Schulzrinne'; Agarwal, Aseem
Cc: 'Jonathan Rosenberg'; 'Piotr S. Kossowski'; [email-masked]
Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified
beh aviour)

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)

> 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