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

From: Rohan Mahy <[email-masked]>
Date: Tue, 27 Nov 2001 17:27:31 -0800

---- 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]>
>Cc: [email-masked]
>
>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?
>
>
>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?

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

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

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

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

Agreed.

thanks,
-rohan

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

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 28 Nov 2001 08:48:50 -0500

> addresses advertised in SDP (the sender's TURN server).
Why would you need to use passive RTP at all? A client uses TURN to allocate
an address on an RTP relay. It puts that allocated address in its SDP. As
long as the client sent the TURN request out the UDP port it wants to
receive RTP on, the TURN relay will send any packets arriving at the
allocated address to the client's RTP port. The client initiated the
outbound "connection" with the TURN request, therefore the firewall/NAT will
allow packets back from the TURN port. The packets outbound from the client
don't need to go through the relay (do they?).

I don't see any deadlock at all. I don't even see a need for passive RTP or
symmetric RTP. Endpoints can send the RTP to the address advertised in the
SDP. If that address is one allocated on a TURN relay, it will be forwarded
to the real endpoint. Am I missing something?