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

Nitesh Bansal nitesh.bansal at gmail.com
Wed Jan 29 02:59:58 CST 2014


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 <lminiero at gmail.com> 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 <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-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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140129/1ff79c9b/attachment.html>


More information about the asterisk-dev mailing list