Subject: Re: [Sip] About maintaing reliable connections according to bis05

From: [email-masked]
Date: Thu, 20 Dec 2001 09:46:42 +0530

Hi Jonathan,
isnt 16 seconds recommendation too small for this purpose?

lets say, an original RFC compliant client A tries to contact client B
through a proxy P.
proxy P is implemented according to bis-05, where after it sees that
connection is idle since 16 seconds it closes the same.

the INVITE from A gets proxied to B, and B takes more time to pick the hand
set.
meanwhile the connection on proxy timesout and it terminates the
connection.
now the client A, is in a fix.

I understand that the coupling transport and transaction layer for solving
this implementation is complex,
but I dont think there might be any problem if the recommended timeout
value is sufficiently high, which to some extent
reduces probability of such problems wrt backword compatibility.

regards,
Shetti

Jonathan Rosenberg <[email-masked]> on 12/20/2001 02:29:54 AM

To:   Shrinivas Shetti/HSSBLR
cc:   [email-masked]
Subject:  Re: [Sip] About maintaing reliable connections according to bis05

[email-masked] wrote:

>
> Hi,
> bis-05 states under "section 19 on TRANSPORT" as below
>
> "It is RECOMMENDED that connections be kept open for some implementation
> defined time after the last message
> was sent or received over that connection. This time SHOULD be at least
16
> seconds in order to ensure with
> high probability that responses can be sent over the same connection a
> request was sent."
>
> This recomendation will have problems with the clients already
implemented
> according to RFC2543.
> These clients will see the connection closure as Server Error which is
not
> desirable, when there are transactions initiated
> by them are still not complete.
>
> backword compatibility is lost because of this recommendation,
> Suggestion is that "this recommendation must be applicable only on the
> transactions that have been completed."

No. The point of the 16s is to guarantee exactly this. Thats why it says
" ensure with high probability that responses can be sent over the same
connection a request was sent.".

However, we absolutely do not want to say to wait until all transactions
have been completed, since this requires coupling of transport layer
behavior with transaction behavior, and is an unholy nightmare to
implement properly. A timer captures the essence of the requirement
without the hassle.

I will, though, clarify that the timer is aimed at ensure transactions
complete over the same connection, since its not just responses, but ack
(for non-2xx) that you want over that connection.

-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Dec 2001 23:12:28 -0500

> now the client A, is in a fix.

Right, so the number needs to be bigger. I'll be sure to put in the 
right value (need to think about what it is). It definitely depends on 
timer C, which is the amount of time a client transaction waits for a 
final response to invite after a provisional. There is a related bug, 
which is that we need to set a minimum value for that timer as well, so 
proxies don't trash invite transactions too early....

-Jonathan R.