RFC3581-关于rport字段 的阅读笔记(一)

RFC3581-关于rport字段 的阅读笔记(一)

1. 背景：

         SIP提供给客户端服务器收到来自客户端请求的IP地址，这个源IP地址被放在”received”参数中传送，它 放

于响应的顶端头字段中。对NAT穿越有很大作用。

    但有很多情况下，仅一个ip地址信息还不够，还有需要端口信息。于是有了第二步扩展，也可以称作平完善。

2.      引出讨论主题：在via头字段中增加了一个新的参数”rport”，它允许服务器回应客户端到源ip和端口，类

    似 于”received”，只是它包括的是端口，而received包括的是ip地址。

3.       客户端行为

1)   客户端可以包含”rport”参数，但它一定没有值 ，作为一个标志，来向服务器表明这种扩展在传送数据

    的过程中是被支持的。

2)   Keep binding fresh

     UDP NAT绑定的超时时间是一分钟，然而，INVITE传送可能会花费大量的时间去完成，结果可能会导致

回应被收到前绑定过期，为了保证绑定新鲜，客户端每20S左右重传一次INVITE消息。

3)    重传周期问题

如果NAT绑定周期大于1分钟，则客户端的请求重传间隔应增大至其一半;

如果NAT绑定周期小于1分钟，则客户端的请求重传间隔应减小至其一半。

   

4.     服务器端行为：

   端口号赋值给”rport”,这类似于”received”参数赋值，即使”sent-by”中包括ip。注意这一处理完全独立于

传输协议。

     服务器端的回应必须从收到请求的ip和port发送以穿越对称的NATS，当一个服务器正在多个端口或者接口

上监听请求时，它需要记住某个请求是从哪个端口收到的。这对于有状态的代理来说，事务期间存储此信

息不成问题。然而，一个无状态代理并不能存储请求和响应之间的状态信息，因此不能记住所收到请求的ip

和port，但为了实现此功能，无状态代理可以封装一个请求的目的地址和port到它所插入的via头字段中。当

一个响应到达时，它可以提取此信息并用它来发送回应。