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

["DRAGE, Keith (Keith)" <[e-mail]>]

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:[e-mail]]
Sent: 21 December 2015 19:52
To: DRAGE, Keith (Keith)
Cc: Ted Hardie; Cullen Jennings; [e-mail]
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) <[e-mail]<mailto:[e-mail]>> 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 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:[e-mail]<mailto:[e-mail]>] On Behalf Of Roman Shpount
Sent: 18 December 2015 23:24
To: Ted Hardie
Cc: Cullen Jennings; [e-mail]<mailto:[e-mail]>
Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio

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

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

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

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.

​And they are using the A-D set?

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

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.


​So this is theoretical.​

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

​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