Re: Where to attach a DTMF API

On 11/30/2011 07:55 AM, Ravindran, Parthasarathi wrote:
> Hi Stefan,
>
> AFAIK, there is no conclusion for RTCWeb DTMF mechanism as per
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg02986.html.
> As I mentioned in other mail thread, there is no need to define
> WebRTC API for DTMF interop with PSTN. From the application
> Developer perspective, it is possible to sent the digits in the
> Websocket (signaling path) using any proprietary mechanism which
> Shall interop with any existing PSTN. There is no security issue
> as WebRTC uses HTTPS only.
Hi Parta,

I think you are right in that there is no conclusion yet on this. 
However, I felt that there was enough weight behind doing media plane 
DTMF (RFC4733) to start discussing what the API should look like in 
order to not loose time if that is what is eventually concluded (our 
schedule is quite tight).

If in the end the decision is to not include DTMF, then we would remove 
that part of the API (and have had wasted a few cycles).

Stefan
>
> Thanks
> Partha
>
>
>> -----Original Message-----
>> From: Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com]
>> Sent: Tuesday, November 29, 2011 2:18 PM
>> To: public-webrtc@w3.org
>> Subject: Where to attach a DTMF API
>>
>> (In role of contributor):
>>
>> On the rtcweb mail list a DTMF API has been proposed
>> (http://www.ietf.org/mail-archive/web/rtcweb/current/msg02887.html).
>>
>>
>> sendDTMF(in DOMString tones, in optional long duration)
>>
>> ex:
>> sendDTMF("1")  // plays tone 1 for 50 ms
>> sendDTMF("2", 200)  // plays tone 2 for 200 ms
>> sendDTMF("123")  // plays tones 1, 2, 3 in succession, each for 50 ms
>> sendDTMF("456", 200)  // plays tones 4, 5, 6 in succession, each for 200
>> ms
>>
>> I don't have enough of insight in DTMF to comment on the options in the
>> sendDTMF method, but I have a comment on what object the method should
>> be available on:
>>
>> I the mail referenced, sendDTMF is a method on MediaStreamTrack. I think
>> the method should apply on PeerConnection because my understanding is
>> that the idea is to generate RTP-packets according to RFC4733, not to
>> insert tones in the audio. This means that "sendDTMF" has really no
>> meaning outside a PeerConnection.
>>
>> I understand that this means that there are some other things that has
>> to be met:
>> * There must be an audio MediaStreamTrack in at least one of the
>> localStream's (that the DTMF RTP packets can share SSRC with)
>> * If there are several outgoing audio RTP streams (having different
>> SSRC's), it must be possible to understand (control?) which SSRC that
>> will be reused by DTMF.
>>
>> My very simple proposal for this would be that the DTMF RTP packets will
>> share SSRC with the first audio track of the first MediaStream that has
>> at least one audio track. If there is no such MediaStream in
>> localStream's, then "sendDTMF" will fail.
>>
>> I realize that this will be a bit cumbersome to use for the application
>> developer, but my counter argument would be: webrtc is primarily for
>> browser-to-browser (I even think the charter says so), and should be
>> simple to use for this case, but could be allowed to be cumbersome to
>> use for other cases. Of course the complexity can be hidden by a
>> library.
>>
>> (If we instead do adopt a model where DTMF is in fact represented by
>> tones - but for a connection transported according to RFC4733 - then it
>> would make sense to attach sendDTFM to a MediaStream or MediaStreamTrack
>> object)
>>
>> My $0.05
>> Stefan
>

Received on Wednesday, 30 November 2011 08:03:13 UTC