Cryptos must be empty when DTLS is active 63.0.3239.108

[soulofmischief87]

Hello,

I am seeing issues with the latest version of chrome 63.0.3239.108 when sending an offer generated with the following flags:UDP/TLS/RTP/SAVPF ICE=force rtcp-mux-offer. I am using the latest pull of rtpengine. I tried removing SDES with SDES-off but had no luck. Does anyone have any idea why this is happening now?

[soulofmischief87]

I tried using the following flag rtpengine offer UDP/TLS/RTP/SAVPF ICE=force SDES-no rtcp-mux-offer

but rtpengine returns to opensips with this

ERROR:rtpengine:parse_flags: error processing flag `SDES-no': unknown flag

Is this flag unsupported by opensips?

[rfuchs]

I have no idea. Never even looked at the opensips module. In the kamailio counterpart, any unrecognized option is passed to rtpengine verbatim as a flag. I suggest you take it up with the opensips guys.

[conraddeweteuphoria]

@soulofmischief87, Did you solve this with OpenSIPS?

[bharathkumardk]

May I know, how did you resolve this issue @soulofmischief87

[soulofmischief87]

Yes, I resolved this by using opensips 2.3 which allows for passing flags opensips did not support prior.

http://www.opensips.org/html/docs/modules/2.3.x/rtpengine.html#rtpengine.f.rtpengine_offer

As stated in the documentation

"When passing an option that OpenSIPS is not aware of, it will be blindly sent to the rtpengine daemon to be processed."[2]

you can set the following

SDES-no when creating the offer towards a WSS peer.

[bharathkumardk]

Thanks for the response @soulofmischief87. I'll update my opensips to 2.3 and post the outcome soon.

[bharathkumardk]

It is resolved after upgrading to opensips 2.3 and set SDES-no when creating the offer.