呼叫的时候,那么就应当发出这个应答。当被叫方一旦恢复接收呼叫,他会返回合适的终结应答。对于这个呼叫状态,可以有一个表示原因的短语,比如:”5 calls queued;expected waiting time is 15minutes”。服务器可以给出好几个182(Queued)应答告诉呼叫方排队的情况(比如排队靠前了等等)。
1.5 183 会话进度
183(Session Progress)应答用于提示建立对话的进度信息。Reason-Phrase(表达原因的句子)、头域或者消息体可以用于提示呼叫进度的更消息的信息。
2 成功信息2xx
这个应答表示请求是成功的。
2.1 200 OK
请求已经处理成功。这个信息取决于不同方法的请求的应答。
3 转发请求3XX
3xx系列的应答是用于提示用户的新位置信息的,或者为了满足呼叫而转发的额外服务地点。
3.1 300 Multiple Choices
请求的地址有多个选择,每个选择都有自己的地址,用户或者(UA)可以选择合适的通讯终端,并且转发这个请求到这个地址。
应答可以包含一个具有每一个地点的在Accept请求头域中允许的资源特性,这样用户或者UA可以选择一个最合适的地址来转发请求。没有未这个应答的消息体定义MIME类型。
这些地址选择也应当在Contact头域中列出(20.10节)。不同于HTTP,SIP应答可以包含多个Contact头域或者一个Contact头域中具有一个地址列表。UA可以使用Contact头域来自动转发或者要求用户确认转发。不过,本规范没有定义自动转发的标准。
如果被叫方可以在多个地址被找到,并且服务器不能或者不愿意转发请求的时候,可以使用这个应答来给呼叫方。
3.2 301 Moved Permently
当不能在Request-URI指定的地址找到用户的时候,请求的客户端应当使用Contact头域(20.10)所指出的新的地址重新尝试。请求者应当用这个新的值来更新本地的目录,地
址本,和用户地址cache,并且在后续请求中,发送到这个/这些列出的地址。
3.3 302 Moved Temporarily
请求方应当把请求重新发到这个Contact头域所指出的新地址(20.10)。新请求的Request-URI应当用这个应答的Contact头域所指出的值。
在应答中的Expires(20.19节)或者Contact头域的expires参数定义了这个Contact URI的生存周期。UA或者proxy在这个生存周期内cache这个URI。如果没有严格的有效时见,那么这个地址仅仅本次有效,并且不能在以后的事务中保存。
如果cache的Contact头域的值失败了,那么被转发请求的Request-URI应当再次尝试一次。临时URI可以比超时时间更快的失效,并且可以有一个新的临时URI。
3.4 305 Use Proxy
请求的资源必须通过Contact头域中指出的proxy来访问。Contact头域指定了一个proxy的URI。接收到这个应答的对象应当通过这个proxy重新发送这个单个请求。305(UseProxy)必须是UAS产生的。
3.5 380 Alternative Service
呼叫不成工,但是可以尝试另外的服务。另外的服务在应答的消息体中定义。消息体的格式在这里没有定义,可能在以后的规范中定义。
4 请求失败4xx
4xx应答定义了特定服务器响应的请求失败的情况。客户端不应当在不更改请求的情况下重新尝试同一个请求。(例如,增加合适的认证信息)。不过,同一个请求交给不同服务器也许就会成功。
4.1 400 Bad Request
请求中的语法错误。Reason-Phrase应当标志这个详细的语法错误,比如”Missing Call-ID header field”。
4.2 401 Unauthorized
请求需要用户认证。这个应答是由UAS和注册服务器产生的,当407(Proxy Authentication Required)是proxy服务器产生的。
4.3 402 Payment Required
保留/以后使用
4.4 403 Forbidden
服务端支持这个请求,但是拒绝执行请求。增加验证信息是没有必要的,并且请求应当不被重试。
4.5 404 Not Found
服务器返回最终信息:用户在Request-URI指定的域上