Subject: [SIP] Multi-message UDP datagrams

From: "Piotr S. Kossowski" <[email-masked]>
Date: Thu, 19 Oct 2000 22:30:39 +0200

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

---

From: Billy Biggs <[email-masked]>
Date: Thu, 19 Oct 2000 16:12:58 -0500

Piotr S. Kossowski ([email-masked]):

> [...] This allows several messages to be placed in a single UDP
> packet."

  Looking at your example:

> 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).
> 
>  UAC           UAS
>   INVITE ----->

  You should send a 200 response to the CANCEL anyways.

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

  Why does it matter how the UA does it?  In your example above, either
way the call still does not complete.  I can't think of any realistic
example where it would make any difference.

-- 
Billy Biggs, 3Com               Email: [email-masked]
http://www.div8.net/billy/      Phone: [email-masked]

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 19 Oct 2000 15:59:31 -0500

> <-----------200 (Cseq: xxx BYE)

Piotr:

Based on a re-reading of the spec, the CANCEL is responded to with a 200 
OK in any case; the CANCEL has no effect on the UAS state if it got to 
the UAS after the UAS sent out a final response.  However, the UAS 
still responds with a 200 OK for the CANCEL.  So your call flow should 
be:

  UAC           UAS
  INVITE-------->
  <------------- 200 OK (CSeq: xxx INVITE)
  CANCEL-------->
  ACK----------->
  <------------- 200 OK (CSeq: xxx CANCEL)
  BYE----------->
  <------------- 200 OK (CSeq: xxx BYE)
 
- vijay
-- 
Vijay K. Gurbani  [email-masked] [email-masked] [email-masked]
Internet Software Group/Intelligent Network and Messaging Systems
Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413
Naperville, Illinois 60566  Voice: +1 630 224 0216 Fax: +1 630 713 0184