Subject: [Sip] Consequence of destroying INVITE server transaction on 200

From: Robert Sparks <[email-masked]>
Date: Wed, 20 Apr 2005 16:38:54 -0500

This is one of the bigger questions that arose at SIPIT 16.

According to 3261 section 13.3.1.4 and the end of 17.1.1.2,
  endpoints destroy their INVITE transaction the instant they send a 200.
For UDP, the application above is left responsible for retransmitting
that 200 by interacting with the transport directly until an ACK
arrives.

Similarly 17.1.1.2 affects proxies as well (it states this destruction 
is
essential for proper proxy operation, choosing this path to define how
subsequent 200s from other branches are handled).

The problem that arose is that it is not clear from the specification
what to do with a retransmission of the INVITE request that arrives
after that transaction state has been deleted (consider that the first
200 over UDP is lost for instance).

Unless we missed something, a literal read of the spec says this
retransmission will get processed as a new request, possibly
forking again to different places at a proxy (it deleted the thing that
would have dealt with that retransmission), or likely generating a
different final response (with a different To tag) from an endpoint.

I believe the intent was that the application on top of the original
transaction (the endpoint, or the response context in the proxy) 
remember
enough to absorb that retransmission. The spec needs more description
around this so that it is obvious that this retransmission should make 
it to
the part of the application that handled the original request. It needs 
to talk
about. how long this part of the application needs to hang around to 
drain
these retransmissions.

Can anyone see text that we may have missed when discussing
this problem that adds clarity to it. If not, does anyone disagree with
the approach for clarification proposed above.

If the answer to both of those questions is no, I'll enter a bug and 
propose text.

RjS

_______________________________________________
Sip mailing list  https://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, 20 Apr 2005 19:38:33 -0400

inline.

Robert Sparks wrote:

> Similarly 17.1.1.2 affects proxies as well (it states this destruction is

I agree that this is a bug in the spec. I don't recall discussing this 
problem during rfc3261 development and I couldn't find any text in the 
spec about it either.

> transaction (the endpoint, or the response context in the proxy) remember
> about. how long this part of the application needs to hang around to drain
> these retransmissions.

Right. A slightly different way to think about this is that the server 
transaction doesnt actually disappear on a 2xx; but rather, it remains 
in a wait state only to suppress INVITE retransmits. It would still 
transparently pass 2xx from the TU out on the network.

> If the answer to both of those questions is no, I'll enter a bug and 

Please do.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 21 Apr 2005 10:27:53 -0400

>> around this so that it is obvious that this retransmission should 
>> make it to
>> the part of the application that handled the original request. It 
>> needs to talk
Absolutely. This is exactly analogous to FIN_WAIT state in TCP.