<div dir="ltr"><div><div class="gmail_signature"><div dir="ltr"><div><br></div></div></div></div>
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hi Joshua,</div><div class="gmail_quote"><br></div><div class="gmail_quote">Thanks for your tips.</div><div class="gmail_quote"><br></div><div class="gmail_quote">For the OUTGOING part, there is no problem. we already did as you said ( use inherited endpoints).</div><div class="gmail_quote"><br></div><div class="gmail_quote">For INCOMING part, you said:</div><br>1.  media_encryption_optimistic is created for SDES, which can supports both sdes and no-encryption in the same config endpoints. </div><div class="gmail_extra">    and our test for DTLS also works but is a side effect.<br><div class="gmail_quote"><div><br></div><div>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 ).<br></div><div><br></div><div><br></div><div>So in your opinion:</div><div><br></div><div>would it be better to integrate media_encryption = "optional" with media_encryption_optimistic = true ? or just leave them separated?</div><div><br></div><div>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</div><div><br></div><div>media_encryption = "optional" implies media_encryption_optimistic = true.<br></div><div><br></div><div><br></div><div>by the way,</div><div>Is there anyone already implement this, or opened an issue tracker that can be patched ?</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Henry Lin wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi Everyone,<br>
<br>
<br>
*This issue had  discussed before, you can check at:*<br>
<br>
Sun Nov 9 17:54:36 CST 2014<br>
[asterisk-dev] Notes from setting up SIP+TLS/RTP+DTLS<br>
<a href="http://lists.digium.com/pipermail/asterisk-dev/2014-November/071322.html" rel="noreferrer" target="_blank">http://lists.digium.com/pipermail/asterisk-dev/2014-November/071322.html</a><br>
<br>
<br>
*Current situation:*<br>
<br>
1. currently, asterisk (13.6) use "identity" ( ip / FROM / TO ) to<br>
identify incoming user and attach an matched "endpoint" configuration to it.<br>
<br>
2. in the configuration, there is a option named: media_encryption<br>
<<a href="https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_res_pjsip#Asterisk13Configuration_res_pjsip-endpoint_media_encryption" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_res_pjsip#Asterisk13Configuration_res_pjsip-endpoint_media_encryption</a>> =<br>
no / dtls / srtp, default: no<br>
     it means the endpoint should use this setting during RTP setup, you<br>
can use one of it.<br>
     so if you set to: dtls, the matched client should always use dtls<br>
in their sdp and send to asterisk<br>
<br>
3. fortunately, you can combine with other options:<br>
media_encryption_optimistic<br>
<<a href="https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_res_pjsip#Asterisk13Configuration_res_pjsip-endpoint_media_use_received_transport" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_res_pjsip#Asterisk13Configuration_res_pjsip-endpoint_media_use_received_transport</a>> =<br>
yes<br>
media_use_received_transport<br>
<<a href="https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_res_pjsip#Asterisk13Configuration_res_pjsip-endpoint_media_encryption_optimistic" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_res_pjsip#Asterisk13Configuration_res_pjsip-endpoint_media_encryption_optimistic</a>> =<br>
yes<br>
<br>
     it will achieve: Asterisk can accept both the "encryption type" set<br>
in media_encryption<br>
<<a href="https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_res_pjsip#Asterisk13Configuration_res_pjsip-endpoint_media_encryption" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_res_pjsip#Asterisk13Configuration_res_pjsip-endpoint_media_encryption</a>> and<br>
No Encryption.<br>
     ex: if you set media_encryption<br>
<<a href="https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_res_pjsip#Asterisk13Configuration_res_pjsip-endpoint_media_encryption" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_res_pjsip#Asterisk13Configuration_res_pjsip-endpoint_media_encryption</a>> =<br>
dtls, then you can accept both dtls and no encryption ( but not sdes )<br>
and vice versa.<br>
</blockquote>
<br>
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.<br></blockquote><div><br></div><div>Oops!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
*Different use case of asterisk:*<br>
<br>
I know from the perspective of using asterisk as an all in one sip<br>
proxy, it makes non-sense to support both dtls/sdes on the same<br>
endpoint. How come we use different encryption for the same endpoint in<br>
and out? and how to determine which encryption should we use while outgoing?<br>
<br>
But I know there are lots of users not use asterisk as an all-in-one sip<br>
server, we just use it as a solid trunk to connect to pstn world or do<br>
the transcoding stuff.<br>
<br>
<br>
*TL;DR*<br>
<br>
For the backward-compatibility to the huge amount of old-school devices<br>
which may still alive in a decade, can we add a new argument "optional"<br>
to media_encryption option?<br>
</blockquote>
<br>
It should be possible to do this in the code. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
it means it can accept any encryption of the incoming, and if we want to<br>
restrict, we still can reject it in extensions based on our logic.<br>
<br>
To avoid conflict that " How we determine the outgoing if we set to<br>
'optional'", maybe it can split media_encryption into "IN" and "OUT",<br>
ex: "in_media_encryption", "out_media_encryption", and it will not be<br>
confused.<br>
<br>
*p.s. *<br>
<br>
out_media_encryption is an default value to me though. we can use syntax<br>
for example:<br>
<br>
exten => s,n,Set(pjsipoutgoing=outgoing-no-encrypt/sip:)<br>
exten => s,n,Set(pjsipoutgoing=outgoing-sdes-encrypt/sip:)<br>
exten => s,n,Set(pjsipoutgoing=outgoing-dtls-encrypt/sip:)<br>
<br>
to determine which encryption should we use or not based on our user<br>
database, so I don't mind which encryption was set for outgoing. I<br>
always do it in specific way when outgoing.<br>
</blockquote>
<br>
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.<br>
<br>
Cheers,<br>
<br>
-- <br>
Joshua Colp<br>
Digium, Inc. | Senior Software Developer<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - US<br>
Check us out at: <a href="http://www.digium.com" rel="noreferrer" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" rel="noreferrer" target="_blank">www.asterisk.org</a><br>
<br>
<br>
<br>
<br>_______________________________________________<br>
--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--" rel="noreferrer" target="_blank">http://www.api-digital.com--</a><br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br></div></div></div>