Subject: [rtcweb] Working group last call for draft-ietf-rtcweb-audio

From: Ted Hardie <[email-masked]>
Date: Fri, 18 Dec 2015 10:13:59 -0800

The two issues that surfaced during this last call that needed resolution
were DTMF and comfort noise.  Based on the discussion, we believe that the
comfort noise requirement will be shifted to "WebRTC endpoints". The DTMF
language will aligned with the W3C specification and clarified that A-D are
not supported (as they will not be supported in the JavaScript).

After the document is updated, the chairs plan to submit it to IETF last
call.

regards,

Ted, Cullen, Sean

---

From: Roman Shpount <[email-masked]>
Date: Fri, 18 Dec 2015 13:32:42 -0500

Hi All,

Since the decision not to support A-D DTMF digits was never made on the
IETF list (I have looked through the archive and cannot find it), I do not
think they should be removed.

Minimal DTMF tone duration and gap duration should be added to the document.

The meaning of "consuming" RFC 4733 events by WebRTC endpoints is unclear.

I suggest to change the following section of the document:

OLD TEXT:
The audio/telephone-event media format as specified in [RFC4733].
      WebRTC endpoints are REQUIRED to be able to generate and consume
      the following events:

         +------------+--------------------------------+-----------+
         |Event Code  | Event Name                     | Reference |
         +------------+--------------------------------+-----------+
         | 0          | DTMF digit "0"                 |  RFC4733  |
         | 1          | DTMF digit "1"                 |  RFC4733  |
         | 2          | DTMF digit "2"                 |  RFC4733  |
         | 3          | DTMF digit "3"                 |  RFC4733  |
         | 4          | DTMF digit "4"                 |  RFC4733  |
         | 5          | DTMF digit "5"                 |  RFC4733  |
         | 6          | DTMF digit "6"                 |  RFC4733  |
         | 7          | DTMF digit "7"                 |  RFC4733  |
         | 8          | DTMF digit "8"                 |  RFC4733  |
         | 9          | DTMF digit "9"                 |  RFC4733  |
         | 10         | DTMF digit "*"                 |  RFC4733  |
         | 11         | DTMF digit "#"                 |  RFC4733  |
         +------------+--------------------------------+-----------+

_____________
Roman Shpount

On Fri, Dec 18, 2015 at 1:13 PM, Ted Hardie <[email-masked]> wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 18 Dec 2015 13:57:40 -0500

Sorry,due to a finger slip the email went out too early. Here is the
proposed change:

OLD TEXT:

NEW TEXT:

The audio/telephone-event media format as specified in [RFC4733].
WebRTC endpoints are REQUIRED to be able to generate the following
events:

     +------------+--------------------------------+-----------+
     |Event Code  | Event Name                     | Reference |
     +------------+--------------------------------+-----------+
     | 0          | DTMF digit "0"                 |  RFC4733  |
     | 1          | DTMF digit "1"                 |  RFC4733  |
     | 2          | DTMF digit "2"                 |  RFC4733  |
     | 3          | DTMF digit "3"                 |  RFC4733  |
     | 4          | DTMF digit "4"                 |  RFC4733  |
     | 5          | DTMF digit "5"                 |  RFC4733  |
     | 6          | DTMF digit "6"                 |  RFC4733  |
     | 7          | DTMF digit "7"                 |  RFC4733  |
     | 8          | DTMF digit "8"                 |  RFC4733  |
     | 9          | DTMF digit "9"                 |  RFC4733  |
     | 10         | DTMF digit "*"                 |  RFC4733  |
     | 11         | DTMF digit "#"                 |  RFC4733  |
     | 12         | DTMF digit "A"                 |  RFC4733  |
     | 13         | DTMF digit "B"                 |  RFC4733  |
     | 14         | DTMF digit "C"                 |  RFC4733  |
     | 15         | DTMF digit "D"                 |  RFC4733  |
     +------------+--------------------------------+-----------+

Generated events MUST have duration of no more than 6000 ms and no less
than 40 ms with the recommended default duration of 100 ms for each tone.
The gap between events MUST be no less then 30 ms with the recommended
default duration of 70 ms. Event SHOULD start on a regular audio packet
border and event and gap duration SHOULD be rounded up to the next regular
audio packet border.

During the time events are generated no audio SHOULD be sent for the same
audio stream. When gaps between events are generated, silence SHOULD
and not the background audio should be sent using regular audio encoding.

If multiple audio sampling rates are supported, audio/telephone-event
payload
SHOULD be present for each supported sampling rate. Endpoints SHOULD use
audio/telephone-event format parameters during the offer/answer to
indicate which events are supported.

Receivers MUST be able to consume any audio/telephone-event events
in such a way that it will not generate audio artifacts, jitter buffer
adjustments, payload mismatches, or invalid RTCP statistics calculation.
Receivers MAY generate audio corresponding to the received events
but are also allowed to discard them in a manner that does not affect
regular audio processing.

_____________
Roman Shpount

---

From: Ted Hardie <[email-masked]>
Date: Fri, 18 Dec 2015 11:34:34 -0800

> think they should be removed.
​Can you say more about what use there would be in supporting them?

regards,

Ted​

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 18 Dec 2015 14:54:34 -0500

The DTMF language will aligned with the W3C specification and clarified that A-D are not supported (as they will not be supported in the JavaScript).

[BA] I am not sure what "aligning the text" means. The W3C WEBRTC specification does not dictate that A-D be supported - it only describes how implementations should behave for supported tones, referencing the Audio document for DTMF requirements. If a tone is unsupported it is considered "unrecognized" in the API. It is the Audio document that provides the requirements, and as long as A-D aren't a MUST NOT, the API needs to allow implementations to send A-D if they choose to do so.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 18 Dec 2015 16:10:13 -0500

> ​Can you say more about what use there would be in supporting them?

First of all, DTMF support is there for legacy support. I generally dislike
when features are removed from an established capability set without a good
reason. Can anyone name me a single commercial PSTN VoIP gateway which does
not support A-D DTMF tones? I cannot think of one. I believe it would
generally make sense to implement whole set defined in
https://tools.ietf.org/html/rfc4733#section-3.2 instead of just 3/4. From
what I know there is no extra implementation to support A-D DTMF tone. It
looks like these tones are removed for aesthetic reasons only.

As far as more specific examples are concerned:

DTMF tones A-D are used to provide a way to access hidden flows in IVR
systems. For instance, when inbound call center is integrated with an
external auto-dialer, auto-dialer places a call to call center IVR and uses
a hidden flow accessible via one of those tones to connect directly to a
waiting agent.

DTMF tones A-D are also commonly used by ham radio operators to integrate
with PSTN, such as http://www.echolink.org/Help/dtmf_functions.htm

DTMF tone A-D are used to provide prioritized call handling service in ITU
Q.955.3 specification which is still used by some PBX and phone systems.

Finally, some calling card like systems allow remote control of functions
such as flash by mapping them to extended DTMF tones.

Regards,
_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Dec 2015 15:19:48 -0600

On 12/18/15 13:54, Bernard Aboba wrote:
> The DTMF language will aligned with the W3C specification and 
> clarified that A-D are not supported (as they will not be supported in 
> the JavaScript).
>
> [BA] I am not sure what "aligning the text" means. The W3C WEBRTC 
> specification does not dictate that A-D be supported - it only 
> describes how implementations should behave for supported tones, 
> referencing the Audio document for DTMF requirements. If a tone is 
> unsupported it is considered "unrecognized" in the API.

I'm a little confused about where this leaves the state of play. You're 
proposing the the W3C spec leave it open as to whether sending an "A" 
through the API will work or throw an exception? That seems to be 
begging for unnecessary pain. And, in this case, it's pushing the pain 
down to the authors, who will likely (accidentally) pass that along to 
users. It goes pretty well against the W3 priority of constituencies: 
http://www.w3.org/TR/html-design-principles/#priority-of-constituencies

> It is the Audio document that provides the requirements, and as long 
> as A-D aren't a MUST NOT, the API needs to allow implementations to 
> send A-D if they choose to do so.

Does this rationale apply to RFC5244 tones also? If so, we have a bit 
more work to do on the W3C API.

If the rationale does not apply to RFC5244 tones, I'd be curious to hear 
about the criteria you're using to draw this line.

To be clear, what we need is to have a list of events that are mandatory 
to implement in both W3C and IETF, and none that are optional (at least, 
with the current, exception-throwing API). And we need this list to be 
identical. I personally have absolutely zero interest in whether A-D are 
included, but we need the list to be the same.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Dec 2015 15:24:10 -0600

On 12/18/15 15:10, Roman Shpount wrote:
> It looks like these tones are removed for aesthetic reasons only.

I think it would be better if you directly disagreed with Cullen's 
rationale rather than simply ignoring it. Since it was made in a 
different forum, I'll copy it here.

On 12/9/15 12:48, Cullen Jennings wrote:
> I want to be clear I don't care that much one way or the other about this but I want to try again to explain the issue...
>
> A to D will often be blocked by the system that sends them from one side to the other. So if you write JS applications that use theses, they will work some times and not others. That is just inviting developers to shoot themselves in the foot and no one has identified any benefit of adding A to D yet.
>
> 100% agree that the IETF and W3C specs need to align on this and we should change the ietf audio draft if we are including A-D.
>

To be clear, this is speaking to operational aspects of the system's 
behavior that I haven't had much visibility into. We have one 
implementor effectively asserting that all commercial gateways support 
these tones, and another saying that they tend to be blocked by 
intermediaries. I suppose both assertions could be true, but the net 
effect of both being true is that these tones are broadly unusable.

But I'm in the same boat as Cullen: I don't care much whether these 
tones are supported, as long as the W3C and IETF documents agree with 
each other.

/a

---

From: Ted Hardie <[email-masked]>
Date: Fri, 18 Dec 2015 13:44:18 -0800

On Fri, Dec 18, 2015 at 1:10 PM, Roman Shpount <[email-masked]> wrote:

> First of all, DTMF support is there for legacy support.
> I generally dislike when features are removed from an established
> capability set without a good reason.
>

​We have stretched very far in many directions to be reasonable in our
support of WebRTC to legacy use cases, but ​I don't think we can argue that
WebRTC has an established capability set that includes these, nor has
anyone given flows where a legacy system would reasonably emit them toward
a WebRTC client.

>
> ​Can anyone name me a single commercial PSTN VoIP gateway which does not
> support A-D DTMF tones? I cannot think of one. I believe it would generally
> make sense to implement whole set defined in

​No, the point Cullen made was that they were sufficiently hit-or-miss in
terms of system blocking that they were effectively unreliable *in the
contexts where WebRTC and legacy might interact*.​

> ​Given that they likely would block the receipt of those tones from
external clients in order to avoid this access from outside, this seems
like one of the cases that Cullen alluded to; it is permitted only part of
the time and the access it provides is not standard.​

> with PSTN, such as http://www.echolink.org/Help/dtmf_functions.htm
​This seems far outside our remit.​

> Q.955.3 specification which is still used by some PBX and phone systems.
​Again, not at all clear that a WebRTC client would ever expect to use
these features of a PBX.

> such as flash by mapping them to extended DTMF tones.
​If there is a calling card system using WebRTC, I have not heard of it.
Can you provide a pointer?​

​The main point here is that we need a consistent set.  I take it you do
agree with that point, and disagree only on whether the set should include
A-D.  Do I have that right?

Ted

Regards,

---

From: Roman Shpount <[email-masked]>
Date: Fri, 18 Dec 2015 16:47:07 -0500

On Fri, Dec 18, 2015 at 4:24 PM, Adam Roach <[email-masked]> wrote:

> rationale rather than simply ignoring it. Since it was made in a different
> forum, I'll copy it here.
>

I was reminded multiple times that here is the right forum to discuss this
issue. I am mostly looking for a consensus made here and then propagated to
W3C.

>> I want to be clear I don't care that much one way or the other about this
>> but I want to try again to explain the issue...
>>
>> A to D will often be blocked by the system that sends them from one side
>> to the other. So if you write JS applications that use theses, they will
>> work some times and not others. That is just inviting developers to shoot
>> themselves in the foot and no one has identified any benefit of adding A to
>> D yet.
>>
>> 100% agree that the IETF and W3C specs need to align on this and we
>> should change the ietf audio draft if we are including A-D.
>>
>>
> behavior that I haven't had much visibility into. We have one implementor
> effectively asserting that all commercial gateways support these tones, and
> another saying that they tend to be blocked by intermediaries. I suppose
> both assertions could be true, but the net effect of both being true is
> that these tones are broadly unusable.
>
> But I'm in the same boat as Cullen: I don't care much whether these tones
> are supported, as long as the W3C and IETF documents agree with each other.
>

DTMF tones A-D can be tricky and might not work in 100% of cases.
Unfortunately this applies to all DTMF tones. For instance, DTMF tones from
the party receiving the call do not work in a fair number of cases. If
developer is using DTMF tones, they should be prepared to deal with
consequences. For instance, as a part of operating a conferencing service
with traditional PSTN access we need to deal with 2-3 tickets per day which
are related to DTMF transmission over various telephone networks.

At the same time WebRTC application can be connected to a legacy PSTN
system under developer control (i.e. through the gateway to a PBX which
uses tone A-D for special purpose such as to trigger phone line flash). In
such application these tones will work every time with 100% certainty.

In my previous email I have listed examples of legacy applications that
still use DTMF tones A-D. I think this is reason enough to keep them.

My main point is that it is probably easier to leave the legacy things
alone instead of improving them. DTMF should not be used for any new
applications. Datachannels are a much better option. DTMF should be left
for legacy interop only, so there is no reason to redesign them or make
them easier to use. They worked fine for the past 50 years.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 18 Dec 2015 17:10:31 -0500

> anyone given flows where a legacy system would reasonably emit them toward

There is no additional implementation burden to support DTMF tones A-D, so
there is no stretching as far as any additional work is concerned.

I can guarantee you that legacy systems will generate DTMF tones towards
WebRTC client. Offer/answer telephone event negotiation is normally by
directional. This normally enabled DTMF detection in PSTN gateways. So, if
you have any system that connects WebRTC client to PSTN network, and if the
person on PSTN network will press a keypad digit, this digit will be sent
to WebRTC client. Furthermore, it is common for DTMF digit detection to be
caused by talk off, i.e. some voice periodically triggers DTMF detection.
Finally, some gateways will also send ANS tones if the call hits a fax
machine, so WebRTC end point will get not only DTMF events, but events for
tone that someone just happened to enable on the gateway. Unless we want to
transcode media coming from PSTN, WebRTC client will need to deal with any
incoming telephone-events. All of this being said, it is up to WebRTC
client to decide what to do with the received events. I am fine with these
tones being discard as long as they are being discarded in a manner which
does not disrupt normal audio processing. This means no unexpected jitter
buffer adjustments, packet loss correction for the audio segment covered by
telephone-event, treating these packets as lost, or payload mismatch.

>> https://tools.ietf.org/html/rfc4733#section-3.2 instead of just 3/4.
>> From what I know there is no extra implementation to support A-D DTMF tone.

All DTMF are often unreliable. There are also enough cases when they are
absolutely reliable. In places where they have been used, they can continue
to be used for legacy interop. In cases where they were unreliable they
will continue to be unreliable. It is not our job to fix or change this.

> the time and the access it provides is not standard.​

This is absolutely incorrect. In this particular example auto-dialer is
running on a hosted platform and accesses the inbound call center over
public PSTN.

> ​This seems far outside our remit.​

Why? I have already seen a few virtual ham radio stations with WebRTC
interface

> ​Again, not at all clear that a WebRTC client would ever expect to use

There are intranet WebRTC applications that access in-company legacy PBX
via a private gateway.

> Can you provide a pointer?​

Once again, this would be a private WebRTC application used to place calls
through a gateway which is under control of the person who developer the
app.

> A-D.  Do I have that right?

I agree that we need a consistent set. I would also like that this set
would be defined once and will have no optional components. I do not want
to spent any more time discussion they API to discover which DTMF tones are
supported by a particular implementation. Including tones A-D removes any
excuses for such options.

Regards,
_____________
Roman Shpount

---

From: Ted Hardie <[email-masked]>
Date: Fri, 18 Dec 2015 14:22:10 -0800

On Fri, Dec 18, 2015 at 2:10 PM, Roman Shpount <[email-masked]> wrote:

>>>>> Since the decision not to support A-D DTMF digits was never made on
>>>>> the IETF list (I have looked through the archive and cannot find it), I do
>>>>> not think they should be removed.
>>>>>
>>>>>
> WebRTC client.

​Sorry that this was not clear; I meant specifically A-D.​

Offer/answer telephone event negotiation is normally by directional. This
> normally enabled DTMF detection in PSTN gateways. So, if you have any
> system that connects WebRTC client to PSTN network, and if the person on
> PSTN network will press a keypad digit, this digit will be sent to WebRTC
> client. Furthermore, it is common for DTMF digit detection to be caused by
> talk off, i.e. some voice periodically triggers DTMF detection. Finally,
> some gateways will also send ANS tones if the call hits a fax machine, so
> WebRTC end point will get not only DTMF events, but events for tone that
> someone just happened to enable on the gateway. Unless we want to transcode
> media coming from PSTN, WebRTC client will need to deal with any incoming
> telephone-events. All of this being said, it is up to WebRTC client to
> decide what to do with the received events. I am fine with these tones
> being discard as long as they are being discarded in a manner which does
> not disrupt normal audio processing.
>

​This seems to result in exactly the case Cullen was concerned about; if
they may be discarded their functionality remains completely unreliable.​
But more to the point, you are not pointing to uses of A-D, but number
detection and events which would still be covered.

This means no unexpected jitter buffer adjustments, packet loss correction
> for the audio segment covered by telephone-event, treating these packets as
> lost, or payload mismatch.
>
>
>
> will continue to be unreliable. It is not our job to fix or change this.

​While this is no doubt not your intent, I must say your message reads as
"Sure it's broken now, but we must make sure it remains broken to be
backwards compatible."​

> Why? I have already seen a few virtual ham radio stations with WebRTC
​The only A-D tone in the one example you gave (echolink) was to pull up a
different stored configuration.

> There are intranet WebRTC applications that access in-company legacy PBX

​And they are using the A-D set?
​

> through a gateway which is under control of the person who developer the
​So this is theoretical.​

> excuses for such options.
​Removing them from the set does as well, at least as far as I can tell.
No one has suggested that they be the subject of discovery or negotiation.​

​Ted
​

---

From: Roman Shpount <[email-masked]>
Date: Fri, 18 Dec 2015 18:24:15 -0500

> detection and events which would still be covered.

This is completely unrelated. This applies to all DTMF tones, not A-D
specifically. What I am saying is that WebRTC endpoints must be able to
generate all DTMF tones including A-D and send them to legacy PSTN
(gateway). Legacy PSTN will receive and handle them. If legacy PSTN
(gateway) sends DTMF tones to WebRTC end point (and it will, even though
they are not expected there), WebRTC endpoint can discard them, as long as
it does it nicely.

>> "Sure it's broken now, but we must make sure it remains broken to be
My intent is that there is an existing well understood functionality set
with its benefits (wide support) and faults (unreliability). This
functionality set is called DTMF. Why WebRTC needs to redefine this set is
beyond my understanding.

> different stored configuration.

So, one out of four tones is used in this example.

> ​And they are using the A-D set?

Yes, they are using A-D set to provide priority dialing.

>>> ​If there is a calling card system using WebRTC, I have not heard of
>>> it.  Can you provide a pointer?​
>>>
>>
>> Once again, this would be a private WebRTC application used to place
>> calls through a gateway which is under control of the person who developer
>> the app.
>>
>>

This is real with existing SIP interface being replaced by WebRTC.

> No one has suggested that they be the subject of discovery or negotiation.​

And then they will be added back by some vendor who got a critical customer
who is using these tones for something.

Despite many words exchanged, I think our entire argument can be boiled
down to "let's remove these tones since they sometimes do not work and they
are ugly" vs "let's keep these tones since they are sometimes used and do
work on occasion."

P.S. I have proposed several other things in addition to tones A-D. Are
there any comments regarding adding the following:

Generated events MUST have duration of no more than 6000 ms and no
less than 40 ms with the recommended default duration of 100 ms for each
tone. The gap between events MUST be no less then 30 ms with the
recommended default duration of 70 ms. Event SHOULD start on a regular
audio packet border. Event and gap duration SHOULD be rounded up to the
next regular audio packet border.

During the time events are generated audio SHOULD NOT be sent for the
same audio stream. When gaps between events are generated, silence and not
the background audio SHOULD be sent using regular audio encoding.

If multiple audio sampling rates are supported, audio/telephone-event
payload SHOULD be present for each supported sampling rate. Endpoints
SHOULD use audio/telephone-event format parameters during the offer/answer
exchange to indicate which events are supported.

Receivers MUST be able to consume any audio/telephone-event events in such
a way that it will not generate audio artifacts, unexpected packet loss
concealment, jitter buffer adjustments, payload mismatches, or invalid RTCP
statistics calculation. Receivers MAY generate audio corresponding to the
received events but are also allowed to discard them in a manner that does
not affect regular audio processing.
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 18 Dec 2015 19:01:43 -0500

On Dec 18, 2015, at 16:47, Roman Shpount <[email-masked]> wrote:
> 
> I was reminded multiple times that here is the right forum to discuss this issue. I am mostly looking for a consensus made here and then propagated to W3C.

[BA] Right. However, unless we are prepared to outlaw tones A-D in the audio document (which I would not suggest), the situation will remain much as it is now - the W3C API will need to accommodate implementations that can send those tones.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 19 Dec 2015 00:10:35 +0000

On Dec 18, 2015, at 3:24 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

This applies to all DTMF tones, not A-D specifically. What I am saying is that WebRTC endpoints must be able to generate all DTMF tones including A-D and send them to legacy PSTN (gateway).

The thing people keep asking is why? what is the use case ?

I don’t feel like I have seen an answer to this.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 18 Dec 2015 19:24:15 -0500

On Dec 18, 2015, at 16:19, Adam Roach <[email-masked]> wrote:
> 
> I'm a little confused about where this leaves the state of play. You're proposing the the W3C spec leave it open as to whether sending an "A" through the API will work or throw an exception? 

[BA] Today this depends on whether an implementation supports sending "A" or not. As long as the audio document does not prohibit or mandate support for A-D, there may be some implementations that will recognize A-D and others that won't. The W3C API leaves it open to accommodate the options provided by the audio document.  

In the absence of a prohibition or requirement to support A-D, the best we can do is make it possible in the API for the application to discover what tones are supported, so it can adjust. RFC 4733 describes SDP that provides that information, and similar capabilities have been discussed in ORTC (though they are not currently in the spec since all existing implementations support the full range of tones).

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 19 Dec 2015 00:53:36 +0000

I’m assuming we will bring the W3C specs in line with whatever we decide here.

> On Dec 18, 2015, at 4:24 PM, Bernard Aboba <[email-masked]> wrote:
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 18 Dec 2015 20:12:21 -0500

On Fri, Dec 18, 2015 at 7:10 PM, Cullen Jennings (fluffy) <[email-masked]>
wrote:

>
> On Dec 18, 2015, at 3:24 PM, Roman Shpount <[email-masked]> wrote:
>
> This applies to all DTMF tones, not A-D specifically. What I am saying is
> that WebRTC endpoints must be able to generate all DTMF tones including A-D
> and send them to legacy PSTN (gateway).
>
>
Because there are IVR systems that use them. They are much less common then
IVR systems that use 0-9 * and # but they do exist. I have provided 4
examples of real IVR systems that use these tones. How many do you need to
keep the extra tones? All these systems can probably be re-engineered not
to use A-D tones, but since this is all legacy no one will spend the time.

Your argument that these tones should be removed since they are sometimes
blocked (When exactly? The only places I see them blocked are some
international carriers) and would not work. The same applies to all DTMF
tones. We should remove all telephone-events based on this logic.

Most importantly I do not want optional tones. So, if we decide to remove
A-D, they should not be allowed in the WebRTC API. If these tones are
allowed in WebRTC API, everyone must implement them.
_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Dec 2015 19:26:25 -0600

+1 

Actually, plus however many I have left in my account. This is the crux of the matter, IMO. 

/a

> On Dec 18, 2015, at 19:12, Roman Shpount <[email-masked]> wrote:
> 
> Most importantly I do not want optional tones. So, if we decide to remove A-D, they should not be allowed in the WebRTC API. If these tones are allowed in WebRTC API, everyone must implement them.
> _____________

---

From: Barry Dingle <[email-masked]>
Date: Sat, 19 Dec 2015 12:43:15 +1100

+1

The Use Case is "IVR systems that support RFC 4733".

It is irrelevant that some systems may not support 'A-D'.

Barry Dingle
Fixed - 03-9725-3937    Mob - 041-911-7578
Fellow of University of Melbourne, Australia

On Sat, Dec 19, 2015 at 12:12 PM, Roman Shpount <[email-masked]> wrote:

> On Fri, Dec 18, 2015 at 7:10 PM, Cullen Jennings (fluffy) <
> [email-masked]> wrote:
>
>>
> Because there are IVR systems that use them. They are much less common
> then IVR systems that use 0-9 * and # but they do exist. I have provided 4

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 19 Dec 2015 06:43:52 -0500

On Dec 18, 2015, at 20:12, Roman Shpount <[email-masked]> wrote:
> 
> Because there are IVR systems that use them. They are much less common then IVR systems that use 0-9 * and # but they do exist. I have provided 4 examples of real IVR systems that use these tones. How many do you need to keep the extra tones? All these systems can probably be re-engineered not to use A-D tones, but since this is all legacy no one will spend the time. 
> 
> Your argument that these tones should be removed since they are sometimes blocked (When exactly? The only places I see them blocked are some international carriers) and would not work. The same applies to all DTMF tones. We should remove all telephone-events based on this logic.
> 

[BA] Bingo. To remove optional tones and discovery of tone capability, we either have to prohibit A-D or mandate that these tones be supported.

---

From: Matthew Kaufman <[email-masked]>
Date: Sat, 19 Dec 2015 10:12:17 -0400

Two-way radio system gateways would benefit from having these tones available.

Matthew Kaufman

(Sent from my iPhone)

> On Dec 19, 2015, at 7:43 AM, Bernard Aboba <[email-masked]> wrote:
>

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 19 Dec 2015 23:26:35 +0100

There has been sufficient indications that A-D has applications.
It would be odd to delete a small part of the RFC 4733 interoperability.

In RFC 4733, all are optional, and can be specified in SDP.
But if no fmtp is provided, then the whole set of DTMF tones shall be 
supported.

This is part of what RFC 4733 says about sdp:

  If the "events"
       parameter is omitted, support for events 0-15 (the DTMF tones) is
       assumed.

I suggest to stick to that and support the full set.

/Gunnar

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 20 Dec 2015 11:54:06 +0000

For priority, Q.955.3 does not specify the use of any key sequences for support of the service. Q.955.3 is the ISDN DSS1 signalling specification and does not use DTMF. Further it is a functional signaling system, i.e. any key presses are identified in the terminal and converted into real signals, such as “flash override”.

I assume you are referring to some proprietary PSTN equivalent.

I’d note that the PSTN equivalent codes originally specified by CEPT and provided in an ETSI TR for other services do not use A through D, performing all sequence separators and terminations with “*” and “#”. There is not an ETSI version of MLPP.

Regards

Keith Drage

From: rtcweb [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 18 December 2015 23:24
To: Ted Hardie
Cc: Cullen Jennings; [email-masked]
Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio

On Fri, Dec 18, 2015 at 5:22 PM, Ted Hardie <[email-masked]<mailto:[email-masked]>> wrote:

Offer/answer telephone event negotiation is normally by directional. This normally enabled DTMF detection in PSTN gateways. So, if you have any system that connects WebRTC client to PSTN network, and if the person on PSTN network will press a keypad digit, this digit will be sent to WebRTC client. Furthermore, it is common for DTMF digit detection to be caused by talk off, i.e. some voice periodically triggers DTMF detection. Finally, some gateways will also send ANS tones if the call hits a fax machine, so WebRTC end point will get not only DTMF events, but events for tone that someone just happened to enable on the gateway. Unless we want to transcode media coming from PSTN, WebRTC client will need to deal with any incoming telephone-events. All of this being said, it is up to WebRTC client to decide what to do with the received events. I am fine with these tones being discard as long as they are being discarded in a manner which does not disrupt normal audio processing.

​This seems to result in exactly the case Cullen was concerned about; if they may be discarded their functionality remains completely unreliable.​  But more to the point, you are not pointing to uses of A-D, but number detection and events which would still be covered.

This is completely unrelated. This applies to all DTMF tones, not A-D specifically. What I am saying is that WebRTC endpoints must be able to generate all DTMF tones including A-D and send them to legacy PSTN (gateway). Legacy PSTN will receive and handle them. If legacy PSTN (gateway) sends DTMF tones to WebRTC end point (and it will, even though they are not expected there), WebRTC endpoint can discard them, as long as it does it nicely.

​While this is no doubt not your intent, I must say your message reads as "Sure it's broken now, but we must make sure it remains broken to be backwards compatible."​

My intent is that there is an existing well understood functionality set with its benefits (wide support) and faults (unreliability). This functionality set is called DTMF. Why WebRTC needs to redefine this set is beyond my understanding.

​The only A-D tone in the one example you gave (echolink) was to pull up a different stored configuration.

DTMF tone A-D are used to provide prioritized call handling service in ITU Q.955.3 specification which is still used by some PBX and phone systems.

​Again, not at all clear that a WebRTC client would ever expect to use these features of a PBX.

There are intranet WebRTC applications that access in-company legacy PBX via a private gateway.

Finally, some calling card like systems allow remote control of functions such as flash by mapping them to extended DTMF tones.

​If there is a calling card system using WebRTC, I have not heard of it.  Can you provide a pointer?​

Once again, this would be a private WebRTC application used to place calls through a gateway which is under control of the person who developer the app.

​Removing them from the set does as well, at least as far as I can tell.  No one has suggested that they be the subject of discovery or negotiation.​

And then they will be added back by some vendor who got a critical customer who is using these tones for something.

Despite many words exchanged, I think our entire argument can be boiled down to "let's remove these tones since they sometimes do not work and they are ugly" vs "let's keep these tones since they are sometimes used and do work on occasion."

P.S. I have proposed several other things in addition to tones A-D. Are there any comments regarding adding the following:

Generated events MUST have duration of no more than 6000 ms and no less than 40 ms with the recommended default duration of 100 ms for each tone. The gap between events MUST be no less then 30 ms with the recommended default duration of 70 ms. Event SHOULD start on a regular audio packet border. Event and gap duration SHOULD be rounded up to the next regular audio packet border.

During the time events are generated audio SHOULD NOT be sent for the same audio stream. When gaps between events are generated, silence and not the background audio SHOULD be sent using regular audio encoding.

If multiple audio sampling rates are supported, audio/telephone-event payload SHOULD be present for each supported sampling rate. Endpoints SHOULD use audio/telephone-event format parameters during the offer/answer exchange to indicate which events are supported.

Receivers MUST be able to consume any audio/telephone-event events in such a way that it will not generate audio artifacts, unexpected packet loss concealment, jitter buffer adjustments, payload mismatches, or invalid RTCP statistics calculation. Receivers MAY generate audio corresponding to the received events but are also allowed to discard them in a manner that does not affect regular audio processing.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 21 Dec 2015 14:52:12 -0500

I was referring to AUTOVON like implementations of of MLPP, which use DTMF
tone A through D for priority.

Regards,
_____________
Roman Shpount

On Sun, Dec 20, 2015 at 6:54 AM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

> For priority, Q.955.3 does not specify the use of any key sequences for
> support of the service. Q.955.3 is the ISDN DSS1 signalling specification
> and does not use DTMF. Further it is a functional signaling system, i.e.
> any key presses are identified in the terminal and converted into real
> signals, such as “flash override”.
>
>
>
> I’d note that the PSTN equivalent codes originally specified by CEPT and
> provided in an ETSI TR for other services do not use A through D,
> performing all sequence separators and terminations with “*” and “#”. There
> is not an ETSI version of MLPP.
>
>
>
> Regards
>
>
>
> Keith Drage
>
>
>
> *From:* rtcweb [mailto:[email-masked]] *On Behalf Of *Roman
> Shpount
> *Sent:* 18 December 2015 23:24
> *To:* Ted Hardie
> *Cc:* Cullen Jennings; [email-masked]
> *Subject:* Re: [rtcweb] Working group last call for
> draft-ietf-rtcweb-audio
>
>
>
> And then they will be added back by some vendor who got a critical
> customer who is using these tones for something.
>
>
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 21 Dec 2015 23:25:16 +0000

And as I indicated, that is a proprietary implemention, and nothing whatsoever to do with Q.955.3.

I do not know what is in all the NAR standards, but I am pretty certain there is no standardized usage (i.e. represented in a published standard) either globally or in Europe, in respect of A through D usage. Indeed may signaling schemes using DTMF do not even define their usage (F.23 and Q.23 allocate the tones but essentially leave the extra combinations reserved).

If we are going to state use cases, I would prefer to keep them accurate.

Note that Wikipedia indicates that the AUTOVON use case is now obsolete.

I’d also note that some of these arguments about use cases seem to be going into sending DTMF to webrtc endpoint, which would seem to bring us into use cases of webRTC gateway to webRTC gateway signaling, which at least is not covered in our current gateways document.

Regards

Keith

From: Roman Shpount [mailto:[email-masked]]
Sent: 21 December 2015 19:52
To: DRAGE, Keith (Keith)
Cc: Ted Hardie; Cullen Jennings; [email-masked]
Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio

I was referring to AUTOVON like implementations of of MLPP, which use DTMF tone A through D for priority.

Regards,
_____________
Roman Shpount

On Sun, Dec 20, 2015 at 6:54 AM, DRAGE, Keith (Keith) <[email-masked]<mailto:[email-masked]>> wrote:
For priority, Q.955.3 does not specify the use of any key sequences for support of the service. Q.955.3 is the ISDN DSS1 signalling specification and does not use DTMF. Further it is a functional signaling system, i.e. any key presses are identified in the terminal and converted into real signals, such as “flash override”.

Regards

Keith Drage

From: rtcweb [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Roman Shpount
Sent: 18 December 2015 23:24
To: Ted Hardie
Cc: Cullen Jennings; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Dec 2015 10:28:02 +1100

On 22 December 2015 at 10:25, DRAGE, Keith (Keith)
<[email-masked]> wrote:
> I’d also note that some of these arguments about use cases seem to be going
> into sending DTMF to webrtc endpoint, which would seem to bring us into use
> cases of webRTC gateway to webRTC gateway signaling, which at least is not
> covered in our current gateways document.

I don't believe that there is any plan to have browsers accept DTMF,
if anyone was considering that possibility.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 21 Dec 2015 18:46:49 -0500

> if anyone was considering that possibility.

All I wrote, and I am not sure how to state this any clearer, that since
offer/answer normally negotiates codecs in both direction, PSTN gateways
will send RFC 4733 tones to WebRTC endpoints. WebRTC endpoints should be
able to receive and safely discard them. This is completely unrelated to
A-D tones and should cover all telephone-events.

P.S. Does anyone have any comments regarding the rest of the text that I
proposed? I would think it is much more important then A-D tone support.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 21 Dec 2015 19:15:42 -0500

Also, some might find interesting what ham radio receivers typically look
like:

http://img3.ph.126.net/snBYUz0aHL9x7Fy2mh85MA==/1133499731230960393.jpg

and here is the microphone at higher resolution:

http://i.ebayimg.com/images/i/371238765810-0-1/s-l1000.jpg

As you can see it is designed to send A-D tones.
_____________
Roman Shpount

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 22 Dec 2015 00:24:25 +0000

And the only way I can interpret this as a use case is where the ham radio remote point is also the webrtc endpoint. Is that what you are proposing?

Keith

From: rtcweb [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 22 December 2015 00:16
To: [email-masked]
Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio

Also, some might find interesting what ham radio receivers typically look like:

On Fri, Dec 18, 2015 at 8:12 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
On Fri, Dec 18, 2015 at 7:10 PM, Cullen Jennings (fluffy) <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Roman Shpount <[email-masked]>
Date: Mon, 21 Dec 2015 19:39:15 -0500

On Mon, Dec 21, 2015 at 7:24 PM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

> And the only way I can interpret this as a use case is where the ham radio
> remote point is also the webrtc endpoint. Is that what you are proposing?
>
>
>
The usage example is where ham radio microphone is replaced with a gateway
to which WebRTC endpoint is connected. WebRTC based application in this
example acts as a remote microphone.
_____________
Roman Shpount