Subject: [Sip] stateless forwarding UDP->TCP by proxy

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 8 Feb 2006 12:01:22 +0100

Would a proxy be allowed to forward a request transaction statelessly when switching from UDP to TCP (e.g. because the request becomes too big for UDP)?

RFC3261 16.1 states "[...] 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."

However, for the UDP->TCP case it would seem that reliability is ensured because retransmitted requests on UDP would be passed upstream again (over TCP), and eventually trigger a retransmission of the response. This would result in retransmissions over TCP - which the next hop perhaps would not expect - but other than that, are there any problems with this scenario?

Regards,

Jeroen van Bemmel

_______________________________________________
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, 08 Feb 2006 08:04:06 -0500

I think it will work. You'll need to make sure that all requests for the 
same transaction land on the same tcp connection, but this can be done 
statelessly.

-Jonathan R.

Jeroen van Bemmel wrote:
> Would a proxy be allowed to forward a request transaction statelessly 
> when switching from UDP to TCP (e.g. because the request becomes too big 
> for UDP)?
>  
> RFC3261 16.1 states "[...] 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."
>  
> However, for the UDP->TCP case it would seem that reliability is ensured 
> because retransmitted requests on UDP would be passed upstream again 
> (over TCP), and eventually trigger a retransmission of the response. 
> This would result in retransmissions over TCP - which the next hop 
> perhaps would not expect - but other than that, are there any problems 
> with this scenario?
>  
> Regards,
>  
> Jeroen van Bemmel
>  
>  
> 
> 
> ------------------------------------------------------------------------
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   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: "Brett Tate" <[email-masked]>
Date: Wed, 8 Feb 2006 10:22:28 -0500

Unfortunately RFC 3261 removed retrying 3xx-6xx responses over reliable
connections.  Thus such responses might only be sent once over the udp
portion when a 1xx was previously sent.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jonathan Rosenberg
> Sent: Wednesday, February 08, 2006 8:04 AM
> To: Jeroen van Bemmel
> Cc: [email-masked]
> Subject: Re: [Sip] stateless forwarding UDP->TCP by proxy
> 
> 
> > RFC3261 16.1 states "[...] Requests forwarded between 
> different types 
> > of

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 8 Feb 2006 17:55:11 +0100

Brett,

Good point

I suppose this could be a reason to state that when possible, 
implementations should not send any 1xx responses (including 100 Trying) 
before sending a 3xx-6xx response over TCP (or any reliable transport), 
since it may be that some proxy along the line made the transport switch. A 
valid case: INVITE becoming too large due to Via / Record-Route headers. 
Trouble is that INVITE -> ringing -> no answer is a common scenario...

Alternatively, the 1300 byte limit for switching to TCP could be extended 
for proxies (say: 1300 for UAC, 1500 for proxies). Or - third option - UACs 
should use a smaller limit value for INVITEs, say 1000 bytes, and above that 
switch to TCP.

Jeroen

----- Original Message ----- 
From: "Brett Tate" <[email-masked]>
To: "'Jonathan Rosenberg'" <[email-masked]>; "'Jeroen van Bemmel'" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, February 08, 2006 4:22 PM
Subject: RE: [Sip] stateless forwarding UDP->TCP by proxy

---

From: "Thejeswara Reddy.P" <[email-masked]>
Date: Wed, 8 Feb 2006 16:57:43 +0000 (GMT)

I think Proxy has to maintain the state of converted (UDP---> TCP) transports.
  
  So that it will not forward the same UDP request (retransmitted ) over TCP for next hop.

  ---- theja reddy

Jonathan Rosenberg <[email-masked]> wrote:  I think it will work. You'll need to make sure that all requests for the 
same transaction land on the same tcp connection, but this can be done 
statelessly.

-Jonathan R.

				
---------------------------------
 Jiyo cricket on Yahoo! India cricket
Yahoo! Messenger Mobile Stay in touch with your buddies all the time.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 08 Feb 2006 16:32:56 -0500

Ah yes - sorry about that. You're right.

-Jonathan R.

Brett Tate wrote:

>>>Would a proxy be allowed to forward a request transaction 
>>
>>statelessly
>>
>>>when switching from UDP to TCP (e.g. because the request 
>>
>>becomes too big 
>>
>>>for UDP)?
>>> 
>>>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."
>>> 
>>>because retransmitted requests on UDP would be passed 
>>
>>upstream again 
>>
>>>(over TCP), and eventually trigger a retransmission of the 
>>
>>response. 
>>
>>>perhaps would not expect - but other than that, are there 
>>
>>any problems 
>>
>>>with this scenario?
>>> 
>>>Regards,
>>> 
>>>Jeroen van Bemmel
> 
>

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 9 Feb 2006 15:13:06 -0500

It isn't just a problem when switching to use TCP because of message size.

The situation can occur anytime the stateless proxy receives a request over
UDP and proxies it using a reliable transport.

The only way I know to fix problem is to get the community to start retrying
INVITE 3xx-6xx responses over reliable transports again if they are
concerned by the potential problem.

> Behalf Of Jeroen van Bemmel
> Sent: Wednesday, February 08, 2006 11:55 AM
> To: Brett Tate; 'Jonathan Rosenberg'
> Cc: [email-masked]
> > Unfortunately RFC 3261 removed retrying 3xx-6xx responses over 
> > reliable connections.  Thus such responses might only be sent once 
> > over the udp portion when a 1xx was previously sent.
> >

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 10 Feb 2006 08:24:44 +0100

Hi Brett,

I'm sorry but I can't follow the discussion anymore.

So far I understand it is possible that a proxy can switch from UDP to 
TCP if the message size is too big. There I do not see any problems 
because the proxy can put a Via header with TCP transport.

Which I do not understand if a UAC decides to send its request through 
UDP and gets back a TCP response is this not a source of trouble because 
in the Via header stands UDP as transport kind. The client will expect 
on its UDP port the response.

The next point is: Why should only non-successful response have problems 
with the packet size? If the answer is 3xx - 6xx no route set will be 
set and every proxy will remove its Via header which make the size 
smaller. Is there really a reason to switch to TCP?

2xx responses have a Contact header where you have the possiblity to 
signal that you will switch from UDP to TCP. But the UAC could be first 
prepared to use TCP if it evaluates the successful response.

Did I understand everything right?

Thank you in advance

Markus

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 10 Feb 2006 10:59:23 -0500

> Which I do not understand if a UAC decides to send its 
> request through UDP and gets back a TCP response is 
> this not a source of trouble because in the Via header 
> stands UDP as transport kind. The client will expect 

Responses currently must use the same transport used within the request.
And I was not attempting to address this topic.

> The next point is: Why should only non-successful response 
> have problems with the packet size? 

The 1xx and 2xx responses are retried when necessary per rfc3261 and
rfc3262.  However the periodic retrying of 3xx-6xx has been removed by
rfc3261.

> If the answer is 3xx - 6xx no route set will be 
> set and every proxy will remove its Via header which 
> make the size smaller. Is there really a reason to 
> switch to TCP?

Responses must use the same transport used within the request.  This was not
the topic of the thread.  

However to answer your question, responses can be larger than a request
because of the potential for extra headers, extra parameters, and a body
within such responses.

> 2xx responses have a Contact header where you have the 
> possibility to signal that you will switch from UDP to 
> TCP. But the UAC could be first prepared to use TCP if 
> it evaluates the successful response.

I'm not sure that I understand your comment; responses must use the same
transport used within the request.

However since rfc3261 and rfc3262 provides for retrying 1xx and 2xx
responses, there is no issue when the used transport was reliable and the
subsequent transport for PRACK or ACK is non reliable.

> Did I understand everything right?

I was trying to communicate that the mentioned problem concerning stateless
proxies was not unique to situations related to message size. 

The problem can surface anytime a stateless proxy receives an INVITE non
reliably and proxies it over a reliable transport.

In the following example, the 486 and ACK only get sent once over UDP.

A            P                B

INVITE (udp) ->  INVITE (tcp) ->
<- 100 (udp) <-  100 (tcp)
<- 486 (udp) <-  486 (tcp)
ACK (udp)    ->  ACK (tcp)    ->