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

[Henry Lin]

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.


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


*Here are scenario:*


1. use other sip proxy for register ( ex: kamailio ), so the endpoint will
have only one section, the identity is ip adress of our sip proxy.

2. every call to kamailio will forward to asterisk, and asterisk can accept
any encryption that caller requested in the sdp.

3. when outgoing, we know which encryption to use of our destinations (
every users or other pstn trunk)

without accept all encryption when incoming, we must force our users to
register to different ip address of register servers, and use different ip
identity to attach different endpoint setting in asterisk conf.




Correct me if I am wrong.
Any alternative suggestions are appreciated!

Cheers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160111/da65788c/attachment.html>