某些4xx 响应码要求UA有特定的处理流程，这取决于method本身。如果收到一个401 （Unauthorized） 或407 （Proxy Authentication Required） 响应时，UAC应该遵从认证部分的处理流程Section 22.2 和 Section 22.3 重新通过请求获取安全消息。

　　如果收到一个413 （Request Entity Too Large）响应（Section 21.4.11），这个请求包含的消息体大于UAS能够接收的消息体时。如果可能的话，UAC应该重发这个请求，忽略这个消息体或者重发一个小一点的消息体。

　　在以上的例子中，请求重发都是通过创建一个新的请求，在新请求中需要做一定的必要的修改才能满足协商机制。这个新请求重构了一个新的事务，并且也应该和前面的请求具有同样的 Call-ID和To头值，但是CSeq 应该包含一个新的序列号码，这个新的序列号码高于前面的号码。

　　对于其他的4xx响应，还有其他没有被定义的响应，重发请求可能或者也不可能发生，这依赖于使用的method和用户使用场景。

　　当UAS处理一个请求处于dialog外部的请求（outside of a dialog）情况下的请求，规范规定了一系列的处理流程，这些流程独立于method。Section 12 给出了一个指导，指导说明了UAS如何通知请求是一个内部的还是outside of a dialog。

　　注意，这里的请求处理是非常恒定的。具体来说，如果接受了这样的请求，所有和此请求绑定的状态修改必须执行。如果拒绝了此请求，所有和此请求绑定的状态修改不能执行。

　　UASs应该根据以下步骤处理请求（开始认证处理，检查method，头域和以及本章节其他部分处理）。

　　一旦请求完成认证流程（或者跳过认证），UAS必须检查请求的method。如果UAS已经识别到method，但是不能支持请求的method的话，它必须生成一个405（Method Not Allowed）响应消息。生成此响应消息的处理流程在Section 8.2.6有介绍。UAS也必须对这个405响应消息增加一个Allow头。这个Allow头必须增加一个列表来表示UAS能够支持的methods列表。Allow 头的讨论在Section 20.5有讨论。如果服务器端可以支持其中一个method，则处理流程继续进行。

　　如果UAS不能理解请求中的一个头的话（规范中没有定义这个头域或规范不支持这个拓展头），服务器必须忽略这个头，继续处理消息。如果出现异常的头域，UAS应该忽略异常的头域值，这些头值对于进一步处理请求是没有必要的。

　　To头域定义请求的初始接收方，这里的请求是由在From头域中定义的用户发起。 因为可能有呼叫前转或其他代理的操作，初始接收方可能是或不是正在处理此请求的UAS。当这里的To头域不是UAS的确认身份时，UAS可以使用任何策略来决定它是否接受请求。

　　但是，规范推荐，UAS接受请求，即使它们不能识别To头域中的URI scheme（例如，一个tel:URL），或如果To头域不能处理这个UAS的已知的或当前用户。 如果，在另一方面，UAS决定拒绝这个请求，UAS应该生成一个响应消息和其响应状态码403 （Forbidden），并且返回这个响应码到服务器事务层的传输。

　　如果，Request-URI定义这个UAS，它来处理这个请求。 如果Request-URI使用的一个scheme不是这个UAS所支持的scheme，它应该拒绝这个请求，并且返回一个416 （Unsupported URI Scheme）响应消息。如果Request-URI没有定义一个地址，这个地址是UAS愿意为这个请求所接受的地址，它应该拒绝这个请求，并且返回一个404 （Not Found） 响应消息。典型环境下，一个UA会使用REGISTER method绑定它自己的address-of-record（aor）到一个具体的contact地址上，contact地址可以是多个地址形式。UA将会看到请求中的Request-URI 地址和contact地址相同。接收Request-URIs的其他潜在地址源包括请求的Contact头和由UA发送到响应地址源，这个响应地址源是创建或刷新dialogs的地址。

　　如果请求中的To头域中没有tag标签，UAS core必须对比检查请求的将要处理的事务。如果From tag， Call-ID，和CSeq 完全和将要处理的事务所关联的匹配，但是请求事务的话（匹配规则参见Section 17.2.3），UAS core 应该生成一个482 （Loop Detected）响应消息，然后把这个响应传递给这个服务器的事务层。

　　如果同样的请求，这些请求抵达UAS多于一次以上的话，这些请求是来自于不同的路径的话，原因可能是进行了分叉forking处理。这里的UAS处理第一个这样的请求，然后对其他请求返回响应482（Loop Detected）。

　　假设UAS决定处理请求中的符合规则的参数要素，如果Require头出现在当前的消息中，它会检查这个Require头域。

　　Require头的作用是UAC用来通知UAS关于SIP拓展的消息，UAC期望UAS支持这些SIP拓展，UAS能够正确处理这些请求中的SIP拓展。Require头的格式在Section 20.32章节中有进一步的描述。如果UAS不能理解Require头中列出的option-tag 列表的话，UAS必须返回一个生成的响应状态码 420（Bad Extension）。UAS必须添加一个 Unsupported 头，在这个Unsupported 头中列出UAS不能支持的拓展，这些拓展是请求中的Require 头所列出的拓展。

　　注意，Require 和 Proxy-Require 不能使用在SIP CANCEL请求中或ACK 请求，这里的ACK请求是发送给non-2xx响应消息的。如果这些头值出现在这些请求中时，它们必须要被忽略掉。

　　一个针对2xx响应的ACK请求必须仅包含那些出现在初始请求中的Require和Proxy-Require值。

　　客户端和服务器端能够互相理解双方所有可选参数值，规范所定义的流程可以确保客户端和服务器端的交互将会快速处理，无任何时延。如果双方参数中，一方不能理解对方的拓展时，处理流程放缓，例如上面的示例。因此，对于客户端和服务器端所支持的拓展都能完全匹配的场景中，交互处理流程会相对较快。如果需要保存一个双向处理，通常需要协商机制来完成。另外，当客户端需要支持的功能，但是服务器端不能理解此拓展功能的话，此头可以移除一些带歧义的拓展功能支持，例如呼叫处理方面的功能，这些功能可能仅是呼叫流程末端系统感兴趣的功能。

　　假设UAS理解所有客户端请求的拓展功能，然后UAS检查消息体的内容和头域。如果其中任何消息的类型（由Content-Type表示），语言（由Content-Language表示）或者 编码（由Content-Encoding表示）不能被支持，并且body 部分不是一个可选的值（由 Content-Disposition头表示），UAS必须拒绝这个请求，返回错误状态响应码415 （Unsupported Media Type）响应。这个响应必须包含一个Accept头的列表，列表表示UAS可以理解的消息体类型，在事件中包含UAS不能理解的消息体类型。如果UAS不能理解请求做包含的内容解码，UAS响应中必须包含一个UAS可接受的Accept-Encoding 头列表，列表中列出UAS所支持的解码方式。如果UAS不能理解请求的头中列出的支持的内容语言，响应中必须包含一个Accept-Language头，这个头列出UAS所支持的语言。除了检查以上这些类型以外，消息体处理还依赖于method和类型。更多关于具体内容头的处理，参考Section 7.4 ，还有 Section 20.11 到20.15。

　　未完继续……

　

　　　

　　关注微信公众号：asterisk-cn，获得有价值的Asterisk行业分享

　　Asterisk freepbx，FreeSBC技术文档：www.freepbx.org.cn

　　融合通信商业解决方案，协同解决方案首选产品：www.hiastar.com

　　Asterisk / FreePBX / FreeSBC中国合作伙伴，官方qq技术分享群（3000人）：589995817