- 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