本文主要是介绍客户端错误应答4XX，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

        服务端或UAS使用这类应答来说明所收到的请求是无法完成的。特定的客户端错误应答，或某些特定的头域，可以向UAC说明错误的性质以及应该如何重新格式化请求。UAC如果没有基于应答修改请求消息，就不应该重发请求。但是，同一请求可以发给不同的地方继续尝试。代理分支处理时收到4xx应答不会终止搜索。通常，客户端错误应答需要用户干预，才能生成新的请求。

400 Bad Request

        说明服务端不能理解请求消息。比如说，请求中缺少诸如To, From, Call-ID, 或 Cseq之类的必要头域。UAS收到同一Call-ID的多个INVITE请求(非重传)时，也用这个应答码处理。

 401 Unauthorized

        说明请求消息要求用户先执行鉴权。它通常是由UA发的，因为代理要求鉴权发的是407 Proxy Authentication Required。注册服务器是一种例外的场景，处理没有携带证书的REGISTER消息时，它回的是401 Unauthorized。以下是一个401消息实例：

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP proxy.globe.example.com:5060;branch=z9hG4bK2311ff5d.1;received=192.0.2.1;rport=3213
Via: SIP/2.0/UDP 173.23.43.1:5060;branch=z9hG4bK4545
From: <sip:explorer@geographic.example.org>;tag=341323
To: <sip:printer@maps-r-us.example.com>;tag=19424103
From: Copernicus <sip:copernicus@globe.example.com>;tag=34kdilsp3
Call-ID: 1g23hj45m678a7
CSeq: 1 INVITE
WWW-Authenticate: Digest realm=”globe.example.com”,nonce=”8eff88df84f1cec4341ae6e5a359”, qop=”auth”,opaque=””, stale=FALSE, algorithm=MD5
Content-Length: 0

消息中的WWW-Authenticate头域是必要的，它让UA有机会用正确的凭据进行响应。SIP中典型的鉴权交换是通过摘要处理流程实现的。注意：后续的INVITE请求应当使用原始请求的Call-ID，有些场景，如果改变Call-ID会导致鉴权失败。

402 Payment Required

SIP定义中，这是一个为将来保留的状态码。可以用它来协商通话完成的费用。

 403 Forbidden

这个应答拒绝一条请求并且不向对方提供任何资源。在服务器已经理解请求，并且请求格式正确的前提下，不希望继续提供服务可以用这个应答。要求鉴权时不能用403应答。

 404 Not Found

这个应答说明请求的Request-URI中所指定的用户目前不能定位，或者该用户当前没有登录。

405 Method Not Allowed

这个应答说明服务端或UA已经收到请求，也能够理解请求内容，但是能完成请求内容。例如向UA发注册请求。应答中必须包含Allow头域，它通知UAC局点能够接受的方法。它与收到未知方法的场景不同，对于未知方法，返回501 Not Implemented应答。注意：除非请求目标是一个代理服务器(Request-URI 指向一个代理服务器URI)，否则代理应当转发它不认识的请求。

406 Not Acceptable

这个应答说明因为不能满足请求消息中的要求，所以UAS不能处理。UAS不支持请求消息中Accept头域指定的内容。

407 Proxy Authentication Required

这个应答由代理发出，说明UAC必须先执行代理要求的鉴权流程才能继续。应答中应当有Proxy-Authenticate头域说明代理的鉴权凭据。UAC应该根据正确的Proxy-Authorization凭据重新发起请求。和HTTP不同，代理不能用它对另一个代理鉴权。

SIP/2.0 407 Proxy Authorization Required
Via: SIP/2.0/UDP discrete.sampling.example.com:5060;branch=z9hG4bK6563;received=65.64.140.198;rport=17234
From: Shannon <sip:shannon@sampling.example.com>;tag=59204
To: Schockley <sip:shockley@transistor.example.com>;tag=142334
Call-ID: adf8gasdd7fld
CSeq: 1 INVITE
Proxy-Authenticate: Digest realm=”sampling.example.com”, qop=”auth”, nonce=”9c8e88df84df1cec4341ae6cbe5a359”,opaque=””, stale=FALSE, algorithm=MD5
Content-Length: 0

408 Request Timeout

请求超时，如果INVITE请求携带Expires头域，并且它指定的时间超时时返回这个应答。代理服务器或UA都可以生成这个应答。UAC可以在随后任意时刻重试请求，或许可以尝试延长Expires头域指定的等待时间，或者干脆去掉Expires头域。有状态代理在请求事务超时后可以返回408给UAC而不必等待接收最终应答。

409 Conflict

这个状态码在RFC 2543中定义，但RFC 3261中已经被删除。它说明由于请求冲突，不能继续处理请求消息。注册服务器用它拒绝有冲突操作参数的注册请求，这个参数也已经被废弃。

410 Gone

这个应答与404 Not Found类似，但它还暗示以后该用户在当前局点都不能继续提供服务了。当用户取消某种服务业务之后可以用这个应答。

411 Length Required

这个应答码由RFC 2543定义，但在RFC 3261已经废弃。代理可以用它拒绝携带消息体但是没有Content-Length头域的请求。以UDP接收，然后以TCP转发请求的代理可以生成这个应答，因为在TCP传输中，Content-Length的用法更为严格。但是对于UDP传输的请求来说，这个应答的作用不大，因为根据数据报长度很容易计算出包体的长度(缺省认为数据报结束处就是包体结束点)。对于TCP之类面向流的传输来说，就没那么容易了。这时如果没有Content-Length头域，那么会导致无限制地读取消息体，继而触发513 Message Too Large应答，似乎411 Length Required也没有多大用途。

412 Conditional Request Failed

RFC 5839添加这个应答码是为了处理条件SIP发布。PUBLISH请求的2xx应答中会包含一个SIP-ETag头域，其内称为实体标签(entity tag)。后续发布的更新请求中会携带SIP-If-Match头域，其内容就是之前2xx应答中返回的实体标签。如果事件状态合成器中所存储的实体标签中没有与请求的SIP-If-Match的标签匹配的条目，那么它返回412 Conditional Request Failed应答。发布状态的UA收到这个应答，它就知道自己所保留的实体标签已经不再合法。因此，它必须重新发起一个PUBLISH流程。

413 Request Entity Too Large

代理服务器可以用这个应答拒绝消息体过大的请求。遇到拥塞的代理可以临时生成这个应答以节省处理大请求的时间。

414 Request-URI Too Long

这个应答说明请求中的Request-URI太长了，在当前节点处理不了。SIP规范中并没有定义Request-URI的最大长度。

415 Unsupported Media Type

这个应答由UA发出，它说明INVITE请求中指定的媒体类型是不支持的。比如说：向一个只处理电话呼叫的PSTN网关发起视频会议请求。应答中可以携带一些辅助头域，以帮助UAC重新格式化请求。

416 Unsupported URI Scheme

当UAS接收到请求时发现Request-URI是自己不认识的URI方案时，返回416 Unsupported URI Scheme应答。比如说，如果Request-URI中包含安全SIP(sips)方案，但代理不支持，这时它返回416应答。由于所有SIP元素都必须支持sip方案，UAC可以用sip URI替代，然后重试。

417 Unknown Resource Priority

请求中包含Require: resource-priority头域指定扩展，但是Resource-Priority头域指定的值是未知的，那么应当回应417 Unknown Resource Priority(RFC 4412)。417应答中可以携带Accept-Resource-Priority头域，用它说明可接受的列表。既可以不带Require: resource-priority头域重试请求，也可以从Accept-Resource-Priority中选择一个值放入Resource-Priority头域(这时Require不能少) 。

420 Bad Extension

这个应答说明Require或Proxy-Require头域中所指定的扩展在代理或UA侧是不支持的。这个应答应当包含一个Supported头域，说明当前支持的扩展。UAC可以选择不使用Require扩展特性重试，或者改用其它代理或UA。

421 Extension Required

421 Extension Required应答说明服务端要求使用某个扩展来处理请求，但它并没有在请求的Supported头域中找到相应的扩展说明。要求使用的扩展应当用Required头域描述。客户端可以在Supported头域中增加相关的扩展描述然后重试，也可以换个不要求扩展的服务器。

422 Session Timer Interval Too Small

(RFC 4028)用422 Session Timer Interval Too Small应答拒绝包含Session-Expires头域的请求(指定的时间太短)。拒绝短时间请求的能力，有助于防止过多的re-INVITE或UPDATE交互。它要求携带Min-SE头域来说明最小的时间限制。请求方可以不带Session-Expires头域重试，或者根据应答消息另选一个合适的时间间隔重试。

 423 Interval Too Brief

423 Interval Too Brief这个应答一般是由注册服务器发出的(RFC 4028)，它用于拒绝注册时长太短的注册请求。应答中必须包含Min-Expires头域，它说明注册服务器能接受的最小注册时长。客户端注册时长太短会加剧不必要的刷新请求。这个应答让注册服务器有了一个防患手段。

424 Bad Location Information

当请求中提供的定位信息格式错误或不能解析时，代理服务器或UA都可以回424 Bad Location Information应答(RFC 6442)。它必须包含Geolocation-Error头域以提供进一步的失败信息。

428 Use Identity Header

428 Use Identity Header 应答由需要使用增强SIP 身份的UAS发出(RFC 4474)。收到应答之后，应当添加Identity头域包含SIP消息选定部分的签名信息，然后重新发送。

429 Provide Referror Identity

429 Provide Referror Identity 应答要求Referred-By头域附带一个合法的Referred-By安全令牌并重发（RFC 3892）。安全令牌以S/MIME格式的消息体携带。这个错误消息的接收方(接收并接受REFER的UA)应当把这个要求通过NOTIFY消息转发给原始REFER的提交方。然后，REFER的提交方生成Referred-By令牌并包含在REFER消息中，由REFER接收方把令牌信息拷贝到触发请求中。

430 Flow Failed

430 Flow Failed应答是SIP出局NAT穿越扩展的组成部分（RFC 5626）。边缘代理服务器用它说明请求中UA对应的流已经丢失(保活失败或超时)。然后，代理应使用其它可用的流ID重新发送请求。这个方法允许UA通过多个代理服务器进行注册。

433 Anonymity Disallowed

433 Anonymity Disallowed应答说明请求因匿名而失败(RFC 5079)。匿名可能是因为URI或From头域里的显示名无效；也可能是因为存在请求隐私的Privacy头域，这个头域提供和种类似于PSTN中的匿名呼叫拒绝服务。

436 Bad Identity-Info Header

436 Bad Identity-Info应答说明无法从Identity-Info头域访问URI(RFC 4474)。Identity-Info头域的URI用于检索私钥相关的证书，这个私钥用于增强SIP身份安全性，生成Identity头域中的签名。

437 Unsupported Certificate

用Identity-Info头域获取的证书不能验证Identity头域中的签名时，可以回复437 Unsupported Certificate应答（RFC 4474）。可能的原因包括证书过期；不是由信任的证书颁发机构(CA)颁发的，或者其它原因。

438 Invalid Identity Header

438 Invalid Identity Header应答说明identity头域里的身份签名与消息不匹配（RFC 4474）。这个说明受到攻击；或者会话边际控制器(Session Border Controller (SBC))或应用层网关(Application Layer Gateway (ALG))之类的中间服务器修改了信令内容。

439 First Hop Lacks Outbound Support

注册服务器用439 First Hop Lacks Outbound Support应答向尝试使用SIP出局扩展的UA说明边缘代理服务器不支持该机制，所以不能使用这类扩展机制（RFC 5626）。

440 Max Breadth Exceeded

440 Max Breadth Exceeded应答说明由于并发分支太多而无法执行分支代理操作（RFC 5393）。这是解决分支代理服务器的放大漏洞扩展的一部分。具体的攻击和防御信息请参考（RFC 5079）。当Max-Breadth计数器归零时，返回440 Max-Breadth Exceeded。

469 Bad Info Package

469 Bad Info Package response应答说明Info包类型不支持（RFC 6086）。应答中将包含Recv-Info头域说明UAS支持哪些包。

 494 Security Agreement Required

用494 Security Agreement Required应答拒绝包含Require: sec-agree头域的请求请求，作为安全协议机制的组成部分（RFC 3329）。

470 Consent Needed

470 Consent Needed应答用于拒绝URI列表中至少有一个元素要求批准的请求（RFC 5360）。要求批准的元素将在Permission-Missing头域中携带。

480 Temporarily Unavailable

这个应答说明请求已经抵达正确的宿端，但基于某种原因被叫方不能处理。为了让呼叫方更好地了解情况，应当适当地修改原因短语说明。这个应答可以携带Retry-After头域来说明什么时候可以恢复。比如，当关闭电话铃音或启用免打扰功能时可以用它。重定向服务器也可以发480应答。

481 Dialog/Transaction Does Not Exist

这个应答说明收到一个呼叫或事务的消息，但服务端没有相关的状态信息记录。

482 Loop Detected

这个应答说明请求出现环路情况，代理之前转发的请求又被路由回来了。每个转发请求的代理服务器在请求的顶端添加一条Via头域，地址指向它自身。Via头域中携带branch参数，它是Request-URI、To、From、Call-ID和Cseq序列号组合的消息摘要(哈希)。如果请求有分支处理，那么branch参数要加上附加信息。如果Request-URI有变化，那么允许消息路由回来，这时必须检查branch参数。在呼叫前转业务里就可能会出现这种情况。这时Via头域将以branch参数不同来区分。

483 Too Many Hops

这个应答说明请求转发的次数已经达到Max-Forwards头域所限定的值。这是通过请求中的Max-Forwards: 0头域值判断的。在下面的实例中，UAC在REGISTER请求中携带Max-Forwards: 4。之后第五跳代理返回483应答。

REGISTER sip:registrar.timbuktu.example.com SIP/2.0
Via: SIP/2.0/UDP 201.202.203.204:5060;branch=z9hG4bK45347.1
Via: SIP/2.0/UDP 198.20.2.4:6128;branch=z9hG4bK917a4d4.1
Via: SIP/2.0/UDP 18.56.3.1:5060;branch=z9hG4bK7154.1
Via: SIP/2.0/TCP 101.102.103.104:5060;branch=z9hG4bKa5ff4d3.1
Via: SIP/2.0/UDP 168.4.3.1:5060;branch=z9hG4bK676746
To: sip:explorer@geographic.example.org
From: <sip:explorer@geographic.example.org>;tag=341323
Call-ID: 67483010384
CSeq: 1 REGISTER
Max-Forwards: 0
Contact: sip:explorer@national.geographic.example.org
Content-Length: 0

SIP/2.0 483 Too Many Hops
Via: SIP/2.0/UDP 201.202.203.204:5060;branch=z9hG4bK45347.1
Via: SIP/2.0/UDP 198.20.2.4:6128;branch=z9hG4bK917a4d4.1
Via: SIP/2.0/UDP 18.56.3.1:5060;branch=z9hG4bK7154.1
Via: SIP/2.0/TCP 101.102.103.104:5060;branch=z9hG4bKa5ff4d3.1
Via: SIP/2.0/UDP 168.4.3.1:5060;branch=z9hG4bK676746
To: <sip:explorer@geographic.example.org>;tag=a5642
From: <sip:explorer@geographic.example.org>;tag=341323
Call-ID: 67483010384
CSeq: 1 REGISTER
Content-Length: 0

484 Address Incomplete

这个应答说明Request-URI里的地址不完整。在PSTN网络对接时，可以用它实现逐位拨号(overlap dialing)功能，网关一位一位地接收号码并组装，直到号码收集完整后路由。注意后续INVITE请求中的Call-ID应当与原始请求的保持一致。下图展示了逐位拨号的信令流程。

485 Ambiguous

这个应答说明Request-URI不明确，必须澄清才能处理。如果用户名与多个注册条目匹配就可能会出现这种场景。如果用Contact头域返回可能匹配的选择，那么它的作用类似于300 Multiple Choices应答。然而它们还是稍微有点区别的，3xx返回的是同一用户的选择，但4xx应答可以返回不同用户的选择。3xx应答可以在没有人机交互的条件下自动处理，但4xx应答通常要求人为选择，因此反它归入客户端错误一类。配置返回这个应答的服务器必须考虑注册隐私。否则，恶意的UA可以使用模糊的Request-URI尝试来发现用户注册的sip或sips URI。

486 Busy Here

这个应答说明UA此时此地不能接受呼叫。这与600 Busy Everywhere应答不同，600说明所有可能的地方都是忙碌的，不能接受新的请求。除非明确知道不能联系上终端用户，通常486 Busy Here是由UAS发出的。这个应答和PSTN里的忙音是等价的。

487 Request Terminated

UA收到CANCEL请求取消未完成的INVITE请求时回这个应答。对于CANCEL，回一个200 OK来确认，487是响应INVITE的。

488 Not Acceptable Here

这个应答说明拟建立会话的某些内容是不可接受的，可以携带头域明确说明原因。这个应答类似于606 Not Acceptable，但它只适用于单点说明，606是全局说明。

 489 Bad Event

489 Bad Event应答可用于拒绝订阅或通知消息，说明UAS不支持请求中的Event包类型（RFC 6665）。如果订阅请求中没有指定Event包，假设服务端不支持PINT协议，也可以回489。

491 Request Pending

491 Request Pending应答用于解决dialog参与双方同时发re-INVITE的意外场景。因为两个INVITE都试图改变会话状态，所以它们不能同时处理。当一个UA在等待re-INVITE的最终应答时，它收到的任何re-INVITE请求都必须回复491。这类似于电话中的“眩光”状态，即两端同时占用中继。SIP中的重试算法是由UA生成一个延时(根据UA是否是初始INVITE发起者决定，在一个范围内随机选择时间窗口)，然后假定没有在这期间内收到re-INVITE，那么重试re-INVITE。通过这种方式，其中一方将赢得”比赛条件并处理重新邀请。下图是一个流程实例图。

 493 Request Undecipherable

493 Request Undecipherable应答说明因为无法获取公钥导致S/MIME消息体不能解密。如果UAS不支持S/MIME，那么应答消息中不携带消息体。如果UAS支持S/MIME，那么应答中携带消息体，消息体包含UAC用于S/MIME加密的公钥主体。

494 Security Agreement Required

用494 Security Agreement Required应答拒绝包含Require: sec-agree头域的请求请求，作为安全协议机制的组成部分（RFC 3329）。

这篇关于客户端错误应答4XX的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！