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

[Henry Lin]

Hi Joshua,

Thanks for your tips.

For the OUTGOING part, there is no problem. we already did as you said (
use inherited endpoints).

For INCOMING part, you said:

1.  media_encryption_optimistic is created for SDES, which can supports
both sdes and no-encryption in the same config endpoints.
    and our test for DTLS also works but is a side effect.

2. a new param of media_encryption = "optional" is possible to do in the
code, which can supports SDES/DTLS/NO-ENCRYPTION at the same config
endpoint for incoming ( ex: caller ).


So in your opinion:

would it be better to integrate media_encryption = "optional" with
media_encryption_optimistic = true ? or just leave them separated?

since they are trying to solve the same problem --- support webrtc clients
but also have backward-compatibility to the huge amount of old-school
devices

media_encryption = "optional" implies media_encryption_optimistic = true.


by the way,
Is there anyone already implement this, or opened an issue tracker that can
be patched ?









> 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.
>

Oops!


>
>
>>
>> *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
>
>
>
>
> _______________________________________________
> --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/20160118/aa7ae284/attachment.html>