- From: Sergio Garcia Murillo via GitHub <sysbot+gh@w3.org>
- Date: Thu, 31 Mar 2016 22:20:23 +0000
- To: public-ortc@w3.org
murillo128 has just created a new issue for
https://github.com/openpeer/ortc:
== Reverse RTCRtpSender<->RTCDtmfSender composition ==
Currently we create a new RTCDtmfSender by calling it's constructor
and passing the RTCRtpSender as attribute. Then we have to inspect
canInsertDTMF to check whether the RTCDtmfSender is capable of sending
DTMF.
```javacript
var sender = new RTCDtmfSender(sendObject);
if (sender.canInsertDTMF) {
var duration = 500;
sender.insertDTMF("1234", duration);
} else {
trace("DTMF function not available");
}
```
This seems weird to me, as canInsertDTMF refers to te ability to of
the RTCRtpSender to send or not DTMFs and has nothing to do with the
RTCDtmfSender object it self.
The natural way of doing that would be by querying the RTCRtpSender
for it's RTCDtmfSender object as the sender MUST know if it supports
or not dtmfs based on the media type/send codecs (removing then the
canInsertDTMF property of RTCDtmfSender)
```javacript
var sender = sendObject.getDtmfSender();
if (sender) {
var duration = 500;
sender.insertDTMF("1234", duration);
} else {
trace("DTMF function not available");
}
```
We can refine the pattern later in order to remove the telephony-event
as a codec.
Please view or discuss this issue at
https://github.com/openpeer/ortc/issues/446 using your GitHub account
Received on Thursday, 31 March 2016 22:20:25 UTC