Subject: Re: [rtcweb] Support DTMF "codec" or expose DTMF in signaling? (Re: DTMF usecase before DTMF API)

From: "Hutton, Andrew" <[email-masked]>
Date: Sat, 19 Nov 2011 09:56:28 +0100

Hi,

I think implementing RFC 4733 in RTCWEB enabled browsers is a must have requirement. It is no big deal to implement is absolutely needed when implementing any interworking with existing media gateways.

Remember RTCWEB is a framework and if your app does not need RFC 4733 then there is no need to use it.

We are only talking about a few lines of code and a simple API lets just do it and move on.

Regards
Andy

Christer Holmberg <[email-masked]> wrote:

Hi,

3GPP has defined a simple DTMF Info Package, some time ago.

I don't see it in the IANA Info Package registry, though, so I will look into that.

However, the Info Package defininion can be found in 3GPP TS 24.449, Annex P.

Regards,

Christer

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Iñaki Baz Castillo
> Sent: 18. marraskuuta 2011 20:58
> To: Hadriel Kaplan
> Cc: <[email-masked]>
> Subject: Re: [rtcweb] Support DTMF "codec" or expose DTMF in
> signaling? (Re: DTMF usecase before DTMF API)
>
> 2011/11/18 Hadriel Kaplan <[email-masked]>:
> > Unfortunately draft-kaplan-dispatch-info-dtmf-package will never
> > become a standard.  I presented it a couple IETF meetings
> ago, and was
> > basically told to go away and never bring it back to the IETF.
> > (despite the fact it was the main use-case and motivation
> for creating
> > INFO packages to begin with)
>
> Opss... then, why do we need the "SIP INFO Method and Package
> Framework"? just for having a generic "framework"? for nothing?
> It's hard to believe :(
>
>
>
> > We can't choose whether to support DTMF in signaling or
> not, because
> >it's possible to do it even right now today on any browser,
> without any
> >changes whatsoever
>
> But what is the real DTMF alternative in the signaling plane?
> using INFO as so many devices do? such usage has drawbacks,
> those DTMF's are not negotiated and so.
>
> Or do you mean SIP KPML (the most exotic and complex
> mechanism for sending simple DTMF's)? I'm pretty sure that
> 99% of existing SIP devices do not implement KPML (does it
> really mean that a PSTN GW should subscribe to any peer fom
> which it receives an INVITE?? it sounds really annoying IMHO.
>
>
> > So if it's not too hard to add, it would be great to
> support RFC 4733 as well, so we can let the web-app provider
> work with even more non-WebRTC devices.  And we've been told
> it shouldn't be too hard to add, so why do you care?  If you
> don't want to use it in your web-app, don't.
>
> I'm not 100% opposed to implementing RFC 4733 in WebRTC. But
> AFAIK, instead of creating a cool API, the only worry is
> about implementing all the requirements of SIP protocol (and others).
>
> --
> Iñaki Baz Castillo
> <[email-masked]>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 20 Nov 2011 07:28:10 +0100

The message below caused me to spend a little time reading RFC 4733's 49 
pages.

> We are only talking about a few lines of code and a simple API lets just do it and move on.
It's a rich standard, including:
- Support for length-encoded events, with the ability to increase the 
length of an event after it is signalled, and to convert it into an 
event of "valid until stopped" nature if it passes 8 seconds long
- Support for sending tones as redundant audio coding (RFC 2198) as one 
option (it's not clear to me what exactly the other option is)
- Support for declaring events to be "states" and "non-states" (but 
never seem to actually indicate whether DTMF tones are "states" or not)
- Support for sending tones as frequency specifications, allowing an 
unlimited combination of any sine waves that have frequencies in Hz 
divisible by 3 (so you can play polytonic music, but it will be badly 
tuned at higher frequencies)
- A rich vocabulary to describe playing out incoming telephony events 
and tones

I'm sure I missed something in the list.

So - question for all you RFC 4733 coders out there:

If we implement 4733, what are we implementing?

- What events do we support? The 16 DTMF events only, or more? (the last 
assignment from this 256-value space is 211 .... there are a few other 
events)
- How do we send the events? Payload switch on the audio SSRC, separate 
SSRC in the same RTP session, telephone-event in a separate RTP session, 
redundant audio coding in the same RTP session, redundant audio coding 
in a separate RTP session, other?
- Can I safely assume that a tone is not a state?
- Can I safely ignore playout of incoming telephone events?

It seems to me to be slightly more than "a few lines of code", no matter 
how we profile the underlying specification (albeit likely shorter than 
the line count of the messages on the subject). And I do not love having 
to profile....

                    Harald

---

From: "Hutton, Andrew" <[email-masked]>
Date: Sun, 20 Nov 2011 11:56:45 +0100

Hi,

I was of course too quick to say it was just a few lines of code but compared to the overall RTCWEB problem supporting DTMF tones I hope would not be a significant issue.

Supporting only the 16 named DTMF events should be sufficient and I personally don't see any requirement for Section 4 (Telephony Tones). 

Whether you can ignore "Playing Out" tones then probably you can I am sure somebody will ask for the API to include reporting of DTMF events received but I would see this as a secondary requirement to generating events.

I understand that profiles are not desirable and cause more work but having just scanned RFC 4733 again then probably a RFC 4733 profile for RTCWeb would be needed.

Regards
Andy

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Harald Alvestrand
> Sent: 20 November 2011 14:28
> To: [email-masked]
> Subject: [rtcweb] Which parts of RFC 4733 are required? (Re: Support
> DTMF "codec" or expose DTMF in signaling?)
> 
> > I think implementing RFC 4733 in RTCWEB enabled browsers is a must
> have requirement. It is no big deal to implement is absolutely needed
> when implementing any interworking with existing media gateways.
> >

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 20 Nov 2011 13:12:20 +0100

I've spent countless of hours the last six months in Asterisk's DTMF code, debugging and testing with a large number of devices and providers. This is limited to the DTMF button events, excluding all of the extra functions in RFC 4733. It's not easy to get this right and there are tons of different implementations out there. Sonus gateways has traditionally given us a lot of issues with an implementation that is different from everyone else. (Check http://www.google.com/search?client=safari&rls=en&q=asterisk+dtmf+sonus&ie=UTF-8&oe=UTF-8 for more information).

The questions you ask are relevant and parsed differently in implementations. Some just stop sending the audio codec while transmitting DTMF, some send it in the same RTP stream, some send comfort noice in the audio stream while sending DTMF in another stream - without negotiating comfort noice. It's a mess. Thinking about it, we should test this at SIPit events.

Apart from the PSTN-gateway usecase - do we need DTMF tones at all? Isn't this a PSTN legacy thing? Is there ANY browser based app that needs to RECEIVE dtmf?

Can apps use the data channel to signal DTMF in the PSTN use case and have the gateway produce the tones? I guess it's not hard to produce a web-based keypad for pressing buttons and sending some sort of signal across the data channel.

If SRTP is not mandated to use, I think DTMF clearly is out of the picture as it opens huge security holes when accessing the PSTN. People will call banks and other services with account numbers and pins.

I think I have said this before: let's keep old PSTN features like DTMF and early media out of scope. 

/O

---

From: Roman Shpount <[email-masked]>
Date: Sun, 20 Nov 2011 08:53:13 -0500

> The message below caused me to spend a little time reading RFC 4733's 49

RFC 4733/ RFC 2833 is historically one of the more misguided VoIP related
RFCs.

I think the whole section 4 there is provided for entertainment value only.
It defines a number of things that nobody needs, but does not allow
encoding of commonly used telephony tones. I don't think I've ever seen
anything that either transmits or can receive this.

Support for anything except DTMF tones is extremely rare. Since we can
specify what events are supported in SDP (events 0-15), we can limit WebRTC
support to DTMF tones only. There are use cases for other events, such as
ANS tones, but they typically have something to do with faxes and modems
which WebRTC does not need to support.

Length encoded events and their continuation are simple enough to code. You
typically do not need events that are longer then 8 seconds and we can put
a restriction on WebRTC to improve interoperability with RFC 2833 end
points which do not support this. DTMF events are not states and cannot
last forever.

DTMF events should be send using the same SSRC. Even though it is not
specified in RFC, you are best of to send RFC 4733 OR in-band audio for any
time stamp range. When RFC 4733 event is sent, audio should be stopped. A
few devices, like Sonus gateways have problems with it otherwise. This will
also make implementation simpler, since in this case there is no need to
generate DTMF tones inband. These inband tones are useless anyway since
they cannot be properly transmitted over anything except G.711 (and may be
few other codecs such as BV).

RFC 4733 already provides some redundancy in DTMF event transmission (end
of DTMF tone is replicated several times). This is duplicated by "user
side" redundancy, since if user gets an invalid selection response from
IVR, they will typically re-enter. Because of this, not additional
redundancy support is needed (and since this is mostly for interop with
existing gateway is not supported).

Due to the wonderful symmetry of offer/answer, if WebRTC will indicate
support for sending RFC 4733 tones, it will get those tones from the remote
gateways. Even if the tones are not expected, since some degree of talk off
in gateway DTMF detector is expected.  Here comes another issue with RFC
4733 -- it redefines the RTP timestamp to indicate the beginning of tone
instead of time the packet was generated. This normally means that extra
care needs to be taken when RTCP is generated from these packets, and they
should be processed separately from the normal jitter buffer. If RFC 4733
processed using normal RTCP routines, they will artificially increase
reported jitter. Apart from handling these packets properly for RTCP
generation, incoming DTMF can probably be ignored, especially if WebRTC
will provide a media synchronized data channel.

After all of this said and done, providing RFC 4733 support is not as bad
as it looks. This is probably a few hundreds lines of code. Some end points
(like an everybody's favorite open source PBX) will not work with anything
you will provide out of the box, but they would typically fix things at
some point. Big gateway and SBC manufacturers (RFC 4733 DTMF is often
inserted by SBC) are fairly stable, and if you are using same SSRC for
audio and DTMF, consistent time stamps and sequence numbers, transmit audio
or DTMF at even given time will work with your code with no issue. As far
as I know code that Google is using to build WebRTC already supports DTMF
transmission.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Sun, 20 Nov 2011 10:59:18 -0500

On Sun, Nov 20, 2011 at 7:12 AM, Olle E. Johansson <[email-masked]> wrote:

> I've spent countless of hours the last six months in Asterisk's DTMF code,
> debugging and testing with a large number of devices and providers. This is
> limited to the DTMF button events, excluding all of the extra functions in
> RFC 4733. It's not easy to get this right and there are tons of different
> implementations out there. Sonus gateways has traditionally given us a lot
> of issues with an implementation that is different from everyone else.
> (Check
> http://www.google.com/search?client=safari&rls=en&q=asterisk+dtmf+sonus&ie=UTF-8&oe=UTF-8for more information).
>
>
As far as I know this was mostly an Asterisk problem. I do believe that
Asterisk is a rather bad example of how DTMF support should be implemented,
since it had so many issues for so many years. Keep in mind that at the
same time practically every phone, softphone and gateway on the market
supports RFC 4733 and they do not typically have interop problems.

> Can apps use the data channel to signal DTMF in the PSTN use case and have
> the gateway produce the tones? I guess it's not hard to produce a web-based
> keypad for pressing buttons and sending some sort of signal across the data
> channel.
>
>
For this to work we need to define a data channel that is time synchronized
with media, otherwise all the applications where you need to record
something and press DTMF digit at the end, will break. RFC 4733 is here. It
is well understood. It is supported by almost any voip device. Support for
required functionality (send-only DTMF digits) is a few hundred lines of
code at most. I think there is good enough use case to add this, if not for
any other reason as to simplify the interop with existing equipment.

If SRTP is not mandated to use, I think DTMF clearly is out of the picture
> as it opens huge security holes when accessing the PSTN. People will call
> banks and other services with account numbers and pins.
>
>
I think this is the wrong argument. Almost all current commercial VoIP is
not secure. All the services like Vonage or Comcast are using RFC 4733
without SRTP. Traditional PSTN calls are very easy to intercept. None of
this caused an issue. Since everyone agrees that SRTP is a must to
implement, at least WebRTC would be able to support secure communications
for anything that requires privacy, including PSTN interconnect. The fact
that a call can be established to a non-secure application should not
prevent all of the applications from using DTMF. Otherwise the next step
would be a requirement for WebRTC to detect that the browser is located in
public location where other people can overheard the call and block all the
calling functionality in such case.

_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Sun, 20 Nov 2011 14:33:23 -0500

On Sun, Nov 20, 2011 at 1:28 AM, Harald Alvestrand <[email-masked]>wrote:

>> I think implementing RFC 4733 in RTCWEB enabled browsers is a must have
>> requirement. It is no big deal to implement is absolutely needed when
>> implementing any interworking with existing media gateways.
>>
> length of an event after it is signalled, and to convert it into an event
> of "valid until stopped" nature if it passes 8 seconds long
> - Support for declaring events to be "states" and "non-states" (but never
> seem to actually indicate whether DTMF tones are "states" or not)
> divisible by 3 (so you can play polytonic music, but it will be badly tuned
> at higher frequencies)
> - A rich vocabulary to describe playing out incoming telephony events and
> tones
>
> redundant audio coding in the same RTP session, redundant audio coding in a
> separate RTP session, other?

Let me take a stab at a set of baseline (i.e. v1) requirements. This is not
everything in RFC 4733, but enough to satisfy the needs of 99% of
applications, and something that can be implemented easily. The general
thinking here is "what are existing phones capable of?"
- 16 DTMF tones
- Sent as telephone-event using the same SSRC as audio
- Optional local playout of sent tones (i.e. playout can be disabled if
desired)

My current proposal for the API for this is:

*void sendDTMF(in DOMString tones)*
*
*
- where |tones| consists of 0-9, '#', '*', A-D, and ','
- default duration is 100 ms, inter-digit pause is 50 ms
- ',' adds an additional 50 ms pause
- if absolutely necessary, we can add an optional |duration| argument,
which would allow the duration to be increased

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 20 Nov 2011 12:09:12 -0800

[BA] I do  believe that it should be possible to protect DTMF with SRTP.  PSTN gateways typically support SDES and not DTLS/SRTP, so If there is a desire to support SRTP with DTMF to a PSTN gateway, then this will imply support for SDES as a keying mechanism.

> I think this is the wrong argument. Almost all current commercial VoIP is not secure. All the services like Vonage or Comcast are using RFC 4733 without SRTP. Traditional PSTN calls are very easy to intercept. None of this caused an issue. Since everyone agrees that SRTP is a must to implement, at least WebRTC would be able to support secure communications for anything that requires privacy, including PSTN interconnect. The fact that a call can be established to a non-secure application should not prevent all of the applications from using DTMF. Otherwise the next step would be a requirement for WebRTC to detect that the browser is located in public location where other people can overheard the call and block all the calling functionality in such case.
> 
> _____________
> Roman Shpount
>

---

From: Randell Jesup <[email-masked]>
Date: Sun, 20 Nov 2011 20:04:30 -0500

> Apart from the PSTN-gateway usecase - do we need DTMF tones at all? Isn't this a PSTN legacy thing? Is there ANY browser based app that needs to RECEIVE dtmf?

Sure, if we're allowing a user to dial into (from the PSTN) their 
browser-based app to check messages (or something else the browser-based 
app knows about, or to tell it to do something (with hardware it's been 
given access to).  Then reception of DTMF key events might be of some 
use.  Things like that are about the only obvious use of receiving 
DTMF.  At this point, I see no need to support incoming DTMF, not even 
tone playback.

> Can apps use the data channel to signal DTMF in the PSTN use case and have the gateway produce the tones? I guess it's not hard to produce a web-based keypad for pressing buttons and sending some s…

There's one serious problem with this: delivery is not linked to the 
media channel.  Depending on bandwidth and congestion control, you can't 
guarantee it being delivered at a time appropriate for playback, even 
with the media-synchronized-data extensions we've talked about, unless 
there's another layer of bandwidth guarantees.

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Sun, 20 Nov 2011 20:14:02 -0500

On 11/20/2011 2:33 PM, Justin Uberti wrote:
> Let me take a stab at a set of baseline (i.e. v1) requirements. This is
> not everything in RFC 4733, but enough to satisfy the needs of 99% of

This sounds good to me.  I'll highlight that Justin is NOT proposing 
handling reception of RFC 4733 - they would be ignored on reception.

> /void sendDTMF(in DOMString tones)/
> /
> /

I'd add one additional statement implied but not stated above:  if tones 
from a sendDTMF() call have not yet ended (including final inter-digit 
pause), a subsequent sendDTMF() call would queue the tones for 
transmission after any current tones waiting to be sent, as if they'd 
all been part of one sendDTMF() call.

-- 
Randell Jesup
[email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Sun, 20 Nov 2011 20:35:30 -0500

On Sun, Nov 20, 2011 at 8:14 PM, Randell Jesup <[email-masked]>wrote:

> pause), a subsequent sendDTMF() call would queue the tones for transmission
> after any current tones waiting to be sent, as if they'd all been part of
> one sendDTMF() call.
>
>
>
I would agree was everything above if we do include optional duration
argument for tones. As I've mentioned before there are IVR systems that
distinguish between short and long duration DTMF digits.
_____________
Roman Shpount

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 21 Nov 2011 07:14:11 +0000

In case signaling path based DTMF, there is no need of API in WebRTC and it is possible to achieve in Javascript. Also, we need to discuss what is PSTN interconnect from WebRTC perspective. The following possibility

1)      RTCWeb-PSTN interconnect through SIP federation

2)      RTCWeb-PSTN interconnect directly

3)      RTCWeb-PSTN interconnect through 3GPP interfaces

4)      RTCWEb-PSTN interconnect through any other???

Please note that FedEx usecase (Sec 4.3.2) in WebRTC usecase document  is not clear about above federation mechanism. Without those details, it is tough to converge. In case the discussion is about fax (T.38), then I agree that it is only possible only in media path but it is not the same case for DTMF.

But still, we need to discuss whether DTMF has to be possible in signaling path

1)      SIP KPML,

2)      3GPP INFO dtmf-relay package,

3)       H.245 signaling

or media path based DTMF

1)      RFC 2833

2)      RFC 4733

3)      Somewhere between RFC 2833 & RFC 4733 . Hope this point is the discussion of this mail thread. IMO, there is a need of detail discussion with draft as it will unveil lot issue in case the middle ground is taken.

I agree with Bernard for SRTP with SDES  in case we are taking the media path for PSTN DTMF interconnect.

Thanks
Partha
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Monday, November 21, 2011 1:39 AM
To: Roman Shpount
Cc: [email-masked]
Subject: Re: [rtcweb] Which parts of RFC 4733 are required? (Re: Support DTMF "codec" or expose DTMF in signaling?)

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 21 Nov 2011 11:16:05 +0100

2011/11/21 Ravindran, Parthasarathi <[email-masked]>:
> In case signaling path based DTMF, there is no need of API in WebRTC and it
> is possible to achieve in Javascript. Also, we need to discuss what is PSTN
> interconnect from WebRTC perspective. The following possibility
>

Hi, I don't think we need to discuss that.

> Please note that FedEx usecase (Sec 4.3.2) in WebRTC usecase document  is
> not clear about above federation mechanism. Without those details, it is
> tough to converge. In case the discussion is about fax (T.38), then I agree
> that it is only possible only in media path but it is not the same case for
> DTMF.

Fax? I hope nobody here will propose adding T.38 capabilities to WebRTC.

> 2)      3GPP INFO dtmf-relay package,

We don't have to discuss that. As you said at the begining "In case
signaling path based DTMF, there is no need of API in WebRTC and it is
possible to achieve in Javascript."

> or media path based DTMF
>
> 1)      RFC 2833
> 2)      RFC 4733
>
> 3)      Somewhere between RFC 2833 & RFC 4733 . Hope this point is the
> discussion of this mail thread. IMO, there is a need of detail discussion
> with draft as it will unveil lot issue in case the middle ground is taken.

Yes, this is the only point of discussion here: implementing RFC
2833/4733 for sending DTMF's via the RTP media stream. There is no
need at all to discuss about signaling or federation.

Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 21 Nov 2011 10:44:54 +0000

As DTMF is possible to achieve in Javascript, there is no need for IETF to recommend or mandate any DTMF mechanism for WebRTC.

In case IETF has to be recommend some specific DTMF mechanism for WebRTC, we need to discuss about WebRTC Federation as there is no WebRTC specific usecase (except Sec 4.3.2 usecase in Usecase document which is a federation usecase). Hope this clarifies.

Thanks
Partha

>From: Iñaki Baz Castillo [mailto:[email-masked]]
>Sent: Monday, November 21, 2011 3:46 PM
>To: Ravindran, Parthasarathi
>Cc: [email-masked]
>Subject: Re: [rtcweb] Which parts of RFC 4733 are required? (Re: Support
>> In case signaling path based DTMF, there is no need of API in WebRTC
>> and it is possible to achieve in Javascript. Also, we need to discuss
>> what is PSTN interconnect from WebRTC perspective. The following
>> possibility
>>
>> Please note that FedEx usecase (Sec 4.3.2) in WebRTC usecase document
>
>> is not clear about above federation mechanism. Without those details,
>> it is tough to converge. In case the discussion is about fax (T.38),
>> then I agree that it is only possible only in media path but it is not
>> the same case for DTMF.
>
>> discussion of this mail thread. IMO, there is a need of detail
>> discussion with draft as it will unveil lot issue in case the middle
>ground is taken.
>
>2833/4733 for sending DTMF's via the RTP media stream. There is no need
>at all to discuss about signaling or federation.
>
>
>Best regards.
>
>--
>Iñaki Baz Castillo
><[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 21 Nov 2011 13:00:22 +0100

> As DTMF is possible to achieve in Javascript, there is no need for IETF to recommend or mandate any DTMF mechanism for WebRTC.

I don't think you have read the whole discussion about DTMF's. There
is obvious and real interest in having RFC 2833/4733 in WebRTC.

> In case IETF has to be recommend some specific DTMF mechanism for WebRTC, we need to discuss about WebRTC Federation as there is no WebRTC specific usecase (except Sec 4.3.2 usecase in Usecase docu…

Honestly, it seems that you want to convert every kind of
discussion/thread in a topic about federation. Let's move on please
and let's define the DTMF topic.

Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 21 Nov 2011 12:28:09 +0000

Inaki,

FYI, I have raised this DTMF issue in IETF-82 RTCWeb Thursday meeting during
draft-cbran-rtcweb-nat presentation.

As you mentioned, lot of folks are interested in WebRTC DTMF without having
the specific WebRTC usecase. In case of Sec 4.3.2 Fedex usecase, it is 
possible to achieve using Javascript and I agree with you that there is no need
to discuss about Federation and even DTMF.

But I'm missing your argument why RFC 2833/4733 is required as per
WebRTC usecase document. In case folks thinks that Sec 4.3.2 requires RFC 2833/
4733 then we need to discuss about Federation and it involves lot of PSTN 
Interop for specific usecase. In case you understand the specific WebRTC DTMF 
usecase which is not possible to solve using Javascript, Please explain.

Thanks
Partha

>Sent: Monday, November 21, 2011 5:30 PM
>> As DTMF is possible to achieve in Javascript, there is no need for
>IETF to recommend or mandate any DTMF mechanism for WebRTC.
>
>I don't think you have read the whole discussion about DTMF's. There is
>obvious and real interest in having RFC 2833/4733 in WebRTC.
>
>
>> In case IETF has to be recommend some specific DTMF mechanism for
>WebRTC, we need to discuss about WebRTC Federation as there is no WebRTC
>specific usecase (except Sec 4.3.2 usecase in Usecase document which is
>a federation usecase). Hope this clarifies.
>
>discussion/thread in a topic about federation. Let's move on please and
>let's define the DTMF topic.
>
>
>Best regards.
>
>
>--
>Iñaki Baz Castillo
><[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 21 Nov 2011 13:47:31 +0100

2011/11/21 Ravindran, Parthasarathi <[email-masked]>:
> WebRTC usecase document.

Well, it's not me, but many others in this WG who advocate for RFC
2833/4733 support in WebRTC.

> In case folks thinks that Sec 4.3.2 requires RFC 2833/

There is no need to discuss about federation. This is just about
sending DTMF via RFC 2833/4733 so it can interoperate with external
networks also using same specification.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 21 Nov 2011 13:16:20 +0000

Inaki,

From the earlier mail thread, I understand that you are not advocating
for RFC 2833/4733. Thanks for double confirmation.

Please note that the missing discussion is about RFC 4733 specific 
usecase for WebRTC as FedEx usecase applies for signaling and RFC 4733. 
The same discussion will helps to find which parts of RFC 4733 required
for WebRTC.

Thanks
Partha

>Sent: Monday, November 21, 2011 6:18 PM
>> 4733 then we need to discuss about Federation and it involves lot of
>> PSTN Interop for specific usecase. In case you understand the specific
>> WebRTC DTMF usecase which is not possible to solve using Javascript,
>Please explain.
>
>There is no need to discuss about federation. This is just about sending
>DTMF via RFC 2833/4733 so it can interoperate with external networks
>also using same specification.
>
>--
>Iñaki Baz Castillo
><[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 21 Nov 2011 14:20:27 +0100

> for RFC 2833/4733. Thanks for double confirmation.

Hi, not exactly. I accept it, and indeed consider it's ok to have it.
I just would like that we can discuss about something else than just
fulfilling SIP requirements.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 21 Nov 2011 13:27:40 +0000

<snip> I didn't understand your above statement. I guess that as usual we 
are going in the circular discussion :-), So I'll stop mailing hereby 
for others opinion </snip>

>Sent: Monday, November 21, 2011 6:50 PM

---

From: Randell Jesup <[email-masked]>
Date: Mon, 21 Nov 2011 10:33:39 -0500

> usecase which is not possible to solve using Javascript, Please explain.

Datastreams (even with all the options being considered) may not be a 
good alternative to 4733, per my previous message.  Even with 
synchronization of delivery to a media stream, there's no guarantee of 
delivery on-time in a congestion situation.  Even if delivered on-time, 
it would require the JS code to be able to run synchronously to the 
media stream and with guaranteed latency, and be able to then inject 
tones into a PSTN media interface with acceptable synchronization to the 
media stream (which probably would mean adding a delay buffer to the 
media stream), etc.  Doable?  yes.  Problematic?  yes.  4733 is a much 
cleaner, more reliable solution, and for those that use it a much 
lower-effort choice.

-- 
Randell Jesup
[email-masked]

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 21 Nov 2011 23:27:37 +0000

Randell,

Please read inline.

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Randell Jesup
>Sent: Monday, November 21, 2011 9:04 PM
>To: [email-masked]
>> FYI, I have raised this DTMF issue in IETF-82 RTCWeb Thursday meeting
>> during draft-cbran-rtcweb-nat presentation.
>>
>> As you mentioned, lot of folks are interested in WebRTC DTMF without
>> having the specific WebRTC usecase. In case of Sec 4.3.2 Fedex
>> usecase, it is possible to achieve using Javascript and I agree with
>> you that there is no need to discuss about Federation and even DTMF.
>>
>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>

Even with
>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>

  Even if delivered on-time,
>media stream), etc. 
<partha> 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. </partha>

 Doable?  yes.  Problematic?  yes.  4733 is a much
>cleaner, more reliable solution, and for those that use it a much lower-
>effort choice.
<partha> RFC 4733 (RTP) is not reliable as explained above. From
The developer point of view, the tone shall be passed in signaling or media and there
is not much difference. </partha>

---

From: Saul Ibarra Corretge <[email-masked]>
Date: Tue, 22 Nov 2011 13:17:51 +0100

Hi,

> Mechanism like KPML or INFO DTMF-relay. </partha>

It presents the same problem, no synchronization is guaranteed.

> /response is part of the mechanism. So, signaling mechanism is preferred

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.

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?

-- 
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 22 Nov 2011 13:38:07 +0100

> What should we do about it?

The response to this is already given in this maillist (and multiple times):

SRTP will be mandatory to *implement* in WebRTC clients, rather than
mandatory to *use*. So yes, the PIN of your bank credit card will be
carried in plain and interceptable RTP when your are using an open
WiFi (cautive portal) in an airport. The solution would be mandating
SRTP usage *always*, but that's too expensive for the owners of legacy
infrastructures, and that seems to be more important than end-users'
privacy/security.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Saul Ibarra Corretge <[email-masked]>
Date: Tue, 22 Nov 2011 13:43:49 +0100

> infrastructures, and that seems to be more important than end-users'

Well, if RFC4733 *mandates* use of SRTP, does that mean we are ignoring this? Or are we not allowing DTMF when using plain RTP?

Regards,

-- 
Saúl Ibarra Corretgé
AG Projects

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 22 Nov 2011 12:43:41 +0000

Saul,

Please read inline.

Thanks
Partha

>From: Saul Ibarra Corretge [mailto:[email-masked]]
>Sent: Tuesday, November 22, 2011 5:48 PM
>Cc: Randell Jesup; [email-masked]
>> <partha> I'm not talking about data channel. My point is to use
>> signaling Mechanism like KPML or INFO DTMF-relay. </partha>
>>
>

<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.
>> 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."
>
<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>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 22 Nov 2011 13:50:46 +0100

> Well, if RFC4733 *mandates* use of SRTP, does that mean we are ignoring this? Or are we not allowing DTMF when using plain RTP?

Unfortunately RFC 4733 says:

  "it makes implementation of SRTP [7] mandatory for compliant implementations"

So, unfortunately, WebRTC clients MUST *implement* SRTP, but whether
to use it or not will depend on the remote peer. The "security" will
rely, at the end, on an ugly alert prompt to the end-user:

   --------------------------------------------------------------------------
        This audio/video communication is insecure
        as the media flow is unencrypted.

        Do you accept it? Options:

              [   I don't understand, so yes   ]

          [   Yes, and don't disturb me again   ]

                  [   Just for this session   ]

                 [   No, but ask me again   ]
   --------------------------------------------------------------------------

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 22 Nov 2011 15:31:21 +0000

Howdy,
Based on the questions raised in this thread and others regarding RFC 4733, I've updated draft-kaplan-rtcweb-sip-interworking-requirements to enumerate specific requirements for RFC 4733 support in a new sub-section 7.1.  This is only an individual draft and my opinion, but at least it's a list to point to and argue over. :)

The updated draft can be found here:
http://www.ietf.org/id/draft-kaplan-rtcweb-sip-interworking-requirements-02.txt

Below is the relevant section from the 02-draft:

7.1. RFC 4733 DTMF Requirements 
    
   The following requirements are driven by the need for WebRTC 
   applications to generate DTMF events to non-WebRTC media servers, 
   gateways, and devices, as described in section 5.3. 
    
   It should be noted the following requirements only address a subset 
   of capabilities in [RFC4733] - namely those the author believes 
   actually matter for WebRTC, and that have the highest chances of 
   being interoperable.  Note that these are also backwards-compatible 
   with RFC 2833, which is what most deployed devices actually 
   implemented to. 
     
      ---------------------------------------------------------------- 
      A3-1            WebRTC MUST provide a means for the 
                      Browser to generate [RFC4733] DMTF RTP 
                      Telephone-events for at least the events 0-15, in 
                      an audio-type RTP packet stream. 
      ---------------------------------------------------------------- 
      A3-2            WebRTC MAY provide a means for the 
                      Browser to receive [RFC4733] DMTF RTP 
                      Events for the telephone-events 0-15. 
      ---------------------------------------------------------------- 
      A3-3            WebRTC MUST indicate [RFC4733] telephone-event 
                      support in SDP, even if the browser cannot 
                      receive and render [RFC4733] packets.  This is 
                      needed to make the far-end know the local browser 
                      supports [RFC4733] and respond with it. 
      ---------------------------------------------------------------- 
      A3-4            WebRTC MUST provide a means for the 
                      Javascript application to invoke [RFC4733] 
                      DTMF events to be generated, and their 
                      duration, with a default duration of 100ms.   
                      In other words, the Javascript should be  
                      able to tell the Browser to generate event 
                      "0" for 100ms based on a button click, for  
                      example. 
      ---------------------------------------------------------------- 
      A3-5            WebRTC MUST provide a means for the 
                      Javascript application to enable or 
                      disable [RFC4733] use, per session. 
      ---------------------------------------------------------------- 
      A3-6            WebRTC MUST NOT generate [RFC4733] events closer 
                      than 50ms back-to-back.  In other words, even if  
                      the Javascript calls the API repeatedly or  
                      provides a string of digits to send, the browser 
                      must enforce a minimum of 50ms inter-event gap. 
      ---------------------------------------------------------------- 
      A3-7            WebRTC MUST generate [RFC4733] events using 
                      the same SSRC as the audio codec(s) for a  
                      stream. 
      ---------------------------------------------------------------- 
      A3-8            WebRTC MUST generate [RFC4733] events in the 
                      same RTP sequence number space as the audio RTP  
                      packets. 
      ---------------------------------------------------------------- 
      A3-9            WebRTC MUST generate [RFC4733] events with the 
                      same clock frequency and timestamp space as  
                      the audio.  
      ---------------------------------------------------------------- 
      A3-10           WebRTC MUST NOT generate audio RTP packets while  
                      sending [RFC4733] DTMF event packets. 
      ---------------------------------------------------------------- 
      A3-11           WebRTC SHOULD generate [RFC4733] events using a 
                      volume decimal value of 10 (binary 1010). 
      ---------------------------------------------------------------- 
      A3-12           WebRTC SHOULD NOT generate an [RFC4733] event for  
                      longer than can be represented by the duration  
                      field (typically 8 seconds for an 8KHz clock). 
                      Although a means to do so is described in section 
                      2.5.1.3 in [RFC4733], it is rarely supported. 
      ---------------------------------------------------------------- 
      A3-13           WebRTC MUST NOT concatenate multiple [RFC4733] 
                      events into one RTP packet. 
      ---------------------------------------------------------------- 

-hadriel

---

From: Justin Uberti <[email-masked]>
Date: Tue, 22 Nov 2011 10:55:50 -0500

On Tue, Nov 22, 2011 at 7:50 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> > Well, if RFC4733 *mandates* use of SRTP, does that mean we are ignoring
> this? Or are we not allowing DTMF when using plain RTP?
>

This is not what was proposed at the most recent WG meeting, and off-topic
to this thread.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 22 Nov 2011 11:03:50 -0500

> this? Or are we not allowing DTMF when using plain RTP?
What RFC 4733 says is:

To meet the need for protection both of confidentiality and integrity,
compliant implementations SHOULD implement the Secure Real-time Transport
Protocol (SRTP).

This is a SHOULD and not MUST. So far this requirement was universally
ignored by all the implementations. Keep in mind, that the main argument
for adding RFC 4733 DTMF support was to inter-operate with existing
gateways. Not a single RFC 4733 implementation on the market forces SRTP if
RFC 4733 payload is used or prohibits RFC 4733 from being sent if SRTP is
not used. I think this requirement can be ignored, since what we are
looking for is the standard that will work in real life, not something that
just provides check-box compatibility with other standards but breaks real
deployments.

>From my point of view, the whole argument behind SRTP requirement in RFC
4733 is misguided. There are very few cases of bit level corruption in IP
networks (UDP is protected by the checksum), thus additional integrity is
not really necessary. A lot of current IVR systems that should require
secure access (like banks or credit cards) accept speech input, so it is
not clear why DTMF should have higher security requirements then voice.

Finally, as far as I know consensus on SRTP was not yet reached. All I am
saying here, is these two issues (DTMF and SRTp support) should not be tied
together.

______________
Roman Shpount

---

From: Saul Ibarra Corretge <[email-masked]>
Date: Tue, 22 Nov 2011 18:41:13 +0100

Hi Roman,

On Nov 22, 2011, at 5:03 PM, Roman Shpount wrote:

> 
> On Tue, Nov 22, 2011 at 7:43 AM, Saul Ibarra Corretge <[email-masked]> wrote:
> To meet the need for protection both of confidentiality and integrity, compliant implementations SHOULD implement the Secure Real-time Transport Protocol (SRTP).
> 

Yes, it does say that. But it also says this in the summary of changes: "More importantly, it makes implementation of SRTP [7] mandatory for compliant implementations, without specifying a mandatory-to-implement method of key distribution.". You may be right and those words in Annex A mislead me, that's why I asked in the first place :-)

> This is a SHOULD and not MUST. So far this requirement was universally ignored by all the implementations. Keep in mind, that the main argument for adding RFC 4733 DTMF support was to inter-operate with existing gateways. Not a single RFC 4733 implementation on the market forces SRTP if RFC 4733 payload is used or prohibits RFC 4733 from being sent if SRTP is not used. I think this requirement can be ignored, since what we are looking for is the standard that will work in real life, not something that just provides check-box compatibility with other standards but breaks real deployments.
> 
> From my point of view, the whole argument behind SRTP requirement in RFC 4733 is misguided. There are very few cases of bit level corruption in IP networks (UDP is protected by the checksum), thus additional integrity is not really necessary. A lot of current IVR systems that should require secure access (like banks or credit cards) accept speech input, so it is not clear why DTMF should have higher security requirements then voice.
> 
> Finally, as far as I know consensus on SRTP was not yet reached. All I am saying here, is these two issues (DTMF and SRTp support) should not be tied together.
> 

It was not my intention to move the discussion, but to raise this concern that I (and some more) had.

Regards,

-- 
Saúl Ibarra Corretgé
AG Projects

---

From: Randell Jesup <[email-masked]>
Date: Mon, 28 Nov 2011 02:35:56 -0500

> 7.1. RFC 4733 DTMF Requirements
[SNIP]
[SNIP]

I would modify A3-10:

        A3-10           WebRTC MUST NOT generate audio RTP packets for
                        the same SSRC while
                        sending [RFC4733] DTMF event packets.

I.e. if you're sending two audio streams, DTMF in one doesn't block DTMF 
in the other.

Other than that: I'm good with this changeset.

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Mon, 28 Nov 2011 02:47:55 -0500

> I.e. if you're sending two audio streams, DTMF in one doesn't block DTMF

Doh!  "DTMF in one doesn't block *audio* in the other"

-- 
Randell Jesup
[email-masked]