SIP

8/10/2019 SIP

# SIP

SIP 即(Session Initiation Protocol)

# 1、SIP是干啥的

  • SIP是一个应用层的信令控制协议
  • SIP用于创建、修改和释放一个或多个参与者的会话
  • 在基础上遵循RFC 3261

后续增补版本:

  • RFC 3262 对临时响应的可靠性作了规定。
  • RFC 3263 确立了 SIP代理服务器的定位规则。
  • RFC 3264 提供了提议/应答模型,
  • RFC 3265 确定了具体的事件通知

注意:

  • 1、SIP不是万能的。它既不是会话描述功能,也不提供增强的一些会话控制功能。
  • 2、为了描述消息内容的负载情况和特点,SIP 使用会话描述协议 (SDP) 来描述终端设备的特点。
  • 3、SIP 自身也不提供服务质量 (QoS),它与负责语音质量的资源保留设置协议 (RSVP) 互操作。
  • 4、它还与若干个其他协议进行协作,包括负责定位的轻型目录访问协议 (LDAP)、负责身份验证的远程身份验证拨入用户服务 (RADIUS) 以及负责实时传输的 RTP 等多个协议。

它不定义要建立的会话的类型,而只定义应该如何管理会话

# 2、SIP网络组件

SIP 会话使用多达四个主要组件:SIP 用户代理、SIP 注册服务器、SIP 代理服务器和 SIP 重定向服务器

# 用户代理

SIP 用户代理(UA) 是终端用户设备,如用于创建和管理 SIP 会话的移动电话、多媒体手持设备、PC、PDA 等。用户代理客户机发出消息。用户代理服务器对消息进行响应。

它是端点和SIP网络的最重要的网络元件之一。端点可以启动,修改或终止会话。 用户代理是SIP网络中最智能的设备或网络元件。它可以是软电话,移动电话或笔记本电脑。 用户代理在逻辑上分为两个部分 -用户代理客户端(UAC) - 发送请求并接收响应的实体。用户代理服务器(UAS) - 接收请求并发送响应的实体。 SIP基于客户端 - 服务器架构,其中呼叫者的电话充当发起呼叫的客户端,并且被叫者的电话充当响应呼叫的服务器。

# 注册服务器

SIP 注册服务器是包含域中所有用户代理的位置的数据库。在 SIP 通信中,这些服务器会检索出对方的 IP 地址和其他相关信息,并将其发送到 SIP 代理服务器。

# 代理服务器

SIP 代理服务器接受 SIP UA 的会话请求并查询 SIP 注册服务器,获取收件方 UA 的地址信息。然后,它将会话邀请信息直接转发给收件方 UA(如果它位于同一域中)或代理服务器(如果 UA 位于另一域中)。

它是从用户代理接收请求并将其转发给另一个用户的网络元素。基本上代理服务器的作用就像一个路由器。它具有一些智能来理解SIP请求并且在URI的帮助下向前发送它。 代理服务器位于两个用户代理之间。源和目标之间最多可以有70个代理服务器。有两种类型的代理服务器 -无状态代理服务器 - 它仅转发接收的消息。这种类型的服务器不存储呼叫或事务的任何信息。 状态代理服务器 - 此类型的代理服务器会跟踪收到的每个请求和响应,如果需要,将来可以使用它。如果没有来自另一方的响应,它可以重传请求。

# 重定向服务器

SIP 重定向服务器允许 SIP 代理服务器将 SIP 会话邀请信息定向到外部域。SIP 重定向服务器可以与 SIP 注册服务器和 SIP 代理服务器同在一个硬件上。

重定向服务器接收请求并在由注册器创建的位置数据库中查找请求的预期接收者。重定向服务器使用数据库获取位置信息,并以3xx(重定向响应)向用户作出响应。

# 3、SIP通过什么达到交互的目的

SIP通过以下逻辑功能来完成通信:

  • 用户定位功能:确定参与通信的终端用户位置。
  • 用户通信能力协商功能:确定参与通信的媒体终端类型和具体参数。
  • 用户是否参与交互功能:确定某个终端是否加入某个特定会话中。
  • 建立呼叫和控制呼叫功能:包括向被叫“振铃”、确定主叫和被叫的呼叫参数、呼叫重定向、呼叫转移、终止呼叫等。

SIP世界里面所有的SIP-UA全部平等

# 4、SIP包含那些信令/消息

SIP协议是一个Client/Sever协议,因此SIP消息分两种:请求消息和响应消息

# 核心消息

1、INVITE:

表示主叫用户发起会话请求,邀请其他用户加入一个会话。也可以用在呼叫建立后用于更新会话(此时该INVITE又称为Re-invite)。

INVITE用于发起与用户代理的会话。换句话说,INVITE方法用于在用户代理之间建立媒体会话。INVITE可以在消息正文中包含呼叫者的媒体信息。如果INVITE已经接收到成功响应(2xx)或者已经发送了ACK,则认为会话被建立。 成功的INVITE请求在两个用户代理之间建立对话,其继续,直到发送BYE以终止会话。在已建立的对话中发送的INVITE被称为re-INVITE。Re-INVITE用于更改会话特征或刷新对话框的状态。

2、ACK:客户端向服务器端证实它已经收到了对INVITE请求的最终响应。

3、BYE:表示终止一个已经建立的呼叫。 BYE是用于终止已建立的会话的方法。 这是一个SIP请求,可以由主叫方或被叫方发送以结束会话。它不能由代理服务器发送。BYE请求通常绕过代理服务器端到端路由。BYE不能发送到挂起的INVITE或未建立的会话。

4、CANCEL:表示在收到对请求的最终响应之前取消该请求,对于已完成的请求则无影响。 CANCEL用于终止未建立的会话。用户代理使用此请求取消之前发起的待处理呼叫尝试。它可以由用户代理或代理服务器发送。CANCEL是逐跳请求,即,它通过用户代理之间的元素并接收由下一个有状态元素产生的响应。

5、REGISTER:表示客户端向SIP服务器端注册列在To字段中的地址信息。 REGISTER请求执行用户代理的注册。此请求由用户代理发送到注册服务器。REGISTER请求可以被转发或代理,直到它到达指定域的权威注册器。 它在正在注册的用户的 To 头中携带AOR(记录地址)。REGISTER请求包含时间段(3600秒)。一个用户代理可以代表另一个用户代理发送REGISTER请求。  这称为第三方注册。 这里, From 标签包含代表 To 标头中标识的一方提交注册的一方的URI。

6、OPTIONS:表示查询被叫的相关信息和功能。 OPTIONS方法用于向用户代理或代理服务器查询其功能,并发现其当前可用性。 对请求的响应列出了用户代理或服务器的功能。 代理永远不会生成OPTIONS请求。

# 扩展消息

1、Subscribe

用户代理使用SUBSCRIBE来建立订阅,以获得关于特定事件的通知。 它包含一个Expires头字段,用于指示订阅的持续时间。 在该时间段过去之后,订阅将自动终止。 订阅在用户代理之间建立对话。 可以在到期时间之前在对话框中发送另一个SUBSCRIBE再次重新订阅。 将收到来自用户的订阅的200 OK。 用户可以通过发送另一个SUBSCRIBE方法取消订阅,Expires值为0(零)。

2、NOTIFY

NOTIFY用于由用户代理获取特定事件的发生。通常,当订阅者和通知者之间存在订阅时,NOTIFY将在对话框中触发。 每个NOTIFY将得到200 OK响应,如果它被通知器接收。 NOTIFY包含指示事件的Event头字段和指示订阅当前状态的subscriptionstate头字段。 NOTIFY总是在订阅的开始和终止时发送。

3、PUBLISH

PUBLISH由用户代理用于向服务器发送事件状态信息。 当有多个事件信息来源时,PUBLISH是最有用的。 PUBLISH请求类似于NOTIFY,除了它不是在对话框中发送。 PUBLISH请求必须包含Expires头字段和Min-Expires头字段。

4、REFER

REFER由用户代理使用来引用另一个用户代理来访问对话框的URI。 REFER必须包含Refer-To标题。这是REFER的必需标题。 REFER可以在对话框内部或外部发送。 A202已接受将触发REFER请求,其指示其他用户代理已接受引用。

5、INFO

INFO由用户代理用来向与其建立媒体会话的另一用户代理发送呼叫信令信息。 这是一个端到端的请求。 代理将始终转发INFO请求。

6、UPDATE

如果会话未建立,UPDATE用于修改会话的状态。用户可以使用UPDATE更改编解码器。 如果建立了会话,则使用重新邀请来改变/更新会话。

7、PRACK

PRACK用于确认接收到临时响应(1XX)的可靠传输。 通常,当客户端接收到包含RSeq可靠序列号和支持的:100rel头部的临时响应时,PRACK就会生成。 PRACK在rack标题中包含(RSeq plus; CSeq)值。 PRACK方法适用于所有临时响应,除了100 Trying响应,其从未可靠地传送。 PRACK可以包含消息体;它可以用于提供/应答交换。

8、MESSAGE

它用于使用SIP发送即时消息。IM通常包括从事文本会话的参与者实时交换的短消息。 MESSAGE可以在对话框内或对话框外发送。 MESSAGE的内容作为MIME附件在邮件正文中传送。 通常接收到200 OK响应以指示消息已在其目的地传送。

# 响应消息 (应答码)

  • 1、临时应答(1XX)
100 Trying 正在处理中
180 Ringing 振铃
181 call being forwarder 呼叫正在前向
182 queue 排队
183 session progress
1
2
3
4
5
  • 2、会话进行会话成功(2XX)
200 OK 
1
  • 3、会话成功重定向(3XX)
300 multiple 多重选择
301 moved permanently 永久移动
302 moved temporaily 临时移动
305 use proxy 用户代理
380 alternative service
1
2
3
4
5
  • 4、替代服务请求失败(4XX)
400 bad request 错误请求
401 unauthorized 未授权
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 不可辨识
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
  • 5、服务器失败(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 消息太大
1
2
3
4
5
6
7
  • 6、全局性错误(6XX)
600 busy everywhere 全忙
603 decline 丢弃
604 does not exist anywhere 不存在
606 not acceptable 不可接受
1
2
3
4

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

# 5、SIP交互过程

  • 1、注册交互
sequenceDiagram
SIP Client ->> SIP Server: REGISTER
SIP Server ->> SIP Client: 401 Unauthorized
SIP Client ->> SIP Server: REGISTER with auth info
SIP Server ->> SIP Client: 200OK
1
2
3
4
5
REGISTER sip:172.21.0.12:6060 SIP/2.0
Via: SIP/2.0/UDP 172.16.1.104:55704;branch=z9hG4bK-d87543-9a0e3753a00ed747-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:5000@171.223.209.177:55704;rinstance=ad2818fe362fecf7>;expires=0
To: "5000"<sip:5000@172.21.0.12:6060>
From: "5000"<sip:5000@172.21.0.12:6060>;tag=1b1b480b
Call-ID: ZjQ5ODRkMGQ0ZWQ5ODFjODUwYWZkY2ZmNzRmNTA4NmM.
CSeq: 7 REGISTER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: eyeBeam release 1011d stamp 40820
Authorization: Digest username="5000",realm="cc-ali-0",nonce="297ffbd2",uri="sip:118.89.247.39:6060",response="52d0dce5b82dd0bb37d9328d1e7afdba",algorithm=MD5
Content-Length: 0
1
2
3
4
5
6
7
8
9
10
11
12
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 172.16.1.104:55704;branch=z9hG4bK-d87543-9a0e3753a00ed747-1--d87543-;received=171.223.209.177;rport=55704
From: "5000"<sip:5000@172.21.0.12:6060>;tag=1b1b480b
To: "5000"<sip:5000@172.21.0.12:6060>;tag=as248a993f
Call-ID: ZjQ5ODRkMGQ0ZWQ5ODFjODUwYWZkY2ZmNzRmNTA4NmM.
CSeq: 7 REGISTER
Server: Asterisk PBX 11.25.3
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="cc-ali-0", nonce="6109745d"
Content-Length: 0
1
2
3
4
5
6
7
8
9
10
11
REGISTER sip:172.21.0.12:6060 SIP/2.0
Via: SIP/2.0/UDP 172.16.1.104:55704;branch=z9hG4bK-d87543-0615ba2d0975c620-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:5000@171.223.209.177:55704;rinstance=ad2818fe362fecf7>;expires=0
To: "5000"<sip:5000@172.21.0.12:6060>
From: "5000"<sip:5000@172.21.0.12:6060>;tag=1b1b480b
Call-ID: ZjQ5ODRkMGQ0ZWQ5ODFjODUwYWZkY2ZmNzRmNTA4NmM.
CSeq: 8 REGISTER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: eyeBeam release 1011d stamp 40820
Authorization: Digest username="5000",realm="cc-ali-0",nonce="6109745d",uri="sip:118.89.247.39:6060",response="3927e9db6247ffc0dee3489495d4c7ab",algorithm=MD5
Content-Length: 0
1
2
3
4
5
6
7
8
9
10
11
12
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.1.104:55704;branch=z9hG4bK-d87543-0615ba2d0975c620-1--d87543-;received=171.223.209.177;rport=55704
From: "5000"<sip:5000@172.21.0.12:6060>;tag=1b1b480b
To: "5000"<sip:5000@172.21.0.12:6060>;tag=as248a993f
Call-ID: ZjQ5ODRkMGQ0ZWQ5ODFjODUwYWZkY2ZmNzRmNTA4NmM.
CSeq: 8 REGISTER
Server: Asterisk PBX 11.25.3
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Expires: 0
Date: Thu, 28 May 2020 04:22:29 GMT
Content-Length: 0
1
2
3
4
5
6
7
8
9
10
11
12
  • 2、呼叫交互
sequenceDiagram
SIP Client A ->> SIP Server: INVITE Client B
SIP Server ->> SIP Client A: 401 UnAuthorized
SIP Client A ->> SIP Server: ACK
SIP Client A ->> SIP Server: INVITE Client B with Auth info
SIP Server ->> SIP Client A: 100 Trying
SIP Server ->> SIP Client B: INVITE Client B 
SIP Client B->> SIP Server: 100 Trying
SIP Client B->> SIP Server: 180 Ringing
SIP Client B->> SIP Server: 183 Progressing
SIP Client B->> SIP Server: 200 OK
SIP Server ->> SIP Client B: 200 OK ACK
SIP Server ->> SIP Client A: 200 OK
SIP Client A ->> SIP Server: 200 OK ACK
SIP Client A ->> SIP Server: RTP
SIP Server ->> SIP Client B: RTP
SIP Client B->> SIP Server: RTP
SIP Server ->> SIP Client A: RTP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

以下是测试环境拨打的一通完整通话并且有语音流的交互过程

INVITE sip:15620512945@172.21.0.12:6060 SIP/2.0
Via: SIP/2.0/UDP 172.16.1.104:24596;branch=z9hG4bK-d87543-77026317f96d5d23-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:20548871@171.223.209.177:24596>
To: "15620512945"<sip:15620512945@172.21.0.12:6060>
From: "20548871"<sip:20548871@172.21.0.12:6060>;tag=d727ba1a
Call-ID: NmM0ODc0NzlhOGIxMWRiMjk4NmYxYjQ5ZWMwZjI2MzY.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
User-Agent: eyeBeam release 1011d stamp 40820
Content-Length: 391
1
2
3
4
5
6
7
8
9
10
11
12
v=0
o=- 5 2 IN IP4 172.16.1.104
s=CounterPath eyeBeam 1.5
c=IN IP4 172.16.1.104
t=0 0
m=audio 29070 RTP/AVP 8 101
a=alt:1 3 : dGV5snlI J8Xw0UwG 169.254.134.75 29070
a=alt:2 2 : wStSQKpG MMZmrBte 169.254.28.105 29070
a=alt:3 1 : 1KV0KQEC WUfhBp9L 172.16.1.104 29070
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=x-rtp-session-id:917BE628B45D4E88A43FCEF44C136844
1
2
3
4
5
6
7
8
9
10
11
12
13

INVITE with auth


INVITE sip:15620512945@172.21.0.12:6060 SIP/2.0
Via: SIP/2.0/UDP 172.16.1.104:24596;branch=z9hG4bK-d87543-5271142036629861-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:20548871@171.223.209.177:24596>
To: "15620512945"<sip:15620512945@172.21.0.12:6060>
From: "20548871"<sip:20548871@172.21.0.12:6060>;tag=d727ba1a
Call-ID: NmM0ODc0NzlhOGIxMWRiMjk4NmYxYjQ5ZWMwZjI2MzY.
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
User-Agent: eyeBeam release 1011d stamp 40820
Authorization: Digest username="20548871",realm="cc-ali-0",nonce="0348d1f8",uri="sip:15620512945@118.89.247.39:6060",response="569f243d8630535f17f615678b1dcc4d",algorithm=MD5
Content-Length: 391
1
2
3
4
5
6
7
8
9
10
11
12
13
v=0
o=- 5 2 IN IP4 172.16.1.104
s=CounterPath eyeBeam 1.5
c=IN IP4 172.16.1.104
t=0 0
m=audio 29070 RTP/AVP 8 101
a=alt:1 3 : dGV5snlI J8Xw0UwG 169.254.134.75 29070
a=alt:2 2 : wStSQKpG MMZmrBte 169.254.28.105 29070
a=alt:3 1 : 1KV0KQEC WUfhBp9L 172.16.1.104 29070
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=x-rtp-session-id:917BE628B45D4E88A43FCEF44C136844
1
2
3
4
5
6
7
8
9
10
11
12
13

# 6、SIP消息体解析


MESSAGE HEADER BEGIN


INVITE sip:15620512945@172.21.0.12:6060 SIP/2.0
Via: SIP/2.0/UDP 172.16.1.104:24596;branch=z9hG4bK-d87543-5271142036629861-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:20548871@171.223.209.177:24596>
To: "15620512945"<sip:15620512945@172.21.0.12:6060>
From: "20548871"<sip:20548871@172.21.0.12:6060>;tag=d727ba1a
Call-ID: NmM0ODc0NzlhOGIxMWRiMjk4NmYxYjQ5ZWMwZjI2MzY.
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
User-Agent: eyeBeam release 1011d stamp 40820
Authorization: Digest username="20548871",realm="cc-ali-0",nonce="0348d1f8",uri="sip:15620512945@118.89.247.39:6060",response="569f243d8630535f17f615678b1dcc4d",algorithm=MD5
Content-Length: 391
1
2
3
4
5
6
7
8
9
10
11
12
13

MESSAGE HEADER END




MESSAGE BODY START


v=0
o=- 5 2 IN IP4 172.16.1.104
s=CounterPath eyeBeam 1.5
c=IN IP4 172.16.1.104
t=0 0
m=audio 29070 RTP/AVP 8 101
a=alt:1 3 : dGV5snlI J8Xw0UwG 169.254.134.75 29070
a=alt:2 2 : wStSQKpG MMZmrBte 169.254.28.105 29070
a=alt:3 1 : 1KV0KQEC WUfhBp9L 172.16.1.104 29070
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=x-rtp-session-id:917BE628B45D4E88A43FCEF44C136844
1
2
3
4
5
6
7
8
9
10
11
12
13

MESSAGE BODY END


# 6.1、SIP 请求和响应报头字段

  • Accept

Accept头字段用于在消息正文中指示可接受的消息Internet媒体类型。 标题字段描述使用通常在因特网中使用的格式类型/子类型的媒体类型。 如果不存在,则假定可接受的消息体格式为 application / sdp 。 媒体类型列表可以使用 q 值参数设置首选项。

  • Accept-Encoding

Accept-Encoding头字段用于指定可接受的消息体编码方案。 编码可以用于确保具有大消息体的SIP消息适合单个UDP数据报。 使用 q 值参数可以设置首选项。如果所列出的方案都不能被UAC接受,则返回406不可接受的响应。如果不包括,则假设的编码将是 text / plain 。

  • To

To 表示请求的最终收件人。UA生成的任何响应将包含此标头字段并添加标签。它是必需的头。 代理生成的任何响应必须在 To 头字段中添加标签。x To 头字段URI从不用于路由。

  • From

From 头字段表示请求的发起者。它是用于标识对话框的两个地址之一。 A From 头字段可以包含用于标识特定呼叫的标签。 它可以包含显示名称,在这种情况下,URI包含在<&gt ;. 它是必需的头。

  • Call-ID

Call-ID头字段在所有SIP请求和响应中是强制的。它用于唯一标识两个用户代理之间的呼叫。 呼叫ID在呼叫之间必须是唯一的。 用户代理的所有注册应使用相同的Call-ID。 Call-ID始终由用户代理创建,并且不会被服务器修改。 它是一个加密随机标识符。

  • Via

Via用于记录由有助于将响应路由回始发者的请求所采用的SIP路由。 生成请求的UA在Via头字段中记录其自己的地址。 转发请求的代理将Via头字段包含其自己的地址添加到Via头字段列表的顶部。 生成对请求的响应的代理或UA将请求中的所有Via报头字段按顺序复制到响应中,然后将响应发送到在顶部Via报头字段中指定的地址。 接收响应的代理检查顶部Via头字段并匹配其自身的地址。 如果不匹配,则响应已被丢弃。 然后删除顶部Via头字段,并将响应转发到在下一个Via头字段中指定的地址。
Via头字段包含协议名称,版本号和传输(SIP / 2.0 / UDP,SIP / 2.0 / TCP等),并且可以包含端口号和参数,例如接收的,rport,branch,maddr, b>和 ttl 。 如果UA或代理从与在顶部Via头字段中指定的地址不同的地址接收到请求,则将收到的标签添加到Via头字段。 分支参数通过UA和代理被添加到Via报头字段,其被计算为Request-URI的哈希函数,以及To,From,Call-ID和CSeq数。

  • CSeq

CSeq头字段是每个请求中所需的头字段。 它包含对每个请求增加的十进制数。 通常,对于每个新请求,除了 CANCEL 和 ACK 请求,它使用它所引用的INVITE请求的CSeq号,它增加1。 UAS使用CSeq计数来确定失序请求或区分新请求(不同CSeq)或重传(相同CSeq)。 CSeq头字段由UAC使用以匹配对其引用的请求的响应。 例如,发送INVITE请求然后发送CANCEL请求的UAC可以通过CSeq中的方法告知200OK响应,如果它是对邀请或取消请求的响应。

  • Contact

Contact头字段用于向其他用户传达关于请求发起者的地址。 一旦接收到联系人报头字段,URI可以被缓存并且用于在对话中路由未来的请求。 例如,在对INVITE的200OK响应中的联系人报头字段可以允许确认ACK消息和在该呼叫期间的所有未来请求绕过代理并直接去往被叫方。

  • Record-Route

Record-Route头字段用于强制路由通过代理以用于两个UA之间的会话(对话)中的所有后续请求。 通常,Contact头字段的存在允许UA直接绕过初始请求中使用的代理链来发送消息。 将其地址插入到记录 - 路由头部字段中的代理覆盖此并且迫使将来的请求包括包含强制该代理被包括的代理的地址的Route头字段。 希望实现此操作的代理将插入包含其自己的URI的头字段,或将其URI添加到已经存在的Record-Route头字段。 构造URI以便URI解析回代理服务器。 UAS将Record-Route头字段复制到对请求的200 OK响应中。 头字段由代理不变地转发回UAC。 然后,UAC存储记录 - 路由代理列表加上联系人头字段(如果在200OK中存在),以便在所有后续请求中的路由头字段中使用。

  • Organization

组织头字段用于指示消息的发起者所属的组织。 它也可以由代理插入,因为消息从一个组织传递到另一个组织。 与所有SIP报头字段一样,它可以由代理用于做出路由决定,并且由UA用于进行呼叫筛选决定。

  • Retry-After

它用于指示资源或服务何时可以再次可用。 在503服务不可用响应中,它指示服务器何时可用。 在404未找到,600 Busy Everywhere和603拒绝响应中,它指示被叫UA何时可以再次可用。 它包含以秒为单位的时间段。

  • Subject

可选的Subject头字段用于指示媒体会话的主题。 报头字段的内容也可以在提醒期间显示,以帮助用户决定是否接受呼叫。

Example:
    Subject: How are you?
    Supported
1
2
3

Supported头字段用于列出UA或服务器实现的一个或多个选项。 它通常包含在对OPTIONS请求的响应中。 如果未实现任何选项,则不包括头字段。 如果UAC列出了支持报头字段中的选项,代理或UAS可以在呼叫期间使用该选项。 如果必须使用或支持该选项,那么将使用Require头字段。

Example:
    Supported: rel100
1
2
  • Expires

Expires头字段用于指示请求或消息内容有效的时间间隔。 当存在于INVITE请求中时,报头字段在INVITE请求的完成时设置时间限制。 也就是说,UAC必须在该时间段内接收最终响应(非1xx),或者INVITE请求被408请求超时响应自动取消。 一旦建立会话,来自原始INVITE中的Expires头字段的值没有效果 - 为此目的必须使用Session-Expires头字段。 如果存在于REGISTER请求中,则头字段在Contact头字段中的URI上设置不包含 expires 参数的时间限制。 Expires也用于SUBSCRIBE请求中,以指示订阅持续时间。

Example:
    Expires: 30
1
2
  • User-Agent

该报头字段用于传送关于发起请求的UA的信息。

  • Authorization

授权报头字段用于将请求中的UA的凭证携带到服务器。 可以发送回复包含质询信息的 401未授权响应。

  • Content-Length

Content-Length 用于指示消息体中的八位字节数。 Content-Length:0表示没有消息体。

  • Content-Type

Content-Type 头字段用于指定邮件正文中的Internet媒体类型。 Content-Type 头字段用于指定邮件正文中的Internet媒体类型。... 如果此头字段不存在,则假定为application / sdp。 如果请求中存在Accept头字段,则响应Content-Type必须包含列出的类型,或者必须返回415不支持的媒体类型响应。 紧凑形式是 c 。

Example:
    Content-Type: application/sdp
1
2
  • Content-Encoding

Content-Encoding 头字段用于表示所列出的编码方案已应用于邮件正文。它允许UAS确定解释消息体所必需的解码方案。 仅可以使用在允许 - 编码头部字段中列出的那些编码方案。 紧凑形式是 e 。

Examples:
    Content-Encoding: text/plain
    e: gzip
1
2
3

# 7、SIP应答码解析

# 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>
1
2

部分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)进行处理。 这个应答只有当客户端知道没有其他终端能够处理这个请求的时候才能发出。

# SIP适用在哪里?

基本上SIP是一种应用层协议。它是用于创建和终止与一个或多个参与者的会话的简单网络信令协议。 SIP协议被设计为独立于底层传输协议,因此SIP应用可以在TCP,UDP或其他低层网络协议上运行。

通常,SIP协议用于两个或更多个端点之间的互联网电话和多媒体分发。 例如,一个人可以使用SIP发起到另一个人的电话呼叫,或者某人可以与许多参与者创建电话会议。 SIP协议被设计为非常简单,具有有限的命令集。 它也是基于文本的,因此任何人都可以读取在SIP会话中的端点之间传递的SIP消息。


收录时间: 2019-08-10

最后更新时间: 10/11/2021, 3:53:50 PM