Re: [P2PSIP] Choice of STUN peer or TURN peer

"Bruce Lowekamp" <lowekamp@sipeerior.com> Mon, 28 January 2008 16:01 UTC

Return-path: <p2psip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWQ0-0004st-35; Mon, 28 Jan 2008 11:01:08 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWPy-0004rz-Jk for p2psip@ietf.org; Mon, 28 Jan 2008 11:01:06 -0500
Received: from wr-out-0506.google.com ([64.233.184.235]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJWPy-0008LF-8B for p2psip@ietf.org; Mon, 28 Jan 2008 11:01:06 -0500
Received: by wr-out-0506.google.com with SMTP id 68so747484wra.13 for <p2psip@ietf.org>; Mon, 28 Jan 2008 08:01:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=8zoqZoq8ZdKA75V7WkmOJdPKMmgBKLovMmyqo1Ap6sk=; b=sDmG9/WEo32Xluna44oc73B33lmXSsh1IyRKlNwb2R8ZnK7rKw9aenrMFtT0xnQCzwIDzXDZ1N4pR+rThf9qXl5KA5pwCRdUAeX2zLHq+guSdlQiXD7t5q3Gu1FhHwustEwyNz8+byYRjlLJGW1i/zcIZRS7es26PiuLlvYNUpg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Kjp0J/TZk0MmM6mnU5ZWqfjmdxGCrLVJS/LJ7L654jDCyll9LQZO8C2W/XPZt3D+p6YjERneiKbh82AxtOjF4Hi1iyCDwOE+FpSULirucgCalRB6+GkXvf/bbk1YpeiJtlpKPTwlACSyGF77Dh4UaDnDgh5Y39q5faJ75cb4DjM=
Received: by 10.114.77.1 with SMTP id z1mr4260718waa.56.1201536065183; Mon, 28 Jan 2008 08:01:05 -0800 (PST)
Received: by 10.115.19.18 with HTTP; Mon, 28 Jan 2008 08:01:05 -0800 (PST)
Message-ID: <20d2bdfb0801280801s5058a661td76c82985b54918@mail.gmail.com>
Date: Mon, 28 Jan 2008 11:01:05 -0500
From: "Bruce Lowekamp" <lowekamp@sipeerior.com>
To: JiangXingFeng <jiang.x.f@huawei.com>
Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer
In-Reply-To: <001501c86156$04a31ee0$2d09a40a@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <174701c85f78$24a386b0$44a36b80@cisco.com> <001501c86156$04a31ee0$2d09a40a@china.huawei.com>
X-Google-Sender-Auth: c0bd62f88e278cff
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: P2PSIP Mailing List <p2psip@ietf.org>
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Errors-To: p2psip-bounces@ietf.org

Sorry for dropping off the thread for so long...

On 1/27/08, JiangXingFeng <jiang.x.f@huawei.com> wrote:
> > It seems useful to phase this for p2p-sip:  initially, just have
> > p2p-sip nodes advertise their TURN servers if the p2p-sip node
> > is not behind a NAT.
> >

This seems like the best first step.  It also seems likely that
different overlays will have different policies for what defines a
good TURN relay.  Some provider-based overlays might actually have the
provider provision TURN servers, whereas at the other end of the
spectrum are overlays that may deploy nothing and rely entirely on
individuals who have eligible peers.


> > Once we know how to have p2p-sip TURN servers qualify their
> > NAT's p2p-friendlyness, then can have p2p-sip nodes advertise
> > those TURN servers, too.  If we make fast progress on a document
> > that describes the qualification procedure, and running code
> > that shows it works, we should be good to go.  No?
>


This seems like a fairly straightforward application of
nat-behavior-discovery.

> >
> >   TURN client         STUN server          NAT  TURN server
> >        |                   |                |      |
> >  1.    |------give me a TURN address------->|----->|
> >  2.    |                   |<--STUN Request--------|
> >  3.    |                   |-STUN Response->|----->|
> >  4.    |<-----here is your TURN address------------|
> >

If we allow a TURN server to be behind a NAT, then the only change I
would see necessary would that 1 and 4 would have to be routed over
the overlay (a reload tunnel, for example).  But otherwise, the TURN
protocol seems to work as is.  For the purposes of a TURN server, a
NAT having endpoint independent mapping seems to be the only real
requirement on the NAT as long as the two voice endpoints support ICE;
the connectivity checks should take care of any form of filtering the
NAT uses.

Bruce

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip