Subject: [Sip] Open Issue #220: Stateless SRV Pain II

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 6 Dec 2001 15:46:49 -0500

The specification requires that all requests within a call be sent to the
same 
address. It was assumed that this could be accomplished statelessly by using
the 
call-id as the seed of a random number generator to select one element
amongst a 
set of equal priority elements with different weights. However, thats only
true 
if the first try succeeds. If it fails, the next server is used. In 
that case, there is state reflected in the fact that two tries were made.
Its 
not clear how this is accomplished in a stateless proxy except to have it
always 
start at the top; it will try that first server, have it fail, and then use
the second. 
Thus, each retransmission will retry the failed server. If there are N
failed servers, each
retransmit will have to try each of those N servers over again.

Of course, if the 
element comes back to life mid-transaction, you will split requests across 
elements for the same transaction. That may be OK in some cases, not OK in 
others.

Discussion:

It is clear that SRV processing is difficult and complex to do on stateless
elements. I don't want to rule it out, but I think the specification should
be honest and recommend that if you do SRV processing a proxy, it should
really be stateful in order to reasonably operate. If a stateless proxy uses
SRV, the problems described above will occur. The result will be overly long
setup times, and potential failure scenarios when elements are added or
removed from service, either gracefully or through failure or recovery.

Proposal:

RECOMMENDED that proxies whihc do SRV are stateful
Document the limitations when stateless proxies do SRV

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Dec 2001 11:38:27 -0500

There were no comments on this proposal on the list.

This proposal is more or less what was placed in draft-ietf-sip-srv-03; 
the text there is a bit softer, saying that all proxies have to meet the 
requirement that all requests within the same transaction (plus CANCEL 
for it) need to go to the same server, period. If a stateless proxy can 
accomplish that, great, and the text gives some guidelines about doing 
it when there isn't a failure. However, when a server has failed, it is 
impossible to do statelessly, and the text points this out.

As such, I consider this issue resolved.

-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