Re: [midcom] updated TURN draft

Marc Petit-Huguenin <> Tue, 02 August 2005 12:53 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1DzwGU-0003pC-Qx; Tue, 02 Aug 2005 08:53:02 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1DzwGQ-0003lB-SD for; Tue, 02 Aug 2005 08:53:00 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id IAA16348 for <>; Tue, 2 Aug 2005 08:52:57 -0400 (EDT)
Received: from [] ( by with esmtp (Exim 4.43) id 1Dzwmu-0006IM-29 for; Tue, 02 Aug 2005 09:26:33 -0400
Received: by (Postfix, from userid 1006) id 537752A181B3; Tue, 2 Aug 2005 05:52:54 -0700 (PDT)
Received: from [] (localhost []) by (Postfix) with ESMTP id C7A442A18199; Tue, 2 Aug 2005 05:52:49 -0700 (PDT)
Message-ID: <>
Date: Tue, 02 Aug 2005 05:52:49 -0700
From: Marc Petit-Huguenin <>
User-Agent: Debian Thunderbird 1.0.2 (X11/20050611)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <>
Subject: Re: [midcom] updated TURN draft
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit
Cc: Midcom <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Hi Jonathan,

Let say that a SIP client sends an Offer with a TURN Derived Transport
Address in the m/c line to a second endpoint. The second endpoint,
according to RFC 3264, "MAY send media immediately.", but the RTP
packets will be discarded because there is no permission for this source
address. The Offerer will be able to add a permission only after
receiving the Answer, so RTP packets will be lost. If it is an audio
session that is established, this means losing partially or completely
the first word said by the user of the called party.

Jonathan Rosenberg wrote:
> Folks,
> I did an update to the turn spec. I goofed on the I-D boilerplate, so
> there is a good chance it won't make it into the repository, in which
> case I'll submit right after ietf. Either way, you can pick up the
> update draft here:
> There are many changes from the previous version, addressing most of the
> comments and concerns I have received privately and on the list. The
> comment on the list I did not resolve yet is how the server can
> differentiate TLS vs. regular TCP connections, the former used for
> shared secret requests, the latter for allocate.

Marc Petit-Huguenin

midcom mailing list