通讯双方选择的加密指数是不公开的，应该相对较大，而且应该通过某种随即算法保证这个加密指数是变化的。其次，通讯双方每隔一定时间，应该申请更改私有密钥，以避免黑客获得太多的数据样本并破译通讯内容。
　　针对基本原理中提到的各个特征数据的长度，我们规定，用于生成密钥的加密指数至少应该达到12位，用于生成偏移量的加密指数建议选择8位，这样，六个加密指数的选择空间总和至少达到60位。
　　一般情况下，在客户端登录以前，客户端向服务器端发起DH交换请求报文，报告自己的6个DH特征值，服务器端收到请求以后，向用户发送自己的6个DH特征值，双方分别使用对方的DH特征值和自身的加密指数计算出私有密钥并生成最终的加密矩阵。虽然这一组报文是以明文方式传输的，但即便黑客得到了这些明文，也知道整套算法的所有细节，黑客也不足以形成这个私有密钥，这是使用DH交换的基本出发点。
　　对于媒体传输，通讯双方并不存在客户端和服务器的区分，这时我们要求，在通过信令完成RTP参数交换以后，双方各自在第一时刻发起DH交换请求，而且任何一方收到DH交换请求以后，立即向用户发送自己的DH特征值，从而建立起这个加密信道。

　　这里需要重点阐述一下加密指数。我们要求设备产生的加密指数是随机的、变化的，而且6个加密指数之间没有任何的联系。事实上，某些嵌入式设备根本不能产生随机数，当程序运行到某一条指令的时候，时钟是一个固定值，随机算法的种子是一个固定值，甚至各个寄存器也是一个固定值，用随机算法产生的下一个数据也是固定值。而对于PC环境，虽然时钟是变化的，有可能获得一个真正随机的种子，但使用rand()等函数获得的伪随机序列其实是一个固定序列。在程序启动的时候以及运行过程中，最好读一小段语音数据或者网路数据，以这些数据进行运算和组合，形成加密指数。

　　三、　程序接口
　　这里，我们仅仅给出基于UDP实现的相关协议(包括MGCP的全部信令、SIP的全部信令、H.323的部分信令、RTP媒体、RTCP媒体控制)的接口，而基于TCP实现的相关协议(H.323的部分协议)的接口将在其他文档中给出。
　　对于UDP传输，一般情况下，我们在每个设备上建立一个加密参数索引表，根据UDP发送端口、UDP接收端口和UDP接收地址(IP地址)进行索引。每次发送的时候，检查DH交换是否完成，如果没有完成，则主动放弃这个报文的发送，并发送DH交换请求报文;如果已经完成，则加密以后发送出去;每次接收的时候，检查DH交换是否完成，如果没有完成，检查这个报文是否为DH交换报文，尝试完成DH交换，并计算位交换矩阵和异或矩阵;如果已经完成，则按照DH交换报文特征进行过滤以后报告给应用程序。当然，在这个过程中，任何一个设备可以随时启动对任何一个连接的再次DH交换，并且在某个连接空闲一段时间以后关闭这个连接。

　　(在交换报文中，我们还需要定义一个叫做报文序号的变量，并强制规定这个需要不能为0。每个设备自行管理属于自己的报文序号。在发送交换报文的时候，设备应该把自己的报文序号和已经收到的对方的报文序号发送给对方;另外一方根据接收到的报文序号判断协商是否完成，或者是否开始了一次新的交换过程)
　　(这样实现，必然会丢弃信道建立初期的一到两个信令单元，但我们可以相信这并不会影响VoIP的实现。因为在SIP或者MGCP或者H.323的UDP信令传输过程中，已经通过重传报文规避了丢包风险;而RTP传输中，信道建立初期丢失几个报文几乎不会影响通讯质量。如果确实不允许丢弃报文，我们可以开辟少量的缓存空间，把这些报文保存下来，一旦DH交换完成，再把这些报文发送出去。)
　　我们重载操作系统中原来的UDP收发函数(一般命名为sendto、recvfrom或其他类似字样)，把发送函数定义成BEEO_sendto，把接收函数定义成BEEO_recvfrom，而接口函数中各个参数的定义完全相同于实际操作系统中相应函数的参数定义。这两个函数就是最基本的程序接口。