OPTIONS请求的目标是用Request-URI指明的,这个既可以是一个UA也可以是一个SIP服务器。如果OPTIONS指向一个proxy服务器,Request-URI设置成为一个没有用户部分(userpart)的,类似REGISTER请求中的Request-URI一样。或者,一台服务器收到一个OPTIONS请求并且Max-Forwards头域值是0的时候,它就需要响应这个请求而不需要关心Request-URI的内容。
OPTIONS请求可以作为建立会话的一部分,用来查询对方的能力使用,这样在后续对话中可以使用双方兼容的方式。
1构造OPTIONS请求
Contact头域在OPTIONS请求中可以存在,也可以不存在。
对于一个OPTIONS请求的应答是假定是在原请求中的Request-URI范围内的。但是,仅当一个OPTIONS请求作为建立对话的一部分而发送的时候,后续的请求应当由收到并且响应这个OPTIONS请求的服务器进行处理。(就是说如果在建立会话的时候使用OPTIONS请求,那么OPTIONS之后的这些请求都应该由这个OPTIONS查询的服务器处理,这样才能保证使用的特性和OPTIONS查询出来的能力是一样的).
2处理OPTIONS请求
在一个对话中的OPTIONS请求会产生一个200(OK)的应答,这是和在对话外创建的并且对对话没有任何影响的请求相同。
如果OPTIONS请求的应答是由proxy服务器给出的,proxy返回一个200(OK)的应答,列出这个服务器的各种选项和能力。应答没有消息体 。
Allow,Accept,Accept-Encoding,Accept-Language,和Supported头域应当在200(OK)应答中出现。如果这个是由proxy产生的应答,那么Allow头域应当忽略,因为proxy是方法无关的(也就是说不知道该如何处理方法的)。
参考
RFC3261