IETF Logo Mail Archive

Re: [Perc] DTMF in Double

Cullen Jennings <fluffy@iii.ca> Tue, 15 August 2017 17:21 UTC

Return-Path: <fluffy@iii.ca>
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 704581321CB for <perc@ietfa.amsl.com>; Tue, 15 Aug 2017 10:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.699
X-Spam-Level:
X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 HfZDe5Zhfh-u for <perc@ietfa.amsl.com>; Tue, 15 Aug 2017 10:21:41 -0700 (PDT)
Received: from smtp125.iad3a.emailsrvr.com (smtp125.iad3a.emailsrvr.com [173.203.187.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6704D132143 for <perc@ietf.org>; Tue, 15 Aug 2017 10:21:41 -0700 (PDT)
Received: from smtp32.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id AD38C5A18; Tue, 15 Aug 2017 13:21:38 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp32.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id BB6865C3A; Tue, 15 Aug 2017 13:21:36 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.85.165.130] ([UNAVAILABLE]. [173.38.117.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Tue, 15 Aug 2017 13:21:38 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_BC46332B-4CCB-4FB4-A030-2C648258AA9E"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD7FD189@DGGEMM506-MBX.china.huawei.com>
Date: Tue, 15 Aug 2017 10:21:39 -0700
Cc: Adam Roach <adam@nostrum.com>, "perc@ietf.org" <perc@ietf.org>
Message-Id: <C3AA87FE-CC50-422D-89F7-0ABF92C50D72@iii.ca>
References: <65EF378D-664F-46E3-8853-56E5BB52C83D@iii.ca> <c5b1ec7b-67d9-c4bb-d5dd-92aac96f189d@nostrum.com> <6E58094ECC8D8344914996DAD28F1CCD7FD189@DGGEMM506-MBX.china.huawei.com>
To: Roni Even <roni.even@huawei.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/zjqVvFLO7VpncNHPdcGJmmm8ZfI>
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: Tue, 15 Aug 2017 17:21:44 -0000

I have no strong opinion if we should add this to the draft or not. When I read it written up, It seems way outside the scope of double and more like something that would be at a system level. But the PR if we want to adopt it is at 

https://github.com/ietf/perc-wg/pull/130 <https://github.com/ietf/perc-wg/pull/130>



> On Aug 13, 2017, at 10:28 PM, Roni Even <roni.even@huawei.com> wrote:
> 
> Hi Adan,
> Yes these are the two options. 
> I think that the important thing here is to caution that DTMF may be used for conference control and if encrypted end to end there need to be some conference level way to receive input from the conference participants (RFC4730, 3gpp 24.229) or having a media server that MUST have the end to end keys..
> 
> DTMF can be used for conference join(MD?), for routing callers to the right agent in call centers, for input of information during the call (E2E?),.... 
> The first example may be relevant to the MD while the third is in general end to end and DTMF must be encrypted.
> 
> Roni
> 
> 
> 
> ----Original Message-----
>> From: Adam Roach [mailto:adam@nostrum.com]
>> Sent: יום ב 14 אוגוסט 2017 00:59
>> To: Cullen Jennings; perc@ietf.org
>> Cc: Roni Even
>> Subject: Re: [Perc] DTMF in Double
>> 
>> 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