Subject: Regarding the reliability via UDP

From: "Masanori Inui" <[email-masked]>
Date: Wed, 2 Feb 2000 22:17:56 +0900

Hi,

The spec. of SIP define how to ensure the reliability, if the entity is
using UDP.
My understanding of reliability is bellow. Please see those diagrams.
So, I have questions.

-Is my understanding correct?
-On (2),(3) and (4),the server goes to initial state(no cache the result)
 ,once the server send a 1st response.If the server receive the
re-transmitted request,
 the server send a 481 final response.Is the SIP allow this implementation?

I worry that the server can not accept a new call depend on cache space(real
memory),
because, I think that the cache time is too long.

(1)200 or 3xx response for INVITE

UAC          UAS
 ---INVITE---->
 <--100--------
 <--180--------
 <--200--------  + start of the timer for reliability
                 | (T1 * 2^n)
 <--200--------  + if UAS has not received ACK, BYE or CANCEL then
retransmit
                 |
                 |
                 + if UAS has not received ACK, BYE or CANCEL then
retransmit
                 |
                 v and, so on until the response has been transmitted 7times

(2)no-200 or non-3xx final response for INVITE

UAC          UAS
 ---INVITE---->
 <--100--------
 <--180--------
 <--xxx-------- + start of the timer for reliability
                | (T1 * 2^n)
 <--xxx-------- + if UAS has not received ACK, BYE or CANCEL then retransmit
                |
                |
                + if UAS has not received ACK, BYE or CANCEL then retransmit
                |
                v and, so on until the response has been transmitted 7times

(3)200 response for BYE,CANCEL,OPTIONS,REGISTER

UAC          SERVER
 ---BYE------->
 <--100--------
 <--200--------  + start of the timer for reliability
                 | (T2 * 10)
 ---BYE------->  + if SERVER has received BYE(re-transmit), then retransmit
 <--200--------  |
                 |
                 v and, so on until the response has been elapsed T2*10

(4)no-200 final response for BYE,CANCEL,OPTIONS,REGISTER

The same behavior as (3)

Best regards,

===========================
Masanori Inui
IWATSU Electric CO.,LTD
Project Team No.2
Solution Engineering Dept.
Engineering Division
---------------------------
1-7-41 Kugayama Suginami-ku
Tokyo, 168-8501, Japan
---------------------------
Tel.+81-3-5370-5211
Fax.+81-3-5370-5193
Email [email-masked]
===========================

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 02 Feb 2000 10:25:54 -0500

> -Is my understanding correct?

Generally looks right. There is no difference in user agent behavior for
the differing final responses to INVITE and non-INVITE requests (you
have two diagrams for INVITE, one for 200 or 3xx, and another for
everything else, but they are the same). Your diagrams don't show it,
but for INVITE the requests are retransmitted with an exponentially
increasing interval until a response is received (provisional or
otherwise).

Also, whilst the spec talks about stopping retransmissions of the INVITE
response if a BYE is received, I think the next revision of the spec
will not recommend this. The problem is for proxies. Since they don't
necessarily have call state, they will end up having two transactions,
one of which never completes. This causes stale transaction state to be
held in a proxy for longer than needed. As much as possible, I'd like to
keep transactions independent of each other. 

For a similar reason, the new recommended behavior for receiving CANCEL
is to keep retransmitting the final response if you've already sent it.
Otherwise, if the final response and the CANCEL cross on the wire, but
the final response is lost, the server thinks the call is set up, but
the client won't know since it will never receive a response to the
INVITE. Similarly, if the server hasn't sent a final response to an
INVITE, the server should send a 487 response to the INVITE when a
CANCEL comes. This ensures that the original INVITE transaction
completes like a normal transaction; CANCEL just speeds it up. 

>  the server send a 481 final response.Is the SIP allow this implementation?

For a user agent server, no. It must cache the response (I think for 60
seconds), or regenerate the same response (possible if the initial
response was some kind of error because the request was bad). Otherwise,
the reliability doesn't work.

For a proxy or redirect server which generates its own response, its the
same as UAS. 

For a stateful proxy that forwards a response it received, it must also
cache the response.

A stateless proxy need not cache a response. When a request
retransmission is received, it forwards it as if it was the initial
request (it can't tell the difference between a retransmission and the
original request).

> because, I think that the cache time is too long.

What kind of server? For a UAS, you still need to store call state
anyway. You will need to store things like CSeq numbers, routes,
credentials, To and From fields, and so on. I can't imagine that for a
UAS handling high call volumes (a gateway typically) the memory
requirements for the responses are a bottleneck. 

If you are worried about memory requirements in a proxy, use a stateless
proxy. They don't need to cache anything.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Masanori Inui" <[email-masked]>
Date: Thu, 3 Feb 2000 12:48:11 +0900

Hi, Jonathan,
Thank you, for your reply,

I almost understood your explanation.
I will implement which the server remember the result(what kind of response)
, and retransmit it when the server needs to send a response.

Further more, I would like to know how the server treat a request for new
call
when the server cache space is empty.

My idea is:
(1)The server send a 500 response(Server Internal Error) with Retry-After.
     In this case the server is not cache.
(2)The server silently drop a request for new call.
     In this case, the client will retransmit a request.

What do you think about these?
If you have any idea, please tell me them.

Thanks,
WEB http://www.iwatsu.co.jp

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Feb 2000 00:55:06 -0500

>      In this case, the client will retransmit a request.

The decision is yours. Its an implementation choice.

-Jonathan R.