[asterisk-dev] SRTP and forcing encrypted calls

[Kai Hoerner]

Terry Wilson wrote:
> The dialplan also needs to be able to set whether or not an outgoing call should be forced for encryption. Currently, I have it set up to use a new dialplan function (poorly named) ENCRYPT(). ENCRYPT(signaling)=1 or ENCRYPT(media=1) for storing on a datastore whether each should be forced to be encrypted. It has been suggested that instead, using CHANNEL() for this would be the way to go. So how does something like Set(CHANNEL(secure_bridge)=signaling|media|none) sound for setting whether bridged calls should be forced to be "secure". For reading whether a channel is "secure" having something like: CHANNEL(secure_signaling) and CHANNEL(secure_media)
>   

I dont see the reason why you use disparate keys for reading and writing 
the same values.
For writing you use "secure_bridge" with a list of signaling|media|none, 
and for reading you access "secure_media" and "secure_signaling".

What about "Set(CHANNEL(secure_media)=forced)" and 
"Set(CHANNEL(secure_signaling=forced)" if you want to force encryption?
I know its two application calls instead of one, but i would like to 
have getter and setter use the same name for clarity.

To "disforce" encryption on dialplan level (if it is forced on config 
level) one would need to set another value, e.g. "optional".

> Hangup cause 58 in this example is AST_CAUSE_BEARERCAPABILITY_NOTAVAIL which is what chan_sip and chan_iax2 use for codec negotiation issues. I'm open to other ideas for that as well.	
>   

I think that is not accurate. There are other codec negotiation issues 
than encryption mismatch.
In your example this is not critical, because the caller would not 
notice the mismatch between "(alaw|g726)" and "(ulaw|gsm)", he would 
just get a declined call.

But if the PBX informs the caller that the encryption has failed and 
asks if it should make the call unencrypted, that is misleading.

Nevertheless it is the best approach we have.


Kaii