Thanks Lorenzo, i would look into it and see how it can be added in Asterisk. If it works fine, i would submit another patch.
Regards, Nitesh On Tue, Jan 28, 2014 at 8:06 PM, Lorenzo Miniero <[email protected]> wrote: > Hi Nitesh, > > openssl normally handles retransmissions by itself, but considering that > in Asterisk the network is handled by pjnath, this needs to be taken care > of manually. You can find some details about how this can be done here: > > https://groups.google.com/forum/#!topic/discuss-webrtc/MSueQRZEyxo > > I describe the (very simple and rough) approach I used in one of my > implementations there, while Rajarshi added some definitely useful details > on how to implement retransmissions the right way. Any of them might be > added to Asterisk in order to retransmit lost packets. > > Lorenzo > > > > > 2014-01-28 Nitesh Bansal <[email protected]> > > I have another question on the same, even if use the media-proxy or not, i >> assume that DTLS message retransmissions need to be handled. >> I would like some pointers on how can we handle retransmissions in >> asterisk. >> P.S: I am not an expert on openssl library, so don't know much about how >> it functions internally. >> >> Regards, >> Nitesh >> >> >> On Mon, Jan 27, 2014 at 4:17 PM, Nitesh Bansal >> <[email protected]>wrote: >> >>> Hello everyone, >>> >>> Contining on the DTLS-SRTP, i need asterisk to be able to retry DTLS >>> handshake in case there is no response from the peer for the first >>> attempted handshake. >>> This is happening in case i use the media-proxy with asterisk, >>> media-proxy is sending DTLS data before completing the ICE handshake, so >>> DTLS messages are being >>> sent to an ICE candidate which is different from final selected ice >>> candidate. In this case, i would like asterisk to attempt the DTLS >>> handshake after a specific timeout? >>> Any pointers on how this can be done ( i can think of scheduling a >>> timer) ? >>> P.S: With media-proxy, asterisk sees the de-iced SDP, media-proxy is >>> handling the ICE handshake on its own. >>> >>> Regards, >>> Nitesh Bansal >>> >>> >>> >>> On Fri, Jan 24, 2014 at 4:22 PM, Daniel Pocock <[email protected]>wrote: >>> >>>> On 24/01/14 10:59, Lorenzo Miniero wrote: >>>> >>>> Hi Daniel, >>>> >>>> the "sha-2" error can be easily circumvented, and the dtlsverify=no >>>> needs an additional callback in the code to always return a success. Nitesh >>>> and I provided some patches here: >>>> >>>> https://issues.asterisk.org/jira/browse/ASTERISK-22961 >>>> >>>> Mine was specifically targeted at getting Firefox to work, but I only >>>> tested incoming calls. I didn't test Nitesh's one, but apparently he >>>> managed to get it to work as well. >>>> >>>> >>>> Thanks for this, I've tested with it >>>> >>>> Two things were necessary for success with Firefox: >>>> a) I applied Nitish's patch to the latest 11.7 from Debian (it is on a >>>> branch dtls-srtp-patch), it builds on wheezy and appears to work >>>> >>>> http://anonscm.debian.org/gitweb/?p=pkg-voip/asterisk.git;a=shortlog;h=refs/heads/dtls-srtp-patch >>>> Anybody wanting to test can clone from there and then >>>> dpkg-buildpackage -rfakeroot -i.git >>>> to build packages with the change. This has not been uploaded in any >>>> official packages, I let the package maintainers decide if they want to >>>> support the patch. >>>> >>>> b) I had to work around the issue with the media descriptor protocol >>>> sub-field. In JSCommunicator (using the branch "develop" from JsSIP), I >>>> look at the field in the outgoing and incoming INVITE and change it to/from >>>> the Asterisk format: >>>> >>>> https://github.com/opentelecoms-org/jscommunicator/commit/6980f8e1c3311c46154b3840d695f0ddc9c8c8ae >>>> >>>> It can now be tested with the links at >>>> http://www.sip5060.net/test-calls and/or from >>>> http://www.lumicall.org/drucall - both now appear to work from Firefox >>>> and it appears to maintain compatibility for calls between JSCommunicator >>>> users. >>>> >>>> However, I'd like to understand if I really should have the patch/hack >>>> in JSCommunicator at all - should Asterisk be willing to accept SDP >>>> specifying "RTP/SAVPF" alone? If so, then I can cut out half the >>>> JSCommunicator patch. >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> _____________________________________________________________________ >>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >>>> >>>> asterisk-dev mailing list >>>> To UNSUBSCRIBE or update options visit: >>>> http://lists.digium.com/mailman/listinfo/asterisk-dev >>>> >>> >>> >> >> -- >> _____________________________________________________________________ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> >> asterisk-dev mailing list >> To UNSUBSCRIBE or update options visit: >> http://lists.digium.com/mailman/listinfo/asterisk-dev >> > > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
