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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 6 Nov 2001 02:13:52 -0500

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 1:49 AM
> To: Jonathan Rosenberg
> Cc: 'Vijay Gurbani'; Dorgham Sisalem; [email-masked]
> Subject: Re: [Sip] RE: [Sipping] RE: [Sip-implementors] 4xx 
> by stateless
> proxy
> 
> 
> 
> 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...

What, SIP isn't complicated enough for you??? I see *zero* value in making
this ridiculous special case exception.

-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 09:43:29 +0200

Hi,

>>it in the first place???? Why not making it optional? And, if the client doesn't

My proposal makes the CLIENT behaviour a little more complicated, since
it would have to make a decission (based on some header value) if to
send an ACK or not. But, we would not send messages on the network that
nobody needs, which one could also argue is a "ridiculous" thing to
do...

Your proposal (or whoever came up with it) makes the SERVER behaviour
more complicated.

FIRST, the server has different logic depending on if the final response
is stateless or not - in some cases it will re-transit the final
response and wait for ACK, and in some cases it won't. No, in a "pure"
stateless server this is not be a big problem, if it ALWAYS sends
stateless final responses.

SECOND, the server has different logic depending on if it sends 1xx or
not. IF the server sends 1xx, the client will STOP re-transmitting the
INVITE. Then, when the server sends the final response, HOW will it know
that the client really will receive it???? The client does NOT
re-transmit the INVITE, and the server does NOT retransmit the final
response... The client will never receive the final response, and when
the C timer expires (or when the caller hangs up) the client will send
CANCEL/BYE - a "long" time (we are NOT talking about a race condition
here) after the server sent the final response. Is that ridiculous, or
what?

Regards,

Christer Holmberg
Ericsson Finland