SIP消息头域的说明
SIP协议主要消息 (3)
SIP协议主要消息协议名称：SIP协议主要消息一、引言本协议旨在详细描述SIP（Session Initiation Protocol，会话初始协议）的主要消息，包括其定义、结构和功能。
SIP是一种用于建立、修改和终止多媒体味话的应用层协议，广泛应用于VoIP（Voice over Internet Protocol，互联网语音通信）和实时通信系统中。
二、协议概述SIP协议主要通过请求和响应的方式进行通信，使用文本格式的消息进行交互。
SIP消息由起始行、头部字段和消息体组成，其中起始行包含请求或者响应的方法、URI（Uniform Resource Identifier，统一资源标识符）和SIP版本信息。
头部字段包含了关于消息的元数据，而消息体则携带了具体的数据内容。
三、主要消息类型1. INVITE：该消息用于建立会话，发起方向被叫方发送INVITE请求，包含了被叫方的SIP地址和媒体描述信息。
2. ACK：该消息用于确认INVITE请求的接收，发起方在收到200 OK响应后发送ACK请求，表示会话建立成功。
3. BYE：该消息用于终止会话，可以由任意一方发送，对方收到BYE请求后会发送200 OK响应，表示会话终止。
4. CANCEL：该消息用于取销未完成的请求，普通用于取销INVITE请求，以便重新发起新的请求。
5. REGISTER：该消息用于注册用户地址，用户向服务器发送REGISTER请求，以便在服务器上注册自己的SIP地址。
6. OPTIONS：该消息用于查询服务器的能力，普通用于检测对方是否在线或者支持特定功能。
7. INFO：该消息用于传输非实时信息，如传输DTMF（Dual-tone Multi-frequency）信号等。
四、消息格式和示例1. INVITE消息格式：```INVITE sip:alice@example SIP/2.0Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK776asdhdsMax-Forwards: 70To: <sip:alice@example>From: <sip:bob@example>;tag=1928301774Call-ID: a84b4c76e66710CSeq: 314159 INVITEContact: <sip:bob@example>Content-Type: application/sdpContent-Length: 142v=0o=bob 2890844526 2890844526 IN IP4 192.0.2.1s=-c=IN IP4 192.0.2.1t=0 0m=audio 49172 RTP/AVP 0a=rtpmap:0 PCMU/8000```2. ACK消息格式：```ACK sip:alice@example SIP/2.0Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK776asdhds Max-Forwards: 70To: <sip:alice@example>From: <sip:bob@example>;tag=1928301774Call-ID: a84b4c76e66710CSeq: 314159 ACKContact: <sip:bob@example>Content-Length: 0```3. BYE消息格式：```BYE sip:alice@example SIP/2.0Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK776asdhds Max-Forwards: 70To: <sip:alice@example>From: <sip:bob@example>;tag=1928301774Call-ID: a84b4c76e66710CSeq: 314160 BYEContact: <sip:bob@example>Content-Length: 0```4. CANCEL消息格式：```CANCEL sip:alice@example SIP/2.0Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK776asdhds Max-Forwards: 70To: <sip:alice@example>From: <sip:bob@example>;tag=1928301774Call-ID: a84b4c76e66710CSeq: 314159 CANCELContact: <sip:bob@example>Content-Length: 0```5. REGISTER消息格式：```REGISTER sip:example SIP/2.0Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK776asdhds Max-Forwards: 70To: <sip:bob@example>From: <sip:bob@example>;tag=1928301774Call-ID: a84b4c76e66710CSeq: 314161 REGISTERContact: <sip:bob@example>Expires: 3600Content-Length: 0```6. OPTIONS消息格式：```OPTIONS sip:example SIP/2.0Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK776asdhds Max-Forwards: 70To: <sip:alice@example>From: <sip:bob@example>;tag=1928301774Call-ID: a84b4c76e66710CSeq: 314162 OPTIONSContact: <sip:bob@example>Content-Length: 0```7. INFO消息格式：```INFO sip:alice@example SIP/2.0Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK776asdhds Max-Forwards: 70To: <sip:alice@example>From: <sip:bob@example>;tag=1928301774Call-ID: a84b4c76e66710CSeq: 314163 INFOContact: <sip:bob@example>Content-Type: application/dtmf-relayContent-Length: 18Signal=1Duration=100```五、总结SIP协议的主要消息包括INVITE、ACK、BYE、CANCEL、REGISTER、OPTIONS和INFO。
Sip消息标题头及选择项备忘
Sip消息标题头及选择项备忘Branch:利用branch ID参数的唯一性作为事务的ID（transaction ID）,根据本标准产生的branch ID必须用”z9h64bK”开头。
Rport:路由器的UDP端口。
Expires:有效期Tag:作为一个通用的机制的一部分来唯一标志一个对话，用于SIP信令中"To" "From"标签中。
当一个用户代理第一次发起会话的request,它只在From中包含一个tag,To中没有。
当返回一个response后才在To中也包含一个tag。
之所以要使用tag，是因为一个request可能会建立多个Dialog所以不能单用Call-ID去区分Dialog.同时,生成的tag必须是唯一的，可以用一些加密算法生成一个32位随机数。
Supported:列举了UAC/UAS所支持的扩展。
100rea l：100rel扩展即是对中间状态响应的确认（即1xx的响应码）。
原先在sip里，只有针对invite请求的200ok响应才会有ack，那么当中间状态响应携带重要的会话参数信息时，例如183响应，客户端是否收到响应就没有ack请求了，于是就定义了prack这一请求消息，即对中间状态响应的确认请求。
当sip发送者支持这一扩展时，及在support头域增加这个100rel 消息，当server端给与1xx响应时，可以在头域里的require字段要求这一100rel的能力。
此时，sip发送者，发送prack消息。
GRUU:GRUU主张在全球路由使用者代理的URI的。
往往有情况下，一个单一的公共用户身份是共同的很多私人用户身份。
在这种情况下，传入会议的要求，是'岔'到终端的。
这分岔，可连续或并行。
有时候，可能有必要为了避免这种分杈的请求到多个终端的实例，我们可能需要请求发送到特定的终端，对于这种情况，我们需要支持GRUU.Update:Sip的UPDATE（RFC3311）消息是SIP扩展的一种机制，用以在通话尚未建立的时候更新媒体流状态的一种机制。
SIP协议主要消息
SIP协议主要消息协议名称：会话发起协议（Session Initiation Protocol，简称SIP）1. 引言本协议旨在规范会话发起协议（SIP）的主要消息格式和内容。
SIP是一种应用层协议，用于在IP网络上建立、修改和终止多媒体会话，如语音通话、视频会议和即时消息。
本协议的目的是确保SIP消息在各个实现之间的互操作性和一致性。
2. 消息格式SIP协议定义了以下主要消息类型：2.1 请求消息请求消息由客户端发送给服务器，用于请求资源或执行操作。
请求消息的格式如下：请求行头部字段空行消息体请求行包括请求方法、请求URI和SIP协议版本。
常见的请求方法包括INVITE（邀请对方参与会话）、REGISTER（注册用户位置信息）、ACK（确认消息接收）等。
头部字段包括各种标准字段和扩展字段，用于传递请求的相关信息，如From （发送者身份）、To（接收者身份）、Call-ID（会话标识符）、CSeq（序列号）等。
消息体可选，用于传递请求的实体内容，如SDP（会话描述协议）等。
2.2 响应消息响应消息由服务器发送给客户端，用于回应请求或指示操作结果。
响应消息的格式如下：状态行头部字段空行消息体状态行包括SIP协议版本、状态码和原因短语。
常见的状态码包括1xx（信息性响应）、2xx（成功响应）、3xx（重定向响应）、4xx（客户端错误响应）、5xx （服务器错误响应）等。
头部字段包括各种标准字段和扩展字段，用于传递响应的相关信息，如From、To、Call-ID、CSeq等。
消息体可选，用于传递响应的实体内容，如SDP等。
3. SIP消息示例以下是一些常见的SIP消息示例：3.1 INVITE请求消息示例：INVITEsip:********************/2.0Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK123456789From:sip:***************;tag=12345To:sip:*****************Call-ID:***************.2.1CSeq: 1 INVITEContact:sip:***************Max-Forwards: 70Content-Type: application/sdpContent-Length: 142v=0o=bob 2890844526 2890844526 IN IP4 192.0.2.1s=-c=IN IP4 192.0.2.1t=0 0m=audio 49170 RTP/AVP 03.2 200 OK响应消息示例：SIP/2.0 200 OKVia: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK123456789 From:sip:***************;tag=12345To:sip:*****************;tag=54321Call-ID:***************.2.1CSeq: 1 INVITEContact:sip:*****************Content-Type: application/sdpContent-Length: 142v=0o=alice 2890844527 2890844527 IN IP4 192.0.2.2s=-c=IN IP4 192.0.2.2t=0 0m=audio 49172 RTP/AVP 04. 总结本协议详细描述了SIP协议的主要消息格式和内容要求。
sip协议详解
SIP协议详解1. 引言Session Initiation Protocol（SIP）是一种用于建立、修改和终止多媒体会话的通信协议。
它广泛应用于语音、视频和即时通讯等实时通信领域。
本文将对SIP协议进行详细解析，介绍其基本原理和主要特点。
2. SIP协议概述SIP协议是基于文本的应用层协议，使用可读的ASCII文本来进行消息交换。
它采用客户端/服务器（C/S）模型，其中用户代理作为客户端，SIP服务器作为服务器。
SIP消息的格式包括请求消息和响应消息两种类型。
3. SIP消息格式SIP消息由起始行、头部字段和消息体组成。
起始行包括请求行或状态行，用于表示消息的类型和状态。
头部字段包含了一系列的键值对，用于传递消息的各种参数和选项。
消息体用于传输实际的数据内容。
4. SIP会话的建立与终止SIP协议通过INVITE/200 OK消息实现会话的建立，通过BYE消息实现会话的终止。
当用户A希望与用户B建立一个通话时，用户A向SIP服务器发送INVITE 消息，SIP服务器将该消息转发给用户B。
用户B可以选择接受INVITE消息，然后发送200 OK消息给用户A，表示接受通话请求。
当通话结束时，任一用户可以发送BYE消息，通知对方终止通话。
5. SIP注册与鉴权SIP协议支持用户注册和鉴权机制，以实现用户身份验证和安全通信。
用户在注册时，将自己的身份信息发送给SIP服务器，服务器将该信息保存起来。
当用户发起通话请求时，服务器可以根据用户的身份进行鉴权，确定用户是否具有通话的权限。
6. SIP中继与路由SIP协议支持中继和路由机制，以实现跨网络的通信。
SIP中继允许SIP消息在不同的网络之间传输，保证了用户可以在不同的网络环境下进行通话。
SIP路由机制允许SIP消息根据特定的规则进行转发，以找到正确的接收者。
7. SIP扩展与应用SIP协议允许进行扩展，以满足不同应用场景的需求。
例如，SIP可以与其他协议结合使用，如SDP（Session Description Protocol）用于传输会话描述信息。
Sip协议消息解释
20 头域头域的语法描述在7.3节。
本节列出了头域的全部列表，包括了语法注释，含义，和用法。
通过本节，我们使用[HX.Y]指当前HTTP/1.1 的RFC2616[8]的规范的X.Y节。
每个头域都有示例给出。
关于与方法和proxy处理有关的头域字段在表2和表3中有处理。
“where”列描述了在头域中能够使用的请求和应答的类型。
这列的值是：R:头域只能在请求中出现；r:头域只能在应答中出现；2xx，4xx，等等：一个数字的值区间表示头域能够使用的应答代码。
c：头域是从请求拷贝到应答的。
如果”where”栏目是空白，表示头域可以在所有的请求和应答中出现。
“proxy”列描述了proxy在头域上的操作a：如果头域不存在，proxy可以增加或者连接头域m：proxy可以修改现存的头域值d：proxy可以删除头域值r：proxy必须能读取这个头域，因此这个头域不能加密。
接下来6个栏目与在某一个方法中出现的头域有关：c：条件；对头域的要求依赖于消息的内容m：头域是强制要有的。
m*：头域应当被发送，但是客户端/服务端都需要准备接收没有这个头域的消息。
o：头域是可选的。
t：头域应当被发送，但是客户端/服务端都需要准备接收没有这个头域的消息。
客户端/服务端都需要准备接收没有这个头域的消息。
如果通讯的协议是基于面向流的协议（比如TCP），那么头域值必须被发送。
*：如果消息体不为空，那么头域值就绪要的。
（细节请参见20.14,20.15和7.4节）-:这个头域是不适用的。
“Optional”意味着这个元素可以在请求或者应答中包含这个头域，并且UA可以忽略在请求或者应答中存在的这个头域（这条规则有一个例外，就是Require头域，在20.32节有描述）。
”mandatory”（强制）头域是必须在请求中存在的头域，并且也必须是UAS 接收到一个请求时能够理解的头域。
一个强制头域必须也在应答中出现，并且UAC也能处理这个头域。
SIP协议主要消息
SIP协议主要消息协议名称：SIP协议主要消息协议简介：SIP（Session Initiation Protocol，会话初始化协议）是一种用于建立、修改和终止多媒体会话的通信协议。
它被广泛应用于IP电话、实时视频会议、即时消息和在线游戏等通信领域。
SIP协议主要通过消息进行通信，本文将详细介绍SIP协议的主要消息格式和功能。
一、SIP请求消息格式：SIP请求消息由请求行、首部字段和消息正文组成。
以下是SIP请求消息的主要字段：1. 请求行：- 方法（Method）：用于指定请求的类型，如INVITE、REGISTER、OPTIONS等。
- 请求URI（Request-URI）：指定请求的目标资源。
2. 首部字段：- Call-ID：唯一标识会话的ID。
- CSeq：命令序列号，用于标识请求的顺序。
- From：发起请求的用户标识。
- To：请求的目标用户标识。
- Via：传输路径和协议版本。
- Max-Forwards：限制请求转发的次数。
- Content-Type：消息正文的类型。
3. 消息正文：- 消息正文可以包含任意类型的数据，如SDP（Session Description Protocol）描述会话信息等。
二、SIP响应消息格式：SIP响应消息由状态行、首部字段和消息正文组成。
以下是SIP响应消息的主要字段：1. 状态行：- 版本号：SIP协议的版本号。
- 状态码：用于指示请求的处理结果，如200 OK表示成功，404 Not Found 表示未找到资源等。
- 原因短语：对状态码的简要描述。
2. 首部字段：- Call-ID：与请求消息中的Call-ID字段相同，用于标识会话。
- CSeq：与请求消息中的CSeq字段相同，用于标识请求的顺序。
- From：与请求消息中的From字段相同，标识请求发起方。
- To：与请求消息中的To字段相同，标识请求目标方。
- Via：与请求消息中的Via字段相同，表示传输路径和协议版本。
sip协议中 认证域
SIP协议中的认证域是一个重要的概念，它用于标识SIP消息的来源和目的地。
认证域通常包括用户名、密码和域名等信息，用于验证SIP消息的合法性。
在SIP协议中，认证域通常与SIP消息的To和From头字段相关联。
To头字段表示消息的目的地，而From头字段表示消息的来源。
认证域中的用户名和密码是用于验证SIP消息的合法性的凭据。
当SIP消息被发送到SIP代理或SIP注册服务器时，这些服务器会检查SIP消息中的认证域信息，以验证消息的来源和目的地的合法性。
如果认证域信息不匹配或无效，SIP代理或注册服务器将拒绝接收该消息，并返回一个错误响应。
通过使用认证域，SIP协议可以确保只有合法的用户能够发送和接收SIP消息，从而保护了通信的安全性和可靠性。
SIP协议中的HEADER应用
SIP协议中的HEADER应用SIP（会话初始化协议）是一种用于控制、启动、修改和终止多媒体会话的协议。
在SIP中，会话参与者之间进行通信和交流的方式是通过消息交换。
在SIP消息中，头部（Header）扮演了非常重要的角色，包含了关键信息以及用于控制和路由会话的参数。
在下面的文章中，我们将探讨SIP协议中头部的应用。
1.请求方法头部：SIP中的请求方法用于指示消息的目的和目的地。
请求方法头部包含了SIP消息的类型，例如INVITE（邀请）、ACK（确认）、BYE（结束会话）等，用于控制和路由会话的不同阶段。
2. 响应状态头部：SIP中的响应状态头部包含了响应消息的状态码和原因短语。
状态码用于指示请求的执行结果，例如200 OK表示请求成功，404 Not Found表示请求资源不存在等。
响应状态头部用于在SIP会话中传递执行结果和错误信息。
3.路由头部：SIP中的路由头部用于指示消息的路由路径。
路由头部包含了一系列URI（统一资源标识符）地址，表示消息在会话过程中经过的路由器和代理服务器。
路由头部的作用是确保消息能够在网络中正确地传递和到达目的地。
5.会话描述头部：SIP中的会话描述头部用于指示会话的特性和参数。
会话描述头部包含了一系列SDP（会话描述协议）参数，用于描述会话的音频、视频和其他多媒体参数。
会话描述头部的作用是确保会话能够正确地被初始化和修改。
6.隐私和安全头部：SIP中的隐私和安全头部用于指示消息的隐私和安全要求。
隐私头部包含了一系列指示消息的隐私级别和策略的参数，安全头部包含了一系列指示消息的安全级别和策略的参数。
这两个头部用于确保消息的隐私和安全性。
7.事件通知头部：SIP中的事件通知头部用于指示事件的发生和通知的接收者。
事件通知头部包含了一系列指示事件类型和通知方式的参数。
事件通知头部的作用是确保事件能够正确地发生和被通知。
8.权限和控制头部：SIP中的权限和控制头部用于指示消息的权限和控制要求。
SIP协议中的HEADER应用
GreenNET
2013-7-11
深圳市格林耐特通信技术有限公司
头域概要, P--Z
where enc. e-e ACK BYE CAN INV OPT REG _______________________________________________________________ Proxy-Authenticate 407 n h o o o o o o Proxy-Authorization R n h o o o o o o Proxy-Require R n h o o o o o o Priority R c e o Require R e o o o o o o Retry-After R c e o Retry-After 404,480,486 c e o o o o o o 503 c e o o o o o o 600,603 c e o o o o o o Response-Key R c e o o o o o Record-Route R h o o o o o o Record-Route 2xx h o o o o o o Route R h o o o o o o Server r c e o o o o o o Subject R c e - o Timestamp g e o o o o o o To gc(1) n e m m m m m m Unsupported 420 e o o o o o o User-Agent g c e o o o o o o Via gc(2) n e m m m m m m Warning r e o o o o o o WWW-Authenticate 401 c e o o o o o o
GreenNET
SIP协议字段讲解
SIP协议1、SIP协议简单介绍：一、SIP基本概念1.1 定义SIP（Session Initiation Protocol，会话发起协议）是由IETF（Internet工程任务组）提出的IP电话信令协议, 是采用UTF-8字符集来进行编码的文本协议。
SIP是一种通信协议，定义了如何在通信设备（计算机，电话，手机，PDA等）之间相互连接和信息交换。
SIP是一种信令控制协议，可以配置和管理任何类型的peer-to-peer 通信会话, 但并不关心媒体类型(语音、短信、游戏、视频等)。
1.2 SIP实体SIP协议定义了多个实体，理解它们在使用SIP协议的体系结构中所起的不同作用是至关重要的。
1.2.1 用户代理用户代理（UA，User Agent）表示一个终端系统。
它可以是SIP电话机或者电脑上的SIP软终端。
它包括两部分，用户代理客户端（UAC，User Agent Client）和用户代理服务器端（UAS，User Agent Server），前者产生请求，后者产生对应的响应。
UAC和UAS是逻辑上的两个部分，每个终端系统都包含了UAC和UAS的功能。
图1.2.1 一个简单的SIP呼叫的例子如图1.2.1所示，Tesla发起INVITE（请求），Marconi接收INVITE请求，因此，此时Tesla 就是用户代理客户端（UAC），Marconi是用户代理服务器端（UAS）；会话建立后，Marconi 发起BYE（结束）请求，Tesla发送对应的响应，因此，此时Marconi就是用户代理客户端（UAC），Tesla是用户代理服务器端（UAS）。
1.2.2代理服务器代理服务器（Proxy）是将请求消息路由到UAS以及将相应消息路由到UAC的实体。
一个请求消息在到达UAS之前可能要经过若干个代理服务器的转发，每个代理服务器都要进行路由决策，并在将请求信息转发到下一个实体之前对其进行修改。
响应消息将遍历请求信息所经的那些服务器，但顺序却完全相反。
SIP消息介绍剖析.
模式6在RFC3311中定义，主要用于在早期对话中更新已建立的会话参数，会话可能是通过模式3，也可能 是通过模式4建立的。模式6还可以对会话进行多次更新。例如,之前已通过模式5更新过的会话还可以使用模式6更新； 甚至通过模式6更新过的会话还可以再次使用模式6更新。 模式6：UAC（或UAS）发送UPDATE请求其中携带一个新的offer, UAS（或UAC）在200 UPDATE中返回一个answer。这样，会 话参数便被更新。注意，UAS或UAC在发送UPDATE进行会话更新之前，必须保证之前的会话更新过程已经完成。也就是说，发出 的offer已经收到answer，或者收到的offer已经产生了answer。
PS: 如果UAC在INVITE消息中含有support头域：100rel，而UAS也支持该扩展并且在183响应中有require:100rel,说明在后面的会话当中，对所 有100以外的响应消息，都需要prack回应。 如果UAC不支持100rel，但UAS要求支持100 rel (require:100rel),UACv发送CANCEL，切断会话。
4，SIP 是基于一个类似 HTTP 协议的请求应答的通讯模式。 每一个通讯都包含对某个功能的请求，并且起码需要一 个应答。 5，SIP 也提供保密 URI，称作 SIPS URI，例如：sips: bob@。 一个基于 SIPS URI 的通话保证这个通话是 安全的，并且对呼叫者和被叫的所有的 SIP 消息是加密传输的（叫做 TLS）。在 TLS 中，请求是通过加密方式传输给被 叫方，但是这个加密机制是基于被叫方宿主服务器的实现的。
UAC: user agent client,用户代理客户端 UAS: 用户代理服务端 ，下面可以把它当成另一个客户端
简便的SIP消息--我们来看看SIP消息的格式
简便的SIP消息--我们来看看SIP消息的格式疫情期间，学校停课，北京的学校都在家上⽹络课堂，⼤家使⽤的不是腾讯视频会议便是钉钉视频会议。
疫情对⼤部分企业都造成了损失，然⽽视频会议市场却迎来⽣机。
今天咱们来谈谈视频会议中使⽤的SIP协议是什么样⼦的。
咱们⽴刻⽤SIP终端发起⼀个呼叫，然后抓取⽹络包如下，我们看到它包含很多A:B这种格式的数据，这些就叫SIP Header，和HTTP Header差不多。
下⾯是发起呼叫的invite SIP消息INVITE sip:6999 SIP/2.0From: <sip:112826@136.123.127.49>;tag=1b7ffa38-6800a8c0-13c4-60011-8ca1-5ce4ed6e-8ca1To: <sip:6999>Call-ID: 1b855600-6800a8c0-13c4-60011-8ca1-614dc2d0-8ca1CSeq: 1 INVITEVia: SIP/2.0/UDP 136.123.127.49:5060;rport;branch=z9hG4bK-8ca1-2255705-7fc7db28-1b7c8d00Max-Forwards: 70Supported: replaces,timer,100relAllow: INVITE, ACK, BYE, REFER, NOTIFY, INFO, CANCELUser-Agent: Sherlock 3.2.0.8Contact: <sip: 112826@136.123.127.49>Session-Expires: 1800;refresher=uac咱们再看看被邀请的⼀⽅返回的SIP消息SIP/2.0 200 OKFrom: <sip: 112826@136.123.127.49>;tag=1b7ffa38-6800a8c0-13c4-60011-8ca1-5ce4ed6e-8ca1To: <sip:6999>;tag=7f231e4ff028-e46b820a-13c4-55022-22b3fa-3ca0854f-22b3faCall-ID: 1b855600-6800a8c0-13c4-60011-8ca1-614dc2d0-8ca1CSeq: 1 INVITESIP消息包含了很多SIP Headers，它很容易看懂，咱们挑⼏个看⼀下1. 1. INVITE sip:6999 SIP/2.0它的意思是，这是⼀个invite消息，呼叫的对象是1. 2. From: <sip:112826@136.123.127.49>;tag=1b7ffa38-6800a8c0-13c4-60011-8ca1-5ce4ed6e-8ca1它的意思是这个invite消息来⾃谁，tag⽤来标识这个谁1. 3. To: <sip:6999>它的意思很明显，就是发送给谁1. 4. Call-ID: 1b855600-6800a8c0-13c4-60011-8ca1-614dc2d0-8ca1它的意思也很明显，就是呼叫的ID，⽤来标识这次呼叫1. 5. CSeq: 1 INVITE1 是个序列号，⼀个对话包含很多请求，⼀般情况下每次发起⼀个新的请求，这个序列号会+1INVITE 这个是请求的名字。
SIP消息类型和消息格式
SIP消息类型和消息格式sip消息类型和消息格式SIP是⼀个基于⽂本的协议,使⽤的是UTF-8字符集.SIP消息主要分为两⼤类:⼀类是由客户端发往服务器的请求消息(Request);⼀类是由服务器发往客户端的应答消息(Response).⼀个基本的SIP消息包括起始⾏、⼀个或多个头字段、说明头字段结束的空⾏和⼀个可选的消息体。
消息=起始⾏（包括请求⾏/状态⾏；请求⾏规定了请求的类别，⽽状态⾏指出了每个请求的状态，⽐如是成功还是失败。
如果是失败的话还要给出失败的原因或类型。
）*头字段CRLF[消息体] （消息⾸部给出了关于请求或应答的更多信息⼀般包括消息的来源、规定的消息接收⽅，另外还包括⼀些其他⽅⾯的重要信息。
消息体通常描述将要建⽴会议的类型包括所交换媒体的描述，但不具体定义消息体的内容或结构，其结构或内容使⽤另外⼀个协议来描述，就是会话描述协议SDP。
）请求消息请求⾏=⽅法 +空格 +请求地址 +SIP版本号 +空⾏通过⼀个请求⾏作为起始⾏，请求⾏包括了⽅法名、请求的URL、协议版本号、中间⽤空格分开。
六种请求⽅法：INVITE 发出呼叫会话请求ACK INVITE请求被最终请求BYE 释放⼀个呼叫会话CANCEL 取消挂起的呼叫REGISTER 登记注册⽤户代理OPTIONS 查询服务器能⼒应答消息状态⾏=SIP版本+空格+状态码+空格+相关⽂本短语+空⾏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 错误请求请求失败(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 不可接受SIP应答代码(这个是详细的应答码解释)应答码是包含了，并且扩展了HTTP/1.1应答码。
sip中route头域的作用
sip中route头域的作用
Route 头域用于路由选择，是session Initiation Protocol （SIP）中比较重要的头域之一，它可以指示 SIP 请求应该被转发到
哪里去。
Route 头域的内容是个 URL（Uniform Resource Locator），它可以携带端口号和参数，而且允许另外一种 SIP 地址格式的使用：name-addr（display-name + addr-spec），因此它可以提供有关 SIP 代理的更多信息。
首先，在传播 SIP 消息时，代理就是消息的转发者。
传播过程中，代理将消息转发给其他代理或直接到达事务用户（Transaction User，即UAC或UAS）。
在转发消息时，代理必须履行以下五项任务：
1、消息路由：代理必须选择消息的下一个传送地址
2、本地路由：代理必须检查是否有当地注册的 UAS
3、消息内容处理：希望代理在收发消息时，能够对消息内容进行
有效地处理，如缓存结果
4、域名解析：对于 SIP URI 的解析问题，通常会从 DNS 服务器
端获取 IPv4 和 IPv6 地址
5、路由权限控制：在转发消息时，代理服务器会遵循 Route 头
域指示，以限制请求所能到达的地方，避免非法请求被错误地传送
因此，Route 头域的存在可以使得 SIP 的代理头域能够有效地完
成上述步骤，将 SIP 请求转发给最终的目标，使得连接能够正常传输。
路由有关的SIP消息头的简单小结
路由有关的SIP消息头的简单小结一、SIP协议中定义的路由相关字段1. Via：当UAC发起一个SIP Request消息时，消息经过的每一跳（包含发起方）都会在SIP消息中增加一个Via字段，内容为自己的地址信息，表示此消息通过此地址发往下一跳。
为什么要增加Via字段来记录Request消息经过的地址呢？实际上这个地址信息将被作为Request消息的Response消息的路由，Response将根据Via字段中记录的地址逐级返回，直到回到Request 的发起方。
2. Route：Route和Via字段正好相反，它被用来作为Request 消息的路由。
当一个Proxy Server收到一个Request消息时，会检查Route字段的第一个地址是否等于自己，如果是，它将从Route字段中删去自己的地址信息，并将消息转发到Route字段中指定的下个地址；如果Route字段为空，则转发到Request URI指定的地址。
3. Record-Route：Record-Route字段实际上用于帮助UA建立Route Set，当UA发送Request时会用Route Set来设置上面提到的Route字段。
当一个Request消息经过Proxy Server时，如果该Proxy Server希望通知UA相关的后续消息都能通过它来转发，此时它就会在消息中添加Record-Route字段，内容为自己的地址信息。
当UAS发送Resposne消息时它将复制Request中的Record-Route 字段，而UAC在Response消息中检测到Record-Route字段时，它就会用该字段的路由信息更新自己的Route Set。
二、IMS协议中增加的路由相关字段1. Service-Route：Service-Route在S-CSCF向UE发送REGISTER成功应答时设置，作用和Record-Route类似，用于帮助UE建立Route Set，这样UE注册后的消息（例如INVITE）通过设置Route字段无需经过I-CSCF可直接送达S-CSCF。
SIP消息头域的说明
SIP消息头域的说明(转)1 general-header类：为描述消息基本属性的通用头域，可用于请求消息或响应消息；通用头域的域名只有在协议版本改变时才可有效地扩展。
不过，通信中的所有方均认为是“通用头域”的新的头域也可认为是通用头域。
不被认可的头域作为实体头域。
1.1 Call-IDCall-ID通用头域唯一标识一个特定的请求或者一个特定客户的所有登记。
来自同一个客户的所有的登记应该使用同样的Call-ID头值，至少是在同一个重新启动的循环中。
注意到单个的多媒体会议会产生不同Call-ID的几个呼叫，例如，用户多次邀请一个单个的私人加入同一个会议。
对于一个INVITE请求。
主叫方用户代理服务器不应该警告用户，如果用户先前已经对INVITE请求中的Call-ID 作出了响应。
如果用户已经是会议的一个成员，同时包含在会话描述中的会议参数并未改变，那么主叫方用户代理服务器可以接受此呼叫，而不管Call-ID。
对于一个已存在的Call-ID或者会话的邀请可能改变会议的参数。
一个客户应用可以决定向用户简单地指示会议参数已经改变，可以自动接受邀请或者可能需要用户的确认。
使用几个不同的Call-ID可以邀请一个用户加入同一个会议或者呼叫。
如果需要的话，可以使用在会话描述中的标识来检测此副本。
例如，SDP的“o”域中包含了会话标识和版本号。
REGISTER和OPTIONS方式使用Call-ID值来精确匹配请求和响应。
一个单个的客户发布的所有的REGISTER请求应该使用同一个Call-ID，至少在同一个有效循环中。
Call-ID = (“Call-ID” | “i”)”:”local-id”@”hostLocal-id = 1*urici是Call-ID的缩写形式。
“host”应该是一个真正的域名或者是一个全球性的IP地址。
如此，”local-id”应该是一个由URI字符组成的标识，此标识在”host”中是唯一的。
SIP必带头域
SIP必带头域SIP消息有5个必带头域：FROM TO CALL-ID MAX-FORWARD VIAFrom: 标识请求的逻辑发起者，如果一个SIP消息中没有Contact 或者Record-Route头域，那么callee就会根据From头域产生后续的Request。
比如：如果 Alice打一个电话给Bob，From头域的内容是From:Alice<sip:*****************>。
那么Bob打给Alice时就会使用sip:*****************作为T o头域和Request-URI头域的内容；To：请求的逻辑接收地，包含了由From域描述的发送者发出的请求的原始接受者。
原始接受者可能是也可能不是正在处理这个请求的UAS,取决于呼叫转移或者其他的proxy操作；注：FROM和TO头域中，可能会带TAG参数，FROM TAG、TO TAG以及CALL-ID三个共同来标识一个对话，之所以需要3个来标识，是因为在多方通话的场景中，CALL-ID都是一样的，不能标识出两个特定UA之间的对话，这时就需要两个TAG来共同标识。
另外，TO TAG是用来在对话中做标志的，如果是会话外的场景，没有建立对话，就不能有TO TAG；Call-ID：一个在一系列消息中，区分一组消息的唯一标志。
在对话中的任一UA的所有请求和所有应答的Call-ID必须一致。
在UA的每次注册中，都应该是一样的。
在会话外的时候，UAC发起一个新的请求，这个Call-ID头域必须由UAC产生一个全局（在时间和空间上都是）唯一的Call- ID, 除非是请求头的方法（method）指明了别的产生方式。
所有的SIP UA都必须保证自己产生的Call-ID不会和其他UA产生的Call-ID重复。
注意，如果是请求的重新尝试，则重新尝试的请求不被当作一个新的请求，所以不需要新的Call-ID；Max-Forwards头域用来限制请求到他的目的地中间的跳转。
SIP常用消息实例
SIP常用消息实例参考1、MESSAGE消息1）头字段填写说明Call-id：必选CSeq：必选From：必选To：必选Max-Forwards：必选Via：必选常用的可选参数：指定的消息体2）消息实例发送MESSAGE请求消息给的6010端口，参考消息如下（带了“Hello”的消息体）：MESSAGE:6010 SIP/Call-IDFrom>;tag=-0037-708c9a5cba8dd878To>CSeq: 1 MESSAGEVia: SIP/UDPMax-Forwards: 30Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,UPDATE,PRACK,REFER,SUBSCRIBE,NOTIFY, MESSAGEContact: <sip:Content-Type: text/plainContent-Length: 5Hello收到来自的6010端口的返回消息，参考消息如下（修改了消息体的内容，变成了“Hello ami go”）：SIP/200 OKVia: SIP/UDPFrom>;tag=-0037-708c9a5cba8dd878To>;tag=-002-3c18e810ab17c76fCall-IDCSeq: 1 MESSAGEAllow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,UPDATE,PRACK,REFER,SUBSCRIBE,NOTIFY, MESSAGEContact: <sip:Content-Type: text/plainContent-Length: 11Hello amigo2、REGISTER消息1）头字段填写说明Call-id：必选Cseq：必选From：必选To：必选Max-Forwards：必选Via：必选Contact：必选Authorization：必选Expires：常用可选头2）非鉴权注册消息实例在该实例中机器发送注册消息给服务器，发送消息实例如下：REGISTER sip: SIP/Via: SIP/UDPMax-Forwards: 70From>;tag=ca04c1391af3429491f2c4dfbe5e1b2e;epid=4f2e395931To>Call-IDCSeq: 1 REGISTERContact: <sip:"INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER" User-Agent: RTC/ (BOL SIP Phone 1005)Event: registrationAllow-Events: presenceContent-Length: 0当注册成功（回送200 OK）时，服务器发送的res消息参考如下：SIP/200 OKVia: SIP/UDPFrom>;tag=ca04c1391af3429491f2c4dfbe5e1b2e;epid=4f2e395931To>;tag=-00834-14d0805b62bc026dCall-IDCSeq: 1 REGISTERAllow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,UPDATE,PRACK,REFER,SUBSCRIBE,NOTIFY, MESSAGEContact: sip:Content-Length: 0Expires: 36003）鉴权注册消息实例当需要鉴权注册时，当请求端使用BOL或xlite等发送注册消息给服务器时，服务器对发送“4 01 Unauthorized”信息给请求端，提示请求段需要带上鉴权信息重新注册，请求端带上鉴权信息后（带有“Authorization”头字段）重新向服务器注册，服务器验证鉴权头的正确性，如果鉴权成功，给请求端发送200 OK消息。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
SIP消息头域的说明(转)1 general-header类：为描述消息基本属性的通用头域，可用于请求消息或响应消息；通用头域的域名只有在协议版本改变时才可有效地扩展。
不过，通信中的所有方均认为是“通用头域”的新的头域也可认为是通用头域。
不被认可的头域作为实体头域。
1.1 Call-IDCall-ID通用头域唯一标识一个特定的请求或者一个特定客户的所有登记。
来自同一个客户的所有的登记应该使用同样的Call-ID头值，至少是在同一个重新启动的循环中。
注意到单个的多媒体会议会产生不同Call-ID的几个呼叫，例如，用户多次邀请一个单个的私人加入同一个会议。
对于一个INVITE请求。
主叫方用户代理服务器不应该警告用户，如果用户先前已经对INVITE请求中的Call-ID 作出了响应。
如果用户已经是会议的一个成员，同时包含在会话描述中的会议参数并未改变，那么主叫方用户代理服务器可以接受此呼叫，而不管Call-ID。
对于一个已存在的Call-ID或者会话的邀请可能改变会议的参数。
一个客户应用可以决定向用户简单地指示会议参数已经改变，可以自动接受邀请或者可能需要用户的确认。
使用几个不同的Call-ID可以邀请一个用户加入同一个会议或者呼叫。
如果需要的话，可以使用在会话描述中的标识来检测此副本。
例如，SDP的“o”域中包含了会话标识和版本号。
REGISTER和OPTIONS方式使用Call-ID值来精确匹配请求和响应。
一个单个的客户发布的所有的REGISTER请求应该使用同一个Call-ID，至少在同一个有效循环中。
Call-ID = (“Call-ID” | “i”)”:”local-id”@”hostLocal-id = 1*urici是Call-ID的缩写形式。
“host”应该是一个真正的域名或者是一个全球性的IP地址。
如此，”local-id”应该是一个由URI字符组成的标识，此标识在”host”中是唯一的。
建议使用经过加密的随机标识。
Call-ID的值禁止被重用于另一个不同的呼叫。
Call-ID区分大小写。
1.2 From请求和响应必须包含From通用头域，指示请求的初始者。
From域可以包含一个"tag"参数。
服务器将From头域从请求复制到响应。
可选的"display-name"意味着由用户接口提出（执行）。
如果客户身份被隐藏，那么系统必须使用显示名"Anonymous"。
此SIP-URL禁止包含"transport-param"，"maddr-param"，"ttl-param"，"headers"。
接收到含有以上元素的SIP-URL的服务器在执行下一步处理之前，应将这些元素删除。
即使"display-name"是空的，如果"addr-spec"包含了"，"、"？"、"；"，"name-addr"形式也必须使用。
From =（"From" | "f"）"："（name-addr | addr-spec）*（"；"addr-params）addr-params=tag-paramtag-param="tag="UUIDUUID=1*（hex | "-"）"tag"可以出现在一个请求的From头域中，当共享同一个SIP地址的用户的两个实例使用同一个Call-ID发出邀请时，必须使用此"tag"。
"tag"必须是全球唯一的，并且是一个经过加密的至少32比特的随机数。
一个单个的用户应该在一个Call-ID所标识的整个呼叫中保持同一个tag。
Call-ID、To和From用于标识一个Call leg。
呼叫和Call-leg的区别在于多个响应对派生请求的呼叫。
1.3 ToTo通用头域说明了请求的接收者。
To =（"To" | "t"）"："（name-addr | addr-spec）*（"；"addr-params）请求和响应必须包含To头域，指示请求的预定接收者。
可选的"display-name"意味着由用户接口提出（执行）。
UAS或者重定向服务器将To头域的内容复制到它的响应中，同时如果请求包含了不止一个Via头域，则必须增加"tag"参数。
如果Via头域不止一个，那么表明请求至少经过一个代理服务器的处理。
因为接收者不知道此请求是哪一个代理服务器派生的请求，所以从安全方面考虑，可认为它们都派生了请求。
此SIP-URL禁止包含"transport-param"，"maddr-param"，"ttl-param"，"headers"。
接收到含有以上元素的SIP-URL的服务器在执行下一步处理之前，应将这些元素删除。
"tag"参数作为一种通用机制，用于区分由一个SIP-URL标识的用户的多个实例。
因为代理可以派生请求，所以同一个请求可以到达用户的多个实例（例如：移动和住宅电话）；又由于每一个都可以响应，所以必须有一种方法来区分来自被叫方每一个实例的响应。
这种情况也可由于多点传送（组播）请求而产生。
"tag"参数用于区分UAC的响应。
当请求有可能被一中间件代理派生时，每一个实例都必须在它的响应中包含"tag"参数。
"tag"参数必须可以被UAS、登记器和重定向服务器增加，但禁止被加入到上传的响应中。
"tag"参数可以增加到所有方式的所有已经定义的响应中，也可以加入到来自UAS或者重定向服务器的报告性（1xx）响应。
两个实体间随后所有的事务都必须包含"tag"参数。
当响应与请求相匹配时，如果请求的To域中未包含"tag"参数，那么响应To域中的"tag"参数将忽略。
"tag"允许代理派生同一个呼叫的未来的请求，而只对几个可能的响应UAS中的一个定位（寻址）。
它也允许被叫方的多个实例发送可以区分的请求。
当SIP服务器接收到一个请求，此请求的To域中含有它不能识别的URI时，它应该返回一个400（Bad Request）响应。
即使"display-name"是空的，如果"addr-spec"包含了"，"、"？"、"；"，"name-addr"形式也必须使用。
Call-ID、To和From用于标识一个Call leg。
呼叫和Call-leg的区别在于多个响应对派生请求的呼叫。
"tag"允许代理派生同一个呼叫的未来的请求，而只对几个可能的响应UAS中的一个定位（寻址）。
它也允许被叫方的多个实例发送可以区分的请求。
1.4 ViaVia头域指示请求迄今为止所走的路径。
它防止了请求的循环，同时确保了响应（回答）沿同样的路径返回，这一点可以通过防火墙遍历和其他的异常路径情况提供帮助。
1.5 ContactContact通用头域可出现在INVITE、ACK和REGISTER请求中，1xx、2xx、3xx和485响应中。
通常，它提供了一个URL，用户可以通过此URL来进行进一步的通信。
INVITE和ACK请求：Contact域表明请求从哪个位置发起；这允许主叫方直接向被叫方发送未来的请求，如BYE，而不是通过一系列的代理。
由于所想要的地址可能是代理的地址，所以只Via头域并不够。
INVITE 2xx响应：一个用户代理服务器在发送一个限定的、肯定的响应（2xx）时，可以加入一个Contact响应头域，表明对于未来的请求它可以直接到达的SIP地址，如ACK请求。
Contact头域包含了服务器自己或者代理的地址，例如主机在一个防火墙之后。
如果响应未包含Record-Route头域，此Contact的值将复制到此呼叫的后来的请求的Request-URI中；如果响应包含了Record-Route 头域，Contact域的值将作为最后一项增加到Record-Route域中。
Contact的值不应该通过呼叫被缓冲，因为它可能不能表示一个特殊目的地地址的最想要的位置。
INVITE 1xx响应：一个UAS发送一个临时的响应（1XX）可以插入一个Contact 响应域。
语义同2XX INVITE响应。
注意到CANCEL请求禁止被发送到那个地址（Contact所指示的），但仍跟随初始请求的路径。
REGISTER request：REGISTER请求中的Contact域表明用户的位置。
REGISTER 请求定义了一个通配的Contact域。
“*”，只能用于：0删除一个用户所有的登记。
一个可选的“expires”参数指示登记所想要的期限。
如果Contact未使用此参数，则Contact域的值将使用默认值。
如果这些机制都未采用，SIP URL 的期限为一个小时。
其他的URL没有期限时间。
REGISTER 2xx响应：一个REGISTER响应可以返回可以达到的用户的所有地址。
3xx和485响应：Contact头域指示一个或多个可选的地址。
可以出现在对于INVITE、BYE和OPTIONS方式的响应中。
Contact头域包含的URI给出了新的位置和用户名，或者简单地说明其他的传输参数。
300（Multiple Choise）、301(Moved Permanently)、302(Movec Temporarily)或者485(Ambiguous)响应应该包含一个含有可尝试的新地址的URL的Contact域。
301和302响应可以给出正在尝试的同样的位置和用户名，但指定了其他的传输参数，如一个不同的服务器或者多点地址，或者一个从TCP到UDP，UDP到TCP的SIP事务的改变。
客户将Contact URL中的“user”、“password”、“host”、“port”、“user-param”复制到重定位请求的Request-URL中，同时使用tranport参数中的传输协议，将此请求传到“maddr”和“port”参数所说明的地址处。