[SR-Users] NO_DTLS_FINGERPRINT when calling from webrtc to webrtc client

Daniel-Constantin Mierla miconda at gmail.com
Wed Sep 17 22:55:38 CEST 2014


On 17/09/14 17:19, Paweł Sternal wrote:
> Thanks Daniel, you save my day :-)
You're welcome! Great to see you ended up with more than expected :-)

Cheers,
Daniel

> Two rtpengine solves my problem and works perfect. This solution also 
> adds me the possibility to record calls, when between two rtpengine 
> instances I will put rtpproxy.
>
> Regards,
> Pawel
>
> 2014-09-17 9:35 GMT+02:00 Daniel-Constantin Mierla <miconda at gmail.com 
> <mailto:miconda at gmail.com>>:
>
>     Hello,
>
>     I would add the RTP-WebRTC gateway between SIP Kamailio and SIP
>     UAC, from resources point of view, it is the only leg that needs
>     encryption/decryption.
>
>     Otherwise, you can try to work with two rtpengine instances (sets)
>     in WS Kamailio, one to use for ws client to proxy and the other
>     one for the leg from proxy to ws client. It will be a
>     communication between them with classic rtp, both having towards
>     ws client webrtc. It has the drawback of decryption and encryption
>     done two times for the same call. You would need to add rtpengine
>     set id in record-route to be able to handle properly the
>     re-INVITE, BYE, etc.
>
>     Another option that I would use is to send a negative reply from
>     SIP kamailio, catch that in failure_route in WS Kamailio and
>     engace there the rtpengine with proper flags. E.g., you assume it
>     is going to be webrtc-to-webrtc, so no encryption/decryption added
>     first time invite comes from WS client. You forward to SIP
>     kamailio, which based on location, if it discovers that the callee
>     is classic SIP-RTP, will send a 4xx back to WS Kamailio -- you end
>     previous rtpengine session and engage it again with new flags (use
>     branch route for managing rtpengine -- like it is done in default
>     kamailio.cfg for rtpproxy).
>
>     Cheers,
>     Daniel
>
>
>     On 15/09/14 20:30, Paweł Sternal wrote:
>
>         Hi. Another topic about WebRTC, websockets with kamailio and
>         rtpengine ;-)
>
>         My problem is how to distinguish a call to WS UAC and how to
>         SIP UAC in scenarios:
>
>         1) WS client1 -> WS kamailio -> SIP kamailio -> SIP UAC
>
>         2) WS client1 -> WS kamailio -> SIP kamailio -> WS kamailio ->
>         WS client2
>
>         WS kamailio is a proxy, SIP kamailio is a registrar
>
>         When "WS client1" is calling to "123123" WS kamailio doesn't
>         know if "123123" was registered from "WS client2" or from SIP UAC.
>
>         I have in this case rtpengine_manage("....... RTP/AVP"), but
>         when INVITE is returned to WS kamailio? RTP/SAVPF?
>
>         Probably it is obvious, however...
>
>         When WS client2 reply with 200OK, rtpengine_manage(".....
>         ICE=force") to WS client1 SDP is sent without a:fingerprint.
>         sipml5 dumps warning:
>
>         message: "Could not negotiate answer SDP; cause =
>         NO_DTLS_FINGERPRINT
>
>         I tried different combinations... and I'm stuck :/
>
>         Regards
>
>         _______________________________________________
>         SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>         mailing list
>         sr-users at lists.sip-router.org
>         <mailto:sr-users at lists.sip-router.org>
>         http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>     -- 
>     Daniel-Constantin Mierla
>     http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -
>     http://www.linkedin.com/in/miconda
>     Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
>     Sep 22-25, Berlin, Germany
>
>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140917/e0b88b0f/attachment.html>


More information about the sr-users mailing list