Subject: [SIP] proxy protocol conversion

From: Loita Jahnsson <[email-masked]>
Date: Thu, 15 Jun 2000 12:52:29 +0200

Hi,

   I kind of new in SIP design and have a couple of
   basic questions regarding proxy protocol conversion.

   Assuming that "proxy protocol conversion" means
   something like this:  

   ---transport-1--> proxy ----transport-2-->

   For which cases are protocol conversion applicable
   in a proxy:

   * when the proxy adds more data to the message, so it 
     cannot be stored within a UDP package when proxying 
     the message?

   * when an outbound proxy receives a UDP package from
     a UAC, stating transport=tcp in the Request-URI?

   * when a proxy is configured to always go through
     another proxy using TCP, disregarding any transport   
     parameters in the SIP message?

   * when a proxy has one client which only knowns UDP
     on one side and a client who only knows TCP on the
     other (ie the attempt to contact the called client
     with UDP fails)?

   * ... ?

   Which of those (if applicable) scenarios was tested
   at the 4th bakeoff?

   If "proxy protocol conversions" refers to scenarios
   like the ones mentioned above, what is it called when 
   you need to do this:

   caller-client   ----request, transport1 ----> server
   
   caller-client   <-- response, transport2 ---- same server :)

   (For example if the response for some reason would be
   bigger than max UDP size).

   Regards,

      Loita Jahnsson

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Neil Deason <[email-masked]>
Date: Fri, 16 Jun 2000 09:31:55 +0100

>    Which of those (if applicable) scenarios was tested

Unless I missed it "proxy protocol conversion" is not a term 
defined within the RFC. However the classification system 
for the 4th bakeoff did include the ability for a proxy to do 
UDP to TCP, and vice versa, conversion. AFAIK this simply means
the proxy accepts a SIP message on one of the protocols and 
proxies it on using the other, for whatever reason. I know 
we did this in the advanced scenario testing, where the reason 
was that our proxy was configured to use TCP to contact the 
next downstream proxy.

>    bigger than max UDP size).

Again I don't know of a specific term for this behaviour within 
the RFC.

hth,
Neil.
-- 
Ubiquity Software Corporation, UK          
http://www.ubiquity.net

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Jun 2000 02:55:47 -0400

>      cannot be stored within a UDP package when proxying

Generally, determination of the transport to use for outgoing requests
will be driven by preferences set in the SRV records. In this case, they
would not be dependent on a change in size of the message. Normal SIP
procesing of a message will normally not make it much bigger. In any
case, the maximum UDP size is 64k, which you are unlikely to ever see in
SIP.

>      a UAC, stating transport=tcp in the Request-URI?

Yes, in this case the protocol goes out TCP. This is spelled out (along
with the above) in Section 1.4.2 of the bis draft. This section applies
independnt of the protocol the request came in on, so it may result in
a  "conversion" if the outgoing protocol selected was different from the
incoming.

>      parameters in the SIP message?

You can always do that, although its not specified to work this way.
You'll run into troubles if the next hop doesn't support that protocol.

>      other (ie the attempt to contact the called client

This would be determined through transport parameters in registered
Contacts, so conversion might take place here, yes.

>    bigger than max UDP size).

This is not supported. You could try to do it by putting a different
transport in the Via header than the one you actually used, but I don't
recommend doing that, since its unlikely to work. In any case, it sounds
like  you want the server to dynamically change the tranpsort for the
response if the response comes in and its big; having the client set the
protocol in the Via won't help that. 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com