[asterisk-dev] Asterisk 11; WEBRTC firefox nightly build fingeprint sha-256

[Lorenzo Miniero]

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 <nitesh.bansal at gmail.com>

> 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 <nitesh.bansal at gmail.com>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 <daniel at pocock.com.au>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-callsand/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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140128/a4513147/attachment.html>