stun/turn/ice学习笔记

stun基本只是用于client探测NAT之后靠近stun server的外网地址，本身不包含应用数据通信的功能，其底层STUN协议通信多是基于UDP的。多个端点之间相互通过信令通道拿到彼此的NAT外网地址之后，就可以进行直接的P2P通，但可能因路由防火墙的规格太严格导致直接P2P通信不成功。

turn是扩展了stun功能，除了类似stun可是实现NAT外网侧地址探测之外，也实现了基于中继转发实现应用数据通信，其底层通信可以基于UDP或TCP，多基于UDP，（rfc5766也建议基于UDP）。由于turn包含了stun的功能，自然是可以实现类似stun时的直接的P2P通信。类似可能因路由防火墙的原因直接的P2P通信不成功，可以使用turn的中继转发来实现两个端点之间的间接通信。

中继转发模式时，两个端点间的通信始终需要turnserver参与，turnserver对此实施了权限管理。
1，首先每个端点链接到turnserver后，需要通过turnserver的身份认证之后才能进行后续操作，认证方式是向turnserver提供预先分配的realm/用户名／密码等信息。此步骤在 STUN Alloc Request中执行。在响应消息中中会得到turnserver返回的mapped addr和relay addr。
2，第一步的身份认证通过之后，若想向其他的端点发送数据，则需要先向turnserver申请发送许可，此步骤需要提供目标端点的relay地址。此步骤在STUN CreatePermission request中执行。
3，之后即可以STUN Data Indication消息形式向turnserver发送应用数据，目的地址为目标端点的relay地址。为进一步减小包头开销，可以进一步向turnserver申请通道绑定，将当前turn中继会话与turnserver的一个通道相关联，后续和turnserver以ChannelData的方式通信，其包头开销小很多。

以上可见STUN/TURN是已经提供了基本可用的通信机制，实际可优先采用STUN P2P直接的通信方式，但可能不通，继而需要改用TURN中继。因此就需要初始的连通性协商检查过程，而此过程都是类似的，ICE的作用正是可以替我们完成这个探测协商过程，并且还提供了双方身份确认的功能。

在pjnath实现中，ICE具体的数据收发由STUN UDP P2P／TURN中继来完成，每个STUN UDP P2P／TURN数据通道在内部用transport表示，而对应应用层的每一路数据流用component表示，其各自的都分配一个id，后续通过ice会话进行数据收发时都需要按需指定这些id值。