Subject: RE: [SIP] Multi-message UDP datagrams

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 20 Oct 2000 01:12:24 -0400

It was my view that receiving multiple messages in a single datagram was the
same as if they were received in separate datagrams. In other words, there
was no requirements for ordering or completion. The result of that was a
simplification in the implementation of handling this case; UDP works just
like TCP. Imposing transactional requirements adds significant burden. I'd
rather not do that unless there was serious requirements or needs here.

In fact, I would argue that multiple messages per datagram might be
something to consider for removal. I've never seen it used. I'm not sure
what the benefit is, in reality. There is little byte savings, and its just
more complexity that is really needless.

Lets simplify, not complicate. 

-Jonathan R.

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

> -----Original Message-----
> From: Piotr S. Kossowski [mailto:[email-masked]]
> Sent: Thursday, October 19, 2000 4:31 PM
> To: [email-masked]
> Subject: [SIP] Multi-message UDP datagrams
> 
> 
> Hello,
> 
> >From rfc-2543bis-02:
> 
> "(...)
> If there is additional data in the UDP packet after the last byte of 
> the body has been read, the server MUST treat the remaining data as
> a separate message. This allows several messages to be placed in a 
> single UDP packet."
> 
> This way of message servicing is to my mind data queueing issue.
> I'm not sure of my interpretation.
> Let's consider scenario:
>  
> UAS receiving UDP datagram containing two correct messages:
> INVITE and CANCEL (matched to this INVITE). Immediately,
> it receiving also BYE (to INVITE). We can conisder it
> as a FIFO queue of messages (1.INIVTE 2.CANCEL 3.BYE).
> 
> Let's assume that UAS decide to send 200 response.
> So, to my mind, sequence of message processing should look like:
> 
>  UAC           UAS
>   INVITE ----->
>   <-----------200 (without earilier 18x repsonses)
>   CANCEL------>
>   "<----------" CANCEL has no impact because of 200 resp. to 
> INVITE (?)
>   BYE---------> (Without ACK for 200 resp. to INVITE)
>   <-----------200 (Cseq: xxx BYE)
> 
>   ... and call terminates
> 
> To summarize:
> UAS should service all the messages from one UDP datagram
> BEFORE reading next portion of data from network. For each serviced
> message should generate a response (or take up other appropriate
> action) BEFORE processing next message from the datagram or network.
> 
> It's rather correct, Is it ?
> 
> 
> Piotr
> 
> 
> _______________________________________________
> 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: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 20 Oct 2000 10:19:55 -0500

> Lets simplify, not complicate.
[...]

For whatever it is worth, I agree.  In the bakeoff scenarios, I have
never
seen a SIP entity send multiple messages in the same datagram.

Regards,

- vijay
--
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software/IN Architecture Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713
0184

---

From: "Piotr S. Kossowski" <[email-masked]>
Date: Fri, 20 Oct 2000 18:50:39 +0200

> seen a SIP entity send multiple messages in the same datagram.
To be honest, I also don't see an important reason for sending multiple 
messages in the same datagram. But I wasn't interested in client side.
I only wondered what would happen if a server got these messages
in the same datagram, somehow. And RFC foresee such situation,
because says: "process everything" instead of "truncate after first
processed message from datagram"...

Regards,
Piotr

---

From: Sean Olson <[email-masked]>
Date: Mon, 23 Oct 2000 09:31:08 +0200

I would strongly disagree with the complexity issue. You need to know where the
end of a
SIP message is. What happens if you receive garbage at the end of a UDP datagram?
If you are going to take the time to deal with Content-Length: or multipart/*,
then you've
gone 99% of the way to supporting multiple messages in a single UDP datagram.
Easy cheesy! This is not that complex.  I would remove line folding before I
messed
with this. (Not that I'm suggesting we do this)

--
Sean Olson <[email-masked]>

---

From: "Piotr S. Kossowski" <[email-masked]>
Date: Mon, 23 Oct 2000 19:42:17 +0200

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.

If behaviour of UAS would be different, please someone to explain it.

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 ?
Or this is only for avoiding of redundancy during sending messages that
usually don't contatin body.

If this header had status "mandatory always" we would avoid
inaccuracy that I described above (if I'm right)

Regards,
Piotr