[asterisk-dev] Asterisk pjsip support all media_encryption no/dtls/sdes for incoming request

Joshua Colp jcolp at digium.com
Sat Jan 16 07:19:00 CST 2016


Henry Lin wrote:
> Hi Everyone,
>
>
> *This issue had  discussed before, you can check at:*
>
> Sun Nov 9 17:54:36 CST 2014
> [asterisk-dev] Notes from setting up SIP+TLS/RTP+DTLS
> http://lists.digium.com/pipermail/asterisk-dev/2014-November/071322.html
>
>
> *Current situation:*
>
> 1. currently, asterisk (13.6) use "identity" ( ip / FROM / TO ) to
> identify incoming user and attach an matched "endpoint" configuration to it.
>
> 2. in the configuration, there is a option named: media_encryption
> <https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_res_pjsip#Asterisk13Configuration_res_pjsip-endpoint_media_encryption> =
> no / dtls / srtp, default: no
>      it means the endpoint should use this setting during RTP setup, you
> can use one of it.
>      so if you set to: dtls, the matched client should always use dtls
> in their sdp and send to asterisk
>
> 3. fortunately, you can combine with other options:
> media_encryption_optimistic
> <https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_res_pjsip#Asterisk13Configuration_res_pjsip-endpoint_media_use_received_transport> =
> yes
> media_use_received_transport
> <https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_res_pjsip#Asterisk13Configuration_res_pjsip-endpoint_media_encryption_optimistic> =
> yes
>
>      it will achieve: Asterisk can accept both the "encryption type" set
> in media_encryption
> <https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_res_pjsip#Asterisk13Configuration_res_pjsip-endpoint_media_encryption> and
> No Encryption.
>      ex: if you set media_encryption
> <https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_res_pjsip#Asterisk13Configuration_res_pjsip-endpoint_media_encryption> =
> dtls, then you can accept both dtls and no encryption ( but not sdes )
> and vice versa.

The media_encryption_optimistic option was originally created for use 
with SDES, where there's a way that companies implement to do it. We 
don't currently have tests for its use with DTLS and if it works I would 
say that's a side effect of it.

>
>
> *Different use case of asterisk:*
>
> I know from the perspective of using asterisk as an all in one sip
> proxy, it makes non-sense to support both dtls/sdes on the same
> endpoint. How come we use different encryption for the same endpoint in
> and out? and how to determine which encryption should we use while outgoing?
>
> But I know there are lots of users not use asterisk as an all-in-one sip
> server, we just use it as a solid trunk to connect to pstn world or do
> the transcoding stuff.
>
>
> *TL;DR*
>
> For the backward-compatibility to the huge amount of old-school devices
> which may still alive in a decade, can we add a new argument "optional"
> to media_encryption option?

It should be possible to do this in the code.

>
> it means it can accept any encryption of the incoming, and if we want to
> restrict, we still can reject it in extensions based on our logic.
>
> To avoid conflict that " How we determine the outgoing if we set to
> 'optional'", maybe it can split media_encryption into "IN" and "OUT",
> ex: "in_media_encryption", "out_media_encryption", and it will not be
> confused.
>
> *p.s. *
>
> out_media_encryption is an default value to me though. we can use syntax
> for example:
>
> exten => s,n,Set(pjsipoutgoing=outgoing-no-encrypt/sip:)
> exten => s,n,Set(pjsipoutgoing=outgoing-sdes-encrypt/sip:)
> exten => s,n,Set(pjsipoutgoing=outgoing-dtls-encrypt/sip:)
>
> to determine which encryption should we use or not based on our user
> database, so I don't mind which encryption was set for outgoing. I
> always do it in specific way when outgoing.

Why don't you just create different outgoing endpoints (all inherited 
from a template so they all have the same settings except for 
encryption) and use those to choose the outgoing encryption? This would 
currently require no code modifications.

Cheers,

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org




More information about the asterisk-dev mailing list