Subject: Re: [SIP] proxy protocol conversion

From: [email-masked]
Date: Tue, 20 Jun 2000 16:45:48 +0000

Hi.

I would like to follow up on this.

Let's assume we have two users, which both have clients which only support
UDP.  They have different home proxies, and those proxies are stateful, use
TCP when possible and always insist on being included throughout any call
going through them.

Thus we have this setup with transport:

Client A  -------  UDP -------- Proxy A --------- TCP --------- Proxy B
-------- UDP -------- Client B

User A calls user B, and a call is successfully set up.  Both proxy A and
proxy B have include Record-Route headers in any proxied requests.

Now let us assume that the code implementing the underlying session being
established has a critical bug, and that when client A and B act on the
agreed session description, they both crash violently.  How will the
proxies in-between ever discover that?  After the ACK is sent by client A,
the proxies never hear from the clients again!

How is this handled?

Best regards,
Hörður K

--
Hordur Kvaran <[email-masked]>
Software Developer - OZ.COM
Snorrabraut 54 - 105 Reykjavik - Iceland
Tel: +354 535 0000 - Direct tel: +354 535 0013

Jonathan Rosenberg <[email-masked]>@lists.bell-labs.com on
17.06.2000 06:55:47

Sent by:  [email-masked]

To:   Loita Jahnsson <[email-masked]>
cc:   [email-masked]

Subject:  Re: [SIP] proxy protocol conversion

Loita Jahnsson wrote:
>
> 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?

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.

>
>    * when an outbound proxy receives a UDP package from
>      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.

>
>    * when a proxy is configured to always go through
>      another proxy using TCP, disregarding any transport
>      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.

>
>    * 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)?

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

>    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).

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

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

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 21 Jun 2000 09:45:32 +0100

> Let's assume we have two users, which both have clients which
> only support UDP.  They have different home proxies, and those
> proxies are stateful, use TCP when possible and always insist on
> being included throughout any call going through them.
>
> User A calls user B, and a call is successfully set up.  Both proxy
> A and proxy B have include Record-Route headers in any proxied
> requests.
>
> Now let us assume that the code implementing the underlying session
> being established has a critical bug, and that when client A and B
> act on the agreed session description, they both crash violently.
> How will the proxies in-between ever discover that?  After the ACK
> is sent by client A, the proxies never hear from the clients again!
> 
> How is this handled?

I'm not massively confident that I'm understanding where there's
a problem; is it because you are concerned that the TCP connection
might persist unnecessarily indefinitely?  Else I can't see where
the "proxy protocol conversion" comes in?  I guess the solution
that jumps out at me is to have some sort of timer on a TCP connection,
which causes it to be closed if there's been no activity for some
period of time.

If this is more a Call-Stateful issue, probably the best solution
is for the proxies to mandate use of the "SIP Session Timer"; the
draft on this is available from Henning's site.

HTH,

 - Jo.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Jun 2000 04:11:14 -0400

> which causes it to be closed if there's been no activity for some

Persistence of TCP connections is totally independent of determination
of whether the UAC and UAS are still in the session set up with the
INVITE. Session timer is used exclusively for the latter; how long to
keep a TCP connection open for is a matter of policy. However, I have a
draft pending shortly which discusses some issues with TCP connection
management.

-Jonathan R.