Subject: RE: [Sip] RE: [Sipping] RE: [Sip-implementors] 4xx by stateless p roxy

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 6 Nov 2001 00:50:28 -0500

> -----Original Message-----
> From: Vijay Gurbani [mailto:[email-masked]]
> Sent: Monday, November 05, 2001 10:10 AM
> To: Dorgham Sisalem
> Cc: [email-masked]
> Subject: Re: [Sip] RE: [Sipping] RE: [Sip-implementors] 4xx 
> by stateless
> proxy
> 
> 
> Dorgham Sisalem wrote:
> > 
> > Hello,
> > 
> > > Because it must match up the incoming ACK to the 3xx it send in 
> > > response. Recall that the ACK is part of the same INVITE 
> transaction in 
> > > case of a non-2xx response.  Furthermore, it must also be 
> able to match 
> > > up a CANCEL, if one should arrive, to the INVITE, and 
> stop further 
> > > processing of the INVITE.
> > 
> > I guess the question is: what will terribly happen if one 
> just "eats"
> > the ACK? 
> 
> Well, in the case of a non-2xx response, ACK basically is 
> used on the server
> end to stop retx'ing (if UDP is being used as the transport). 
>  Unless you
> are working on a lossless network, I don't think you can be 
> sure that the
> 3xx send upstream over UDP actually made it.  The ACK serves 
> as that not-
> ification.

Thats true, but there are two ways to reliably send the response. One is to
retransmit it until ACK, and the other is to retransmit the response on
retransmissions of the request. If a server does not send a 1xx response to
a request, the client will continue to retransmit the request, and this can
cause retransmissions of the response. In this case, the ACK is not
critical, and a server that knows its always a redirect server can "eat"
both the ACK and the CANCEL (of course it would need to respond to the
CANCEL with a 2xx).

THe notion of a "stateless uas", which is what this is, is not well
documented in bis-05. I am not sure how much we want to say about it, as it
is effectively an implementation decision that can be made, rather than a
new protocol element. However, since doing stateless responding is important
for security (and we do mention that), it might be worth giving more
guidance than is there now.

-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: Christer Holmberg <[email-masked]>
Date: Tue, 06 Nov 2001 08:48:30 +0200

Hi,

In a "stateless UA", if the ACK is not needed for the re-transmission
mechanism (or anything else), and it's only "eaten", why send it in the
first place???? Why not making it optional? And, if the client doesn't
know if the server is stateless or not it can be indicated somehow in
the response... We save messages in the network...

Just some thoughs...

Christer Holmberg
Ericsson Finland

---

From: Vijay Gurbani <[email-masked]>
Date: Tue, 06 Nov 2001 09:21:38 -0600

Jonathan Rosenberg wrote:
> > Well, in the case of a non-2xx response, ACK basically is used on the 
> > server end to stop retx'ing (if UDP is being used as the transport).
> > Unless you are working on a lossless network, I don't think you can be
> > sure that the 3xx send upstream over UDP actually made it.  The ACK 
> > serves as that notification.
> 
> Thats true, but there are two ways to reliably send the response. One is 
> to retransmit it until ACK, and the other is to retransmit the response on
> retransmissions of the request. If a server does not send a 1xx response 
> to a request, the client will continue to retransmit the request, and this 
> can cause retransmissions of the response. In this case, the ACK is not

Jonathan:

I respectfully submit that this behavior will lead to ambiguity and more 
interop nightmares! 

Since the dawn of SIP time, connection-less transports have had 2 ways to 
deal with SIP response reliability: the INVITE way and the non-INVITE way.  

As you are well aware, what you describe above is how response reliability 
is specified for non-INVITE methods (basically, resend final response every 
time the request arrives).  To now say that for redirection, responses to 
the INVITE should have the same behavior as those for non-INVITEs will open 
up a can of worms.

> documented in bis-05. I am not sure how much we want to say about it, as 
> it is effectively an implementation decision that can be made, rather than 
> a new protocol element. However, since doing stateless responding is 
> important for security (and we do mention that), it might be worth giving 
> more guidance than is there now.

It is better to have a tacit understanding that redirect servers may "eat"
up the ACK -- even though I really do not like this behavior -- so that from 
a UAC's point of view, the INVITE/3xx/ACK completes a transaction.  If 
instead, you spell this behavior in the spec, we will run into interop 
nightmares because invariably there will be an UAC implementation that deems 
the ACK optional for 2xx responses as well.  

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184