Subject: [Sip] Stateless proxy and reliable transport

From: "kkuei" <[email-masked]>
Date: Wed, 12 Apr 2006 18:17:46 +0800

Dear all,

This may be a stupid question, but I can't find the answer in RFC3261 and 
archive.

Here is the story:

A <-----> Stateless Proxy <------> Proxy <------->  B

Assume the transport between A and stateless proxy is reliable (TCP).

If A send INVITE to stateless proxy, it will not received 100 provisional 
response. Then, stateless proxy tries to relay it to proxy. If the packet 
dropped.. A will not do retransmite right?? 

Then the transaction will be timeout... Is it the correct behavior??

--
Kevin Kuei

_______________________________________________
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: "kkuei" <[email-masked]>
Date: Wed, 12 Apr 2006 18:21:20 +0800

Sorry, I forgot the say the transport between stateless proxy and proxy is 
unreliable (say, UDP)

--
Kevin Kuei

On Wed, 12 Apr 2006 18:17:46 +0800, kkuei wrote
> Dear all,
> 
> This may be a stupid question, but I can't find the answer in 
> RFC3261 and archive.
> 
> Here is the story:
> 
> If A send INVITE to stateless proxy, it will not received 100 
> provisional response. Then, stateless proxy tries to relay it to 
> proxy. If the packet dropped.. A will not do retransmite right??
> 

--
Kevin Kuei

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 12 Apr 2006 07:45:45 -0400

Questions like this really belong on the Sip-implementors mailing list
[email-masked]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

There is rule against a stateless proxy changing the transport for exactly 
this reason. In section 16.1 of RFC 3261 it says  "Requests forwarded 
between different types of transports where the proxy's TU must take an 
active role in ensuring reliable delivery on one of the transports MUST be 
forwarded transaction statefully."

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[email-masked]

---

From: Dean Willis <[email-masked]>
Date: Wed, 12 Apr 2006 10:08:41 -0500

On Apr 12, 2006, at 5:17 AM, kkuei wrote:

> RFC3261 and
> provisional

A is still responsible for retransmission, whether or not it receives  
a provisional response.

This would be required even if all the proxies were stateful and all  
the links reliable, because there's always a chance that proxy will  
simply drop a request or fail in some other way.

--
Dean

---

From: "kkuei" <[email-masked]>
Date: Thu, 13 Apr 2006 10:36:49 +0800

Hi Dean,

Thanks for your reply. But rfc3261 section 17.1.1.1 said:

INVITE client transaction:
"The request is not retransmitted over reliable transports"

You said:
A responsible for retransmission

Which layer will be responsible for retransmission??

Cheers,

--
Kevin Kuei

On Wed, 12 Apr 2006 10:08:41 -0500, Dean Willis wrote
> A is still responsible for retransmission, whether or not it 
> receives  a provisional response.
> 

--
Kevin Kuei

---

From: Dean Willis <[email-masked]>
Date: Thu, 13 Apr 2006 13:48:51 -0500

> Which layer will be responsible for retransmission??

Theoretically, the application layer above the SIP UA, although I'm  
not sure I'm happy about this.

I suppose it depends somewhat means by retransmitted". I suspect  
"retried" is a better term for the state I'm describing.

If the transport is reliable, there are three possible occurrences  
that get us here:

1) The transport layer returns an error -- generally, something like  
"ICMP host unreachable" or "connection reset by peer".

2) The transport layer is happy, but we never see a response, so  
timer B fires.

3) The keepalive layer finds that the proxy we thought we were  
talking to is not talking to us anymore.

The problem is that there may have been a proxy-discard somewhere, or  
an unreliable link at a "stateless" proxy that dropped the request  
(note that proxies adapting from reliable to unreliable transport  
really have to be at least transaction stateful, but sometimes aren't).

There's a strong argument to be made that we need a fairly aggressive  
use of timer B, followed by "re-execution of the request" in the UA.  
This is especially pertinent if there are multiple possible next-hop  
routes towards the target.

An example of this occurs in sip-outbound, when a UA discovers mid- 
transaction that the route identified by a "flow" has failed, and  
completes the transaction using a separate flow (and related route).  
Following 3261 strictly, we'd have to take the transaction to  
"terminated" state. But we don't, as I understand sip-outbound.

--
Dean

---

From: [email-masked]
Date: Sat, 15 Apr 2006 11:50:44 +0530

Is Stateless Proxy converting the request to UDP from TCP?, is it possible 
?---- as per RFC 3261

"kkuei" <[email-masked]> 
04/13/2006 08:06 AM

To
[email-masked]
cc
[email-masked]
Subject
Re: [Sip] Stateless proxy and reliable transport

Hi Dean,

You said:

Cheers,

--
Kevin Kuei

--
Kevin Kuei

***********************  FSS-Restricted   ***********************

---

From: Dean Willis <[email-masked]>
Date: Thu, 20 Apr 2006 11:17:06 -0500

On Apr 15, 2006, at 1:20 AM, [email-masked] wrote:

>
> Is Stateless Proxy converting the request to UDP from TCP?, is it  
> possible ?---- as per RFC 3261
>

Some people have claimed that it is possible, but I don't see how one  
could get correct behavior. It seems to me that the proxy that is  
converting from TCP to UDP becomes responsible for assuring  
transaction reliability at the UDP layer, which I think makes it at  
least transaction-statefull. Conceivably, one could have a partially  
transaction- statefull proxy that discards the state used for  
reliability on receipt of a provisional response, but why bother?

--
Dean