Subject: [midcom] pre-midcom - How does TURN work?

From: Steve Davies <[email-masked]>
Date: Tue, 27 Nov 2001 18:19:28 -0000

Jonathan, Joel, Christian and Rohan,

Please explain how you expect the following to work within TURN: 

* How does a client register with a central registrar behind the TURN
server. The ALLOCATE method obtains a public transport address to represent
the client, but how does the registration request get forwarded from the
TURN server to the central registrar?

* When a call exists between 2 clients that are behind 2 different TURN
servers, there appears to be a media deadlock. It appears from the
description, that both TURN servers are waiting for the other to send them
media before each of them knows where to send media to. Is this
interpretation correct?

* What is your solution for RTP port pairing? 

* How do you expect to prevent NATs from timing out on both the 'in-bound
signaling' connection and for media in the presence of silence suppression? 

It would also really be nice to see the detail of a proper call flow - SIP
or H.323 will suffice. Until we see how TURN is expected to work it is
difficult to make a like-for-like comparison with FANTOM and have a proper
debate on the pros and cons of various methods.

Thanks. 

Steve

---

From: Steve Davies <[email-masked]>
Date: Tue, 27 Nov 2001 23:47:38 -0000

All,

By way of clarification of the first question, when I say 'behind' I mean
the central registrar is on the public side of the TURN Server, viz: TURN
Client<->NAT<->TURN Server<->Central Registrar<->etc. So the client must go
through TURN to get to the registrar - a typical managed service deployment.

Hopefully the other questions are clear.

Steve

-----Original Message-----
From: Steve Davies [mailto:[email-masked]]
Sent: 27 November 2001 18:19
To: [email-masked]'; [email-masked]'; 'Christian Huitema';
[email-masked]'
Cc: [email-masked]
Subject: [midcom] pre-midcom - How does TURN work?

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 27 Nov 2001 18:14:14 -0800

> MGCP and H.323 both use TCP, so they are likewise OK for
> signaling.

Unfortunately, H.323 explicitely specifies TCP ports (as well as the IP
address)
to be used for signalling.

Also, to make things worst, the H.245 TCP channel is specified dynamically
(IP address and port) in H.225.0 at every call. Either end can specify it,
so
it makes NAT traversal pretty difficult. Unless you use H.245 tunnelling.

---

From: Steve Davies <[email-masked]>
Date: Fri, 30 Nov 2001 14:48:32 -0000

Rohan, 

Thanks for this clarification. This is what I supposed, but I couldn't
deduce it from the text of TURN. In fact, I had falsely assumed that in
comparing TURN with FANTOM I could take TURN in isolation. From your reply,
am I now correct in infering that for your solution to work the following
steps would need to be implemented:

* a UA would implement STUN to determine what type of NAT it is behind
* if it is behind a symmetric NAT then it would implement TCP signaling
instead of UDP
* furthermore the TCP connection is a permanent connection to a SIP Proxy
* if it is behind a symmetric NAT the UA would to be programmed with the NAT
timeout interval
* A public SIP proxy (to which the permanent TCP connection is made) has to
be in the call signalling path (no direct UA to UA calls)
* The public SIP proxy must also use TCP signalling and ignore any tranport
address registered by the UA
* The UA must implement symmetric passive RTP and signal the capability in
SIP. When the UA makes a call, it must authenticate itself with a TURN
server and then ALLOCATE a couple of transport addresses on that TURN
server. The addresses returned are sent to the destination UA. The
orginating UA has to wait to receive RTP/RTCP packets via the TURN server
before it can transmit (because its TURN server's routing table isn't
complete) and then it must ignore the transport addresses sent by the
destination UA, instead transmitting media (RTP and RTCP) via its TURN
server. When the UA receives a call, it must transmit media first before it
can be received and it must transmit to the orginating's TURN server - not
via its own TURN server.
* Both UAs must either turn off silence supression (bandwith wasteful)or
periodically send NAT keep-alives
* Call clearing must be via the public SIP proxy 

Steve

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: 28 November 2001 01:28
To: Steve Davies
Cc: [email-masked]'; [email-masked]'; 'Christian Huitema';
[email-masked]'; [email-masked]
Subject: RE: [midcom] pre-midcom - How does TURN work?

---- Original message ----
>Date: Tue, 27 Nov 2001 23:47:38 -0000
>From: Steve Davies <[email-masked]>  
>Subject: RE: [midcom] pre-midcom - How does TURN work?  
>To: "[email-masked]'" <[email-masked]>,
"[email-masked]'" <[email-masked]>, "'Christian
Huitema'"<[email-masked]>,
"[email-masked]'" <[email-masked]>
>TURN server to the central registrar?

There is no need to use TURN to communicate with a SIP Server.
 SIP over TCP or TLS works fine as specified in bis.  SIP over
UDP  must use the rport Via parameter specified in
draft-ietf-sip-nat-00.txt

>media before each of them knows where to send media to. Is this

A user originating an INVITE using a TURN server should
represent that they can use symmetric RTP in passive mode. 
When a user behind a symmetric NAT receives an INVITE offering
this, it does not use TURN, it instead sends its media to the
addresses advertised in SDP (the sender's TURN server).

>* What is your solution for RTP port pairing?

This is an area where we need to write a concrete proposal. 
We had some discussions about this when STUN/TURN where part
of the same proposal, but we never closed on a syntax. 
Basically the approach would involve including a parameter in
the first Allocate request to hold the next address for a
short period of time.  The second request would contain some
information from the previous request (for example the next
expected MAPPED-ADDRESS parameter).
 
>* How do you expect to prevent NATs from timing out on both
the 'in-bound signaling' connection

either use TCP/TLS, or send a sacrifice packet periodically to
keep the mapping fresh.  This sacrifice could be an OPTIONS
with max-forwards of 0, a PING as in the Nortel proposal, etc.

>and for media in the presence of silence suppression?

endpoints should send empty RTP packets periodically if no RTP
is  sent.  likewise with RTCP announcements.
 
>debate on the pros and cons of various methods.

Agreed.

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 30 Nov 2001 08:22:27 -0800

Steve,

Some clarifications below...

At 06:48 AM 11/30/01 , Steve Davies wrote:

>comparing TURN with FANTOM I could take TURN in isolation. From your 
>reply, am I now correct in infering that for your solution to work the 
>following steps would need to be implemented:
>

yes

>* furthermore the TCP connection is a permanent connection to a SIP Proxy

no,  either the client must use TCP, or UDP with the rport parameter and 
keep this mapping alive.

>* if it is behind a symmetric NAT the UA would to be programmed with the 
>NAT timeout interval

fyi: this can be detected through STUN.   in the TCP signaling case, you 
only need to keep your RTP/RTCP bindings fresh (much less of a burden).

>* A public SIP proxy (to which the permanent TCP connection is made) has 
>to be in the call signalling path (no direct UA to UA calls)

no,  the public SIP proxy merely provide a publicly accesible point for 
receiving requests.  outbound requests MAY go direct as long as the target 
SIP UA is not itself behind a (different) NAT.

>* The public SIP proxy must also use TCP signalling and ignore any 
>tranport address registered by the UA

no, see above.  the connection to the proxy can be TCP or persistent UDP.

>server. When the UA receives a call, it must transmit media first before 
>it can be received and it must transmit to the orginating's TURN server - 
>not via its own TURN server.

in the case of a symmetric NAT this is true.  In the case of the other 
types of NATs you can send RTP/RTCP directly.

>periodically send NAT keep-alives

In practice it is sufficient to send an empty RTP packet periodically if 
vad is on.

>* Call clearing must be via the public SIP proxy

same comment applies as above on direct signaling

thanks,
-rohan

>From: Rohan Mahy [<mailto:[email-masked]>mailto:[email-masked]]
> >From: Steve Davies 
> [<mailto:[email-masked]>mailto:[email-masked]]

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom