IETF Logo Mail Archive

Re: [Perc] DTMF in Double

Adam Roach <adam@nostrum.com> Sun, 13 August 2017 21:59 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD551331CF for <perc@ietfa.amsl.com>; Sun, 13 Aug 2017 14:59:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvq2NtK-Dm5V for <perc@ietfa.amsl.com>; Sun, 13 Aug 2017 14:59:17 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A599B1331CE for <perc@ietf.org>; Sun, 13 Aug 2017 14:59:17 -0700 (PDT)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7DLxAx6094203 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 13 Aug 2017 16:59:11 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: Cullen Jennings <fluffy@iii.ca>, perc@ietf.org
Cc: Roni Even <roni.even@huawei.com>
References: <65EF378D-664F-46E3-8853-56E5BB52C83D@iii.ca>
From: Adam Roach <adam@nostrum.com>
Message-ID: <c5b1ec7b-67d9-c4bb-d5dd-92aac96f189d@nostrum.com>
Date: Sun, 13 Aug 2017 16:59:05 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <65EF378D-664F-46E3-8853-56E5BB52C83D@iii.ca>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/J7aKrMocr5NgfVj-nppp9hXAODs>
Subject: Re: [Perc] DTMF in Double
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing <perc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perc>, <mailto:perc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perc/>
List-Post: <mailto:perc@ietf.org>
List-Help: <mailto:perc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perc>, <mailto:perc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Aug 2017 21:59:19 -0000

On 8/13/17 2:16 PM, Cullen Jennings wrote:
> I think Roni had a good point about DTMF can be done with the SIP INFO approach so I plan to add the text do double that says something along the lines of
>
>     When DTMF is sent with [RFC4733], it is end-to-end encrypted and the
>     relay can not read it so it can not be used to control the media
>     relay.  Other out of band methods to control the relay need to can
>     be used instead.  One way to do this is to send DTMF with [RFC6086],
>     which will be sent in the signalling thus allowing the relay to read
>     the DTMF.
>

RFC6086 doesn't define how to send DTMF in the signaling path any more 
than RFC3261, RFC675, or RFC791 do.

3GPP 24.229 does, if you want to cite that. The other two options are 
RFC4730 and "It's 2017 -- don't do that."

/a

v2.23.0 | Report a Bug | By Email