SIP消息格式描述

        SIP消息有两种：客户机到服务器的请求(Request),服务器到客户机的响应(Response)。

        SIP消息由一个起始行(start—line)、一个或多个字段(field)组成的消息头、一个标志消息头结束的空行(CRLF)以及作为可选项的消息体(message body)组成。其中，描述消息(messagebody)的头称为实体头(entityheader),其格式如下：
generic-message = start-line
*message-header
CRLF
[message-body ]

        起始行分请求行(Request-Line)和状态行(Status-Line)两种，其中请求行是请求消息 的起始行，状态行是响应消息的起始行。

        消息头分通用头(general-header)、请求头(request-header)、响应头(response-header) 和实体头(entity-header) 4种。

1.SIP请求消息

请求消息的格式如下：
Request = Request-Line
*( general-header
I request-header
I entity-header)
CRLF
[message-body ]

请求行(Request-Line)以方法(method)标记开始，后面是Request-URI和协议版本 (SIP-Version),最后以回车键结束，各个元素间用空格键字符间隔。

Request-Line = Method SP Request-URI SP SIP-Version CRLF

SIP用术语“method”来对说明部分加以描述，Method标识是区分大小写的。

Method = "INVITE" I "ACK" I "OPTIONS" I "BYE" I "CANCEL" I "REGISTER" | "INFO"

SlP定义了以下几种方法(methods)：
1）INVITE
        INVITE方法用于邀请用户或服务参加一个会话。在INVITE请求的消息体中可对被叫方被邀请参加的会话加以描述，如主叫方能接收的媒体类型、发出的媒体类型及其一些参数；对INVITE请求的成功响应必须在响应的消息体中说明被叫方愿意接收哪种媒体，或者说明被 叫方发出的媒体。
服务器可以自动地用200 (OK)响应响应会议邀请。
2）ACK
        ACK请求用于客户机向服务器证实它已经收到了对INVITE请求的最终响应。ACK只和 INVITE请求一起使用。对2xx最终响应的证实由客户机用户代理发出，对其他最终响应的证 实由收到响应的第一个代理或第一个客户机用户代理发出。ACK请求的To, From, Call-ID, CSeq字段的值由对应的INVITE请求的相应字段的值复制而来。
3）OPTIONS
        用于向服务器查询其能力。如果服务器认为它能与用户联系，则可用一个能力集响应 OPTIONS请求；对于代理和重定向服务器只要转发此请求，不用显示其能力。OPTIONS的From、To分别包含主被叫的地址信息，对OPTIONS请求的响应中的From、 To (可能加上tag参数)、Call-ID字段的值由OPTIONS请求中相应的字段值复制得到。
4）BYE
        用户代理客户机用BYE请求向服务器表明它想释放呼叫。BYE请求可以像INVITE请求那样被转发，可由主叫方发出也可由被叫方发出。呼叫的一方在释放(挂断)呼叫前必须发出BYE请求，收到BYE请求的这方必须停止发送媒体流 给发出BYE请求的一方。
5）CANCEL
        CANCEL请求用于取消一个Call-ID, TO, From和CSeq字段值相同的正在进行的请求，但取消不了已经完成的请求（如果服务器返回一个最终状态响应，则认为请求已完成）。CANCEL请求中的Call-ID、To、Cseq的数字部分及From字段和原请求的对应字段值相同，从而使CANCEL请求与它要取消的请求匹配。
6）REGISTER
REGISTER方法用于客户机向SIP服务器注册列在To字段中的地址信息。
REGISTER请求消息头中各个字段的含义定义如下：
• To:含有要创建或更新的注册的地址记录。
• From:含有提出注册的人的地址记录。
• Request-URI:注册请求的目的地址，地址的域部分的值即为主管注册者所在的域，而主机部分必须为空。一般，Request-URI中的地址的域部分的值和To中的地址的域部分的值相同。
• Call-ID:用于标识特定客户机的注册请求。来自同一个客户机的注册请求至少在相同重启周期内Call-ID字段值应该相同；用户可用不同的Call-ID值注册不同的地址，后面的注册请求将替换前面的所有请求。
• CSeq: Call-ID字段值相同的注册请求的CSeq字段值必须是递增的，但次序无关系， 服务器并不拒绝无序请求。
• Contact:此字段是可选项；用于把以后发送到TO字段中的URI的非注册请求转到 Contact字段给出的位置。如果请求中没有Contact字段，那么注册保持不变。
• Expires:表示注册的截止期。
7）INFO
INFO方法是对SIP协议的扩展，用于传递会话中产生的与会话相关的控制信息，如ISUP 和ISDN信令消息，有关此方法的使用还有待标准化，详细内容参见IETF RFC 2976。
8）其他扩展
其他扩展的含义如下：
• re-INVITE:用来改变参数；
• PRACK:与ACK作用相同，但是用于临时响应；
• SUBSCRIBE:该方法用来向远端端点预定其状态变化的通知；
• NOTIFY:该方法发送消息以通知预定者它所预定的状态的变化；
• UPDATE:允许客户更新一个会话的参数而不影响该会话的当前状态；
• MESSAGE:通过在其请求体中承载即时消息内容实现即时消息；
• REFER:其功能是指示接受方通过使用在请求中提供的联系地址信息联系第三方。

2. SIP响应消息

响应消息格式如下：
Response = Status-Line
*（ general-header
I response-header
I entity-header )
CRLF
[message-body ]

状态行(Status-Line)以协议版本开始，接下来是用数字表示的状态码(Status-Code)及 相关的文本说明，最后以回车键结束，各个元素间用空格字符(SP)间隔，除了在最后的CRLF 序列中，这一行别的地方不许使用回车或换行字符。

Status-Line = SIP-version SP Status-Code SP Reason-Phrase CRLF

SIP协议中用三位整数的状态码(Status Code)和原因码(Reason Code)来表示对请求做 出的回答。状态码用于机器识别操作，原因短语(Reason-Phrase)是对状态码的简单文字描述, 用于人工识别操作，一个客户端并不要求一定要显示或者解释这个Reason-Phrase。其格式如下：

Status-Code = 1xx (Informational) I 2xx (Success) I 3xx (Redirection) I 4xx (Client-Error)
I 5xx (Server-Error) I 6xx (Global-Failure) I extension-code

状态码的第一个数字定义响应的类别，在SIP/2.0中第一个数字有6个值，定义如下：
• 1xx(Informational):请求已经收到、继续处理请求。
• 2xx(Uccess):行动已经成功地收到，理解和接受。
• 3xx(Redirection):为完成呼叫请求，还须采取进一步的动作。
• 4xx(Client Error):请求有语法错误或不能被服务器执行。客户机需修改请求，然后再 重发请求。
• 5xx(ServerError):服务器出错，不能执行合法请求。
• 6xx(Global Failure):任何服务器都不能执行请求。
其中，1xx响应为暂时响应(Provisional response)，其他响应为最终响应(Final Response)

3. SIP消息头字段

SIP协议的消息头定义与HTTP在语法规则和定义上很相似。每个头字段都遵循以下格式: 首先是字段名(Field Name),字段名不分大小写，后面是冒号；然后是字段值，字段值与冒号间可有多个前导空格(LWS)。其格式如下：

message-header = field-name ":" [ field-value ] CRLF field-name = token
field-value = *( field-content ILWS )
1）通用消息头(Generahheader)
通用头字段适用于请求消息和响应消息，包含的字段有：
general-header = Accept
I Accept-Encoding
I Accept-Language
I Call-ID
I Contact
I CSeq
I Date
I Encryption
I Expires
I From
I Organization
I Record-Route
I Timestamp
I To
I User-Agent
I Via

接下来，介绍通用头字段中各字段的含义：

• Accept, Accept-Encoding和Accept-Language字段用于客户机在请求消息中给出其可接受的响应的媒体类型、编码方式以及描述语言。用于服务器在415响应(请确认)中 表明其可理解的请求消息的媒体类型、编码方式以及描述语言。
• Call-ID字段：用于惟一标识特定遨请或某个客户机的注册请求，一个多媒体会议可产 生多个Call-ID不同的呼叫。
• Contact字段：给出一个URL,用户可以与此URL建立进一步的通信。
• CSeq字段：用于标识服务器发出的不同请求，若Call-ID值相同，那么CSeq值必须各不相同。
• Date字段：反映首次发出请求或响应消息的时间，重发的消息与原先的消息有相同的 Data字段值。
• Encryption字段：表明内容经过了加密处理，这种加密为端到端的加密。
• Expire字段：它给出消息内容截止的日期和时间。
• From字段：所有消息中都必须有From字段，此字段给出请求的发起者。
• Organization字段：它给出发出请求或响应消息的实体所属的组织的名称。
• Record-Route字段：它给出一个全局可到达的Request-URI,用于标识代理服务器。
• Time-Stamp字段：给出客户机向服务器发出请求的时间。
• To字段：所有消息中都必须有To字段，此字段给出请求的目的收方。
• User-Agent字段：含有与发起请求的用户代理客户机有关的信息。
• Via字段：它给出请求消息迄今为止经过的路径。

2）实体头(Entity-header)

实体头字段用于定义与消息体相关的信息。包含的字段有：
entity-header = Content-Encoding
I Content-Length
I Content-Type

接下来，介绍实体头字段中各个字段的含义：
• Content-Encoding字段：表明消息体上添加应用的内容编码方式。
• Content-Length字段：表明消息体的大小。
• Content-Type字段：表明消息体的媒体类型。

3）请求头(Request-header)

请求头字段用于客户机上传附加信息到服务器，其中包括有关请求和客户机本身的信息。 包含的字段有：
request-header = Authorization
I Contact
I Hide
I Max-Forwards
I Priority
I Proxy-Authorization
I Proxy-Require
I Route
I Require
I Response-Key
I Subject

接下来，介绍请求头字段中各个字段的含义：
• Authorization字段：用于用户代理向服务器鉴定自身身份。
• Hide字段：用于客户机表明其希望向后面的代理服务器或用户代理隐藏由Via字段构成的路径。
• Max-Forwards字段：表明请求消息允许被转发的次数。
• Priority字段：用于客户机表明请求的紧急程度。
• Priority-Authorization字段：用于客户机向要求身份认证的代理服务器表明自身身份。
• Proxy-Require字段：用于标识出代理必须支持的代理敏感特征。
• Route字段：决定请求消息的路由。
• Require字段：用于客户机告诉代理服务器为了让服务器正确处理请求,客户机希望服 务器支持的选项。
• Response-Key 用于给出被叫方用户代理加密响应消息所采用的密钥需满足的要求。
• Su可ect字段：提供对呼叫的概述或表明呼叫的性质，可用于呼叫过滤。

4）响应头(Response-header)

响应头字段用于服务器向Request-URI指定的地址传送有关响应的附加信息。包含的字段有：response-header = Allow
I Proxy-Authenticate
I Retry-After
I Server
I Unsupported
I Warning
I WWW-Authenticate

接下来，介绍响应头字段中各个字段的含义：

• Proxy-Authenticate字段：必须为407响应的一部分：字段中的值给出适用于 Request-URI的代理的认证体制和参数。
• Retry-Afta•字段：可用于503响应中，向发出请求的客户机表明服务预计多久以后可 以启用，用于404、600、603响应中表明被叫方何时才有空。
• Server字段：含用户代理服务器处理请求所使用的软件信息。
• Unsuppoted字段：列出服务器不支持的特征。
• Warning字段：用于传递与响应状态有关的附加信息。
• WWW-Authenticate字段：含于401响应中，指出适用于Request-URI的认证体制和参数。.

各种头使用场合，每一种头都有相应的使用场合，具体如下表所示。

Header field	where	proxy	ACK	BYE	CAN	INV	OPT	REG
Accept	R			o		o	m*	0
Accept	2xx					0	m*	o
Accept	415			c		c	c	c
Accept-Encoding	R			0		0	o	0
Accept-Encoding	2xx					0	m*	.0
Accept-Encoding	415			c		c	c	c
Accept-Language	R			o		O	O	o
Accept-Language	2xx					O	M*	0
Accept-Language	415			c		C	C	c
Alert-Info	R	ar				O
Alert-Info	180	ar				O
Allow	R			0		O	O	o
Allow	2xx			0		m*	m*	o
Allow	r			0		O	0	0
Allow	405			m		m	M	m
Authentication-Info	2xx			0		O	O	o
Authorization	R		o	0	o	o	O	o
CaU-ID	c	r	m	M	M	M	M	m
CaU-Info		ar				O	O	0
Contact	R		O			M	0 .	0
Contact	lxx					0
Contact	2xx					M	o	o
Contact	3xx	d	-	0		0	o	0
Contact	485		-	0	-	O	0	0

Header field	where	proxy	ACK	BYE	CAN	INV	OPT	REG
Content-Disposition			0	O		O	O	O
Content-Encoding			o	O		O	O	o
Content-Language			o	O		O	O	o
Content>Length		Ar	t	t	t	T	T	t
Content-Type			*	*		*	*	*
CSeq	c	r	m	m	m	m	M	m
Date		a	0	O	o	0	O	o
Error-Info	300〜699	a		0	O	O	O	o
Expires						O		0
From	c	r	m	m	M	M	M	m
In-Reply-To	R					0
Max-Forwards	R	amr	m	m	m	M	M	m
Min>Expires	423							m
MIME-Wrsion			o	O		o	O	o
Organization		ar				o	O	0
Priority	R	ar			-	O	-	-
Proxy” Authenticate	407	ar	-	m	-	m	M	m
Proxy- Aulhenticate	401	ar	-	0	0	o	O	0
Proxy- Authorization	R	Dr	0	0	-	O	O	0
Proxy-Require	R	ar		0	-	O	O	o
Record-Route	R	ar	o	0	0	O	O	-
Record-Route	2xx 18x	mr	-	o	o	0	o	-
Reply-To					-	o		-
Require		ar	-	c		c	c	c
Retiy-After	404 413 480 486			o	o	0	o	0
	500 503		-	o	0	o	o	0
	600 603		-	0	0	O	o	0
Route	R	adr	C	c	c	c	c	c
Server	r			0	o	0	0	0
Subject	R					0		-
Supported	R		-	0	0	m*	o	o

Header field	where	proxy	ACK	BYE	CAN	INV	OPT	REG
Supported	2xx			0	0	m*	m*	0
Timestamp			o	o	o	0	0	o
To	c(l)	r	M	m	m	m	M	m
Unsupported	420			m		m	M	m
User-Agent			0	0	o	0	0	0
Via	R	amr	m	m	m	m	M	m
Via	rc	dr	m	m	m	m	M	m
Warning	r			o	o	o	O	0
WWW-Authenticate	401	ar		m		m	M	m
WWW-Authenticate	407	ar	-	o	-	o	o	0

        其中，Where栏表示头可使用的地方，当为R时，表示仅可用在请求中；为[时，表示仅可用 在响应中；为c时，表示将头从请求复制到响应中。
        Proxy栏描述代理对头采取的操作，当为a时，表示如果没有头，代理可以增加头；为m 时，表示代理可以修改头；为d表示代理可以删除头；为I•表示代理必须能读此头，所以此头不能加密。
        接下来六栏中的c表示根据具体消息来决定是否需要头，m表示必须要头；ni*表示应该发送头，但是在没有头的情况下，仍应能接收消息；o表示头可选；t表示应该发送头，但是在没有头的情况下，仍应能接收消息，如果使用基于流的协议(如TCP)作为传输协议，则必须发送头；*表示如果消息体非空，需要此头；■表示头不可用。

4、SIP应答消息状态码与功能

类型 状态码 状态说明
临时应答(1XX) 100 Trying 正在处理中
180 Ringing 振铃
181 call being forwarder 呼叫正在前向
182 queue 排队
181* session progress 会话进行

会话成功(2XX) 200 OK 会话成功

重定向(3XX) 300 multiple 多重选择
301 moved permanently 永久移动
302 moved temporaily 临时移动
305 use proxy 用户代理
380 alternative service 替代服务

请求失败(4XX) 400 bad request 错误请求
401unauthorized 未授权
402 payment required 付费要求
403 forbidden 禁止
404 not found 未发现
405 method no allowed 方法不允许
406 not acceptable 不可接受
407 proxy authentication required 代理需要认证
408 request timeout 请求超时
410 gone 离开
413 request entity too large 请求实体太大
414 request-url too long 请求URL太长
415 unsupported media type 不支持的媒体类型
416 unsupported url scheme 不支持的URL计划
420 bad extension 不良扩展
421 extension required 需要扩展 
423 interval too brief 间隔太短
480 temporarily unavailable 临时失效
481 call/transaction does not exist 呼叫/事务不存在
482 loop detected 发现环路
483 too many hops 跳数太多
484 address incomplete 地址不完整
485 ambiguous 不明朗
486 busy here 这里忙
487 request terminated 请求终止
488 not acceptable here 这里请求不可接受
491 request pending 未决请求
493 undecipherable 不可辨识

服务器失败(5XX) 500 server internal error 服务器内部错误
501 not implemented 不可执行
502 bad gateway 坏网关
503 service unavailable 服务无效
504 server time-out 服务器超时
505 version not supported 版本不支持
513 message too large 消息太大

全局性错误(6XX) 600 busy everywhere 全忙
603 decline 丢弃
604 does not exist anywhere 不存在
606 not acceptable 不可接受

5、SIP应答代码(这个是详细的应答码解释)

应答码是包含了，并且扩展了HTTP/1.1应答码。并不是所有的HTTP/1.1应答码都适当应用，只有在折里指出的是适当的。其他HTTP/1.1应答码不应当使用。并且，SIP也定义了新的应答码系列，6xx。

1 临时应答1xx 
临时应答，也就是消息性质的应答，标志了对方服务器正在处理请求，并且还没有决定最后的应答。如果服务器处理请求需要花200ms以上才能产生终结应答的时候，它应当发送一个1xx应答。 
注意1xx应答并不是可靠传输的。他们不会导致客户端传送一个ACK应答。临时性质的（1xx）应答可以包含消息体，包含会话描述。 
1.1 100 Trying 
这个应答表示下一个节点的服务器已经接收到了这个请求并且还没有执行这个请求的特定动作（比如，正在打开数据库的时候）。这个应答，就像其他临时应答一 样，种植了UAC重新传送INVITE请求。100(Trying)应答和其他临时应答不同的是，在这里，它永远不会被有状态proxy转发到上行流中。 
1.2 180 Ringing 
UA收到INVITE请求并且试图提示给用户。这个应答应当出世化一个本地回铃。 
1.3 818 Call is Being Forwarded(呼叫被转发) 
服务器可以用这个应答代码来表示呼叫正在转发到另一个目的地集合。 
1.4 182 Queued 
当 呼叫的对方暂时不能接收呼叫的时候，并且服务器决定将呼叫排队等候，而不是拒绝呼叫的时候，那么就应当发出这个应答。当被叫方一旦恢复接收呼叫，他会返回 合适的终结应答。对于这个呼叫状态，可以有一个表示原因的短语，比如：”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指定的域上不存在。当Request-URI的domain和接收这个请求的domain不匹配的情况下， 也会产生这个应答。 
4.6 405 Method Not Allowed 
服务器支持Request-Line中的方法，但是对于这个Request-URI中的地址来说，是不允许应用这个方法的。 
应答必须包括一个Allow头域，这个头域包含了指定地址允许的方法列表。
4.7 Not Acceptable 
请求中的资源只会导致产生一个在请求中的Accept头域外的，内容无法接收的错误。 
4.8 407 Proxy Authentication Required 
这个返回码和401（Unauthorized）很类四，但是标志了客户端应当首先在proxy上通过认证。SIP对认证的访问请参见26节和22.3节。 
这个返回码用于应用程序访问通讯网关（比如，电话网关），而很少用于被叫方要求认证。 
4.9 408 Request Timeout 
在一段时间内，服务器不能产生一个终结应答，例如，如果它无法及时决定用户的位置。客户端可以在稍后不更改请求的内容然后重新尝试请求。 
4.10 410 Gone 
请求的资源在本服务器上已经不存在了，并且不知道应当把请求转发到哪里。这个问题将会使永久性的。如果服务器不知道，或者不容易检测，这个资源消失是临时性质的还是永久性质的，那么应当返回一个404（Not Found）。 
4.11 413请求实体过大。 
服务器拒绝处理请求，因为这个请求的实体超过了服务器希望或者能够处理的大小。这个服务器应当关闭连接避免客户端重发这个请求。 
如果这个情况是暂时的，那么服务端应当包含一个Retry-After头域来表明这是一个暂时的故障，并且客户端可以过一段时间再次尝试。 
4.12 414 Request-URI Too Long 
服务器拒绝这个请求，因为Request-URI超过了服务器能够处理的长度。 
4.13 415 Unsupported Media Type 
服务器由于请求的消息体的格式本服务器不支持，所以拒绝处理这个请求。这个服务器必须根据内容的故障类型，返回一个Accept，Accpet-Encoding,或者Accept-Language头域列表。UAC根据8.1.3.5节定义的方法处理这个应答。 
4.14 416 Unsupported URI Scheme 
服务器由于不支持Request-URI中的URI方案而终止处理这个请求。客户端处理这个应答参照8.1.3.5。 
4.15 Bad Extension 
服务器不知道在请求中的Proxy-Require(20.29)或者Require(20.32)头域所指出的协议扩展。服务器必须在Unsupported头域中列出不支持的扩展。UAC处理这个应答请参见8.1.3.5 
4.16 421Extension Required 
UAS需要特定的扩展来处理这个请求，但是这个扩展并没有在请求的Supported头域中列出。具有这个应答码的应答必须包含一个Require头域列出所需要的扩展。 
UAS不应当使用这个应答除非它真的不能给客户端提供有效的服务。相反，如果在Support头域中没有列出需要的扩展，服务器应当根据基准的SIP兼容的方法和客户端支持的扩展来进行处理。 
4.17 423 Interval Too Brief 
服务器因为在请求中设置的资源刷新时间（或者有效时间）过短而拒绝请求。这个应答可以用于注册服务器来拒绝那些Contact头域有效期过短的注册请求。这个应答的用法和相关的Min-Expires头域在10.2.8,10.3,20.23节中介绍和说明。 
4.18 480 Temporarily Unavailable 
请求成功到达被叫方的终端系统，但是被叫方当前不可用（例如，没有登陆，或者登陆了但是状态是不能通讯，或者有”请勿打扰”的标记）。应答应当在Retry-After中标志一个合适的重发时间。这个用户也有可能在其他地方是有效的（在本服务器中不知道）。Reason-Phrase(原因短句)应当提示更详细的原因，为什么被叫方暂时不可用。这个值应当是可以被UA设置的。状态码486（Busy Here）可以用来更精确的表示本请求失败的特定原因。 
这个状态码也可以是转发服务或者proxy服务器返回的，因为他们发现Request-URI指定的用户存在，但是没有一个给这个用户的合适的当前转发的地址。 
4.19 481 Call/Transaction Does Not Exist 
这个状态表示了UAS接收到请求，但是没有和现存的对话或者事务匹配。 
4.20 482 Loop Detected 
服务器检测到了一个循环(16.3/4) 
4.21 483 Too Many Hops 
服务器接收到了一个请求包含的Max-Forwards(20.22)头域是0 
4.22 484 Address InComplete 
服务器接收到了一个请求，它的Request-URI是不完整的。在原因短语中应当有附加的信息说明。这个状态码可以和拨号交叠。在和拨号交叠中，客户端不知道拨号串的长度。它发送增加长度的字串，并且提示用户输入更多的字串，直到不在出现484（Address Incomplete）应答为止。 
4.23 485 Ambiguous 
Request-URI是不明确的。应答可以在Contact头域中包含一个可能的明确的地址列表。这个提示列表肯囊个在安全性和隐私性对用户或者组织造成破坏。必须能够由配置决定是否以404（NotFound）代替这个应答，又或者禁止对不明确的地址使用可能的选择列表。 
给带有Request-URI的请求的一个应答例子： 
sip: lee@example.com: 
SIP/2.0 485 Ambiguous 
Contact: Carol Lee <sip:carol.lee@example.com> 
Contact: Ping Lee <sip:p.lee@example.com> 
Contact: Lee M.Foote <sips:lee.foote@example.com> 
部分email和语音邮箱系统提供了这个功能。这个状态码和3xx状态码不同：对于300来说，它是假定同一个人或者服务有不同的地址选择。所以对3xx来说，自动选择系统或者连续查找就有效，但是对485（Ambiguous）应答来说，一定要用户的干预。 
4.24 486 Busy Here 
当成功联系到被叫方的终端系统，但是被叫方当前在这个终端系统上不能接听这个电话，那么应答应当回给呼叫方一个更合适的时间在Retry-After头域重试。这个用户也许在其他地方有效，比如电话邮箱系统等等。如果我们知道没有其他终端系统能够接听这个呼叫，那么应当返回一个状态码600（Busy Everywhere）。 
4.25 487 Request Terminated 
请求被BYE或者CANCEL所终止。这个应答永远不会给CANCEL请求本身回复。 
4.26 488 Not Acceptable Here 
这个应答和606（Not Acceptable）有相同的含义，但是只是应用于Request-URI所指出的特定资源不能接受，在其他地方请求可能可以接受。 
包含了媒体兼容性描述的消息体可以出现在应答中，并且根据INVITE请求中的Accept头域进行规格化（如果没有Accept头域，那么就是application/sdp）。这个应答就像给OPTIONS请求的200(OK)应答的消息体一样。 
4.27 491 Request Pending 
在同一个对话中，UAS接收到的请求有一个依赖的请求正在处理。14.2描述了这种情况应当怎样解决。 
4.28 493 Undecipherable 
UAS接收到了一个请求，包含了一个加密的MIME,并且不知道或者没有提供合适的解密密钥。这个应答可以包含单个包体，这个包体包含了合适的公钥，这个公钥用于给这个UAS通讯中加密包体使用的。细节描述在23.2节。 
5 Server Failure 5xx 
5xx应答是当服务器本身故障的时候给出的失败应答。 
5.1 500 Server Internal Error 
服务器遇到了未知的情况，并且不能继续处理请求。客户端可以显示特定的错误情况，并且可以在几秒种以后重新尝试这个请求。 
如果这个情况是临时的，服务器应当在Retry-After头域标志客户端过多少秒钟之后重新尝试这个请求。

5.2 501 Not Implemented 
服务器没有实现相关的请求功能。当UAS不认识请求的方法的时候，并且对每一个用户都无法支持这个方法的时候，应当返回这个应答。（proxy不考虑请求的方法而转发请求）。 
注意405（Method Not Allowed）是因为服务器实现了这个请求方法，但是这个请求方法在特定请求中不被支持。 5.3 502 Bad Gateway 
如果服务器，作为gateway或者proxy存在，从下行服务器上接收到了一个非法的应答（这个应答对应的请求是本服务器为了完成请求而转发给下行服务器的）。 
5.4 503 Service Unavailable 
由于临时的过载或者服务器管理导致的服务器暂时不可用。这个服务器可以在应答中增加一个Retry-After来让客户端重试这个请求。如果没有Retry-After指出，客户端必须就像收到了一个500（Server Internal Error）应答一样处理。 
客户端（proxy或者UAC）收到503（Service Unavailable）应当尝试转发这个请求到另外一个服务器处理。并且在Retry-After头域中指定的时间内，不应当转发其他请求到这个服务器。 
作为503(Service Unavaliable)的替代，服务器可以拒绝连接或者把请求扔掉。 
5.5 504 Server Time-out 
服务器在一个外部服务器上没有收到一个及时的应答。这个外部服务器是本服务器用来访问处理这个请求所需要的。如果从上行服务器上收到的请求中的Expires头域超时，那么应当返回一个408（Request TimeOut）错误。 
5.6 505 Version Not Supported 
服务器不支持对应的SIP版本。服务器是无法处理具有客户端提供的相同主版本号的请求，就会导致这样的错误信息。 
5.7 Message To Large 
服务器无法处理请求，因为消息长度超过了处理的长度。 
6 Global Failures 6xx 
6xx应答意味这服务器给特定用户有一个最终的信息，并不只是在Request-URI的特定实例有最终信息。 
6.1 600 Busy Everywhere 
成功联系到被叫方的终端系统，但是被叫方处于忙的状态，并不打算接听电话。这个应答可以通过增加一个Retry-After头域更明确的告诉呼叫方多久以后可以继续呼叫。如果被叫方不希望提示拒绝的原因，被叫方应当使用603（Decline）。只有当终端系统知道没有其他终端节点（比如语音邮箱系统）能够访问到这个用户的时候才能使用这个应答。否则应当返回一个486（Busy Here）的应答。
6.2 603 Decline 
当成功访问到被叫方的设备，但是用户明确的不想应答。这个应答可以通过增加一个Retry-After头域更明确的告诉呼叫方多久以后可以继续呼叫。只有当终端知道没有其他任何终端设备能够响应这个呼叫的势能才能给出这个应答。 
6.3 604 Does Not Exists Anywhere 
服务器验证了在请求中Request-URI的用户信息，哪里都不存在 
6.4 606 Not Acceptable 
当成功联系到一个UA,但是会话描述的一些部分比如请求的媒体，带宽，或者地址类型不被接收。 
606（NotAcceptable）应答意味着用户希望通讯，但是不能充分支持会话描述。606（Not Acceptable）应答可以在Warning头域中包含一个原因列表，用于解释为何会话描述不能被支持。警告原因代码在20.43节中列出。 
在应答中，可以出现一个包含媒体兼容性描述的消息体，这个消息体的格式根据INVITE请求中的Accept头域指出的格式进行规格化（如果没有Accept头域，那么就是application/sdp），就像给OPTIONS亲求的200(OK)应答中的消息一样。 
我们希望这些媒体协商不要经常需要，并且当一个新用户被邀请加入已经存在的会话的时候，这个媒体协商可能不需要。这取决于邀请的初始化者是否需要对606（Not Acceptable）进行处理。 
这个应答只有当客户端知道没有其他终端能够处理这个请求的时候才能发出。
 

整理参考：https://www.dsliu.com/wenti/5084.html
https://blog.csdn.net/ddhuangjiali/article/details/107811241