IETF Logo Mail Archive

Re: [rtcweb] Which parts of RFC 4733 are required? (Re: Support DTMF "codec" or expose DTMF in signaling?)

"Ravindran, Parthasarathi" <pravindran@sonusnet.com> Tue, 22 November 2011 12:44 UTC

Return-Path: <pravindran@sonusnet.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B6621F8DF2 for <rtcweb@ietfa.amsl.com>; Tue, 22 Nov 2011 04:44:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.573
X-Spam-Level:
X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxqhSJfBn1tu for <rtcweb@ietfa.amsl.com>; Tue, 22 Nov 2011 04:44:27 -0800 (PST)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id D003C21F8DF1 for <rtcweb@ietf.org>; Tue, 22 Nov 2011 04:44:26 -0800 (PST)
Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pAMCj0sf003671; Tue, 22 Nov 2011 07:45:00 -0500
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Nov 2011 07:43:24 -0500
Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Nov 2011 18:13:42 +0530
Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by inba-hub01.sonusnet.com (10.70.51.86) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 22 Nov 2011 18:13:41 +0530
Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0339.001; Tue, 22 Nov 2011 18:13:41 +0530
From: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>
To: Saul Ibarra Corretge <saul@ag-projects.com>
Thread-Topic: [rtcweb] Which parts of RFC 4733 are required? (Re: Support DTMF "codec" or expose DTMF in signaling?)
Thread-Index: AQHMqDavk1X1jFOE306g9+by8oNJ+JW3Itjg//+60QCAAGDswP//2qyAgADar1CAAIDxgIAAX+/A
Date: Tue, 22 Nov 2011 12:43:41 +0000
Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01CEA70D@inba-mail01.sonusnet.com>
References: <mic312r58213o9qkb9gg0ey5.1321693128138@email.android.com> <4EC89DFA.1070404@alvestrand.no> <271E1940-D50B-4F14-B580-4DF118FA8A58@edvina.net> <CAD5OKxuvnaj3j7gZ6xFGHuxOZgozLWZRczhnb6EfNL7fkq1XKg@mail.gmail.com> <snt0-eas2502C46717F466D0DA42ACC93CA0@phx.gbl> <387F9047F55E8C42850AD6B3A7A03C6C01CEA256@inba-mail01.sonusnet.com> <CALiegf=s1ivzr1nq=MZN_eBeN+WNBatg8MJ9jDuufBAOhVfjyg@mail.gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C01CEA311@inba-mail01.sonusnet.com> <CALiegfkg2kPLnDrem-zerz3nc+YMHKnnuxju+p+66qS79gQn7g@mail.gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C01CEA36D@inba-mail01.sonusnet.com> <4ECA6F53.8020907@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6C01CEA4E1@inba-mail01.sonusnet.com> <FC92CA03-0D1D-48C1-B00D-1EE8E6A33C1C@ag-projects.com>
In-Reply-To: <FC92CA03-0D1D-48C1-B00D-1EE8E6A33C1C@ag-projects.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.70.54.92]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 22 Nov 2011 12:43:42.0150 (UTC) FILETIME=[5D96B660:01CCA914]
Cc: Randell Jesup <randell-ietf@jesup.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Which parts of RFC 4733 are required? (Re: Support DTMF "codec" or expose DTMF in signaling?)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Nov 2011 12:44:27 -0000

Saul,

Please read inline.

Thanks
Partha


>-----Original Message-----
>From: Saul Ibarra Corretge [mailto:saul@ag-projects.com]
>Sent: Tuesday, November 22, 2011 5:48 PM
>To: Ravindran, Parthasarathi
>Cc: Randell Jesup; rtcweb@ietf.org
>Subject: Re: [rtcweb] Which parts of RFC 4733 are required? (Re: Support
>DTMF "codec" or expose DTMF in signaling?)
>
>Hi,
>
>>>
>>> Datastreams (even with all the options being considered) may not be a
>>> good alternative to 4733, per my previous message.
>>
>> <partha> I'm not talking about data channel. My point is to use
>> signaling Mechanism like KPML or INFO DTMF-relay. </partha>
>>
>
>It presents the same problem, no synchronization is guaranteed.

<partha> I have explained in the earlier mail thread that  there is 
no synchronization problem for FedEx use case. The actual text is as follows:

 For FedEx IVR example, the prompt is going to be played in IVR Side and 
digits are collected in WebRTC client. As long as the reliable Mechanism 
exists for DTMF, there is no need of explicit synchronization. 

In case the concern is about how PSTN gateway include DTMF into its media 
Layer, then it is existing current implementation as most of the PSTN 
gateway has the capability to convert signaling into DTMF tones in PSTN 
side. In Fact, I have worked in PSTN gateway which perform multiple 
signaling Based DTMF namely KPML, INFO dtmf-relay, H.245 
(signaling, alphanumeric), Unsolicited NOTIFY. 


In case you have some specific use case where synchronization issues occurs, 
Please explain it.

</partha>



>
>> Even with
>>> synchronization of delivery to a media stream, there's no guarantee
>>> of delivery on-time in a congestion situation.
>> <partha> It is possible for RTP (RFC 4733) packet to be dropped during
>> Congestion but it is not the case with signaling like KPML where
>> request /response is part of the mechanism. So, signaling mechanism is
>> preferred Over RTP.  </partha>
>>
>
>Which can't be done in a timely manner. Yo may press the button, but it
>may be sent too late due to congestion issues. I think this is Randell's
>point.
>

<partha> How come RFC 4733 DTMF will pass across whereas signaling DTMF will not
Pass across during congestion? It is not possible. </partha>

>On to something else: some mails ago Olle raised a security concern. I
>may have missed some mails, so where are we on the SRTP requirements? If
>we'll allow for non-secure sessions (plain RTP) we'd need to fallback to
>RFC2833. On RFC4733, Appendix A:
>
>"The Security Considerations section is updated to mention the
>requirement for protection of integrity.  More importantly, it makes
>implementation of SRTP [7] mandatory for compliant implementations,
>without specifying a mandatory-to-implement method of key distribution."
>
>What should we do about it?
>
<partha> Please note that WebRTC mandates SRTP. I didn't see any closure here
as it is special case for key distribution (DTLS vs SDES). I noticed the mail 
thread on this
http://www.ietf.org/mail-archive/web/rtcweb/current/msg02967.html. 
</partha>

>--
>Saúl Ibarra Corretgé
>AG Projects
>
>
>
>

v2.23.0 | Report a Bug | By Email