sip协议refer信令标准用法
vonr语音通话的sip信令流程
vonr语音通话的sip信令流程
Vonr语音通话采用SIP(SessionInitiationProtocol)协议进行信令传输，下面是SIP信令流程的简要介绍：
1. 呼叫发起：用户A发起呼叫，向SIP服务器发送INVITE请求。
2. 呼叫转移：如果用户B在呼叫转移状态，则呼叫会被转移到用户C，此时SIP服务器会向用户C发送INVITE请求。
3. 呼叫确认：用户C收到INVITE请求后，会向SIP服务器发送200 OK响应，表示确认呼叫。
4. 媒体协商：在呼叫确认后，用户A和用户C需要协商音视频编解码器、分辨率等媒体信息。
5. 媒体传输：协商完成后，用户A和用户C开始进行音视频传输。
6. 呼叫结束：当通话结束时，用户A或用户C会向SIP服务器发送BYE请求，SIP服务器会向另一方发送200 OK响应，表示呼叫结束。
以上是Vonr语音通话的SIP信令流程概述，具体实现可能会有所不同。
- 1 -。
中国电信SIP规范第三部分(信令流程)
ＳＩＰ 初始会话协议 信令流程 Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ｓｉｇｎａｌｉｎｇ Ｃａｌｌ Ｆｌｏｗ ２００３年１２月３１日发布 ２００３年１２月３１日实施 中国电信集团公司发布前言 ＳＩＰ协议是下一代网络中的接口协议之一，属于应用控制协议。
本标准是以ＩＥＴＦ和ＩＴＵ－Ｔ的相关标准为基础，结合中国电信网络的实际情况，并综合中国电信集团公司对下一代网络的实验成果制定的。
它是中国电信在下一代网络建设中引进、测试和研发软交换设备、SIP终端设备以及其他基于SIP协议相关设备的规范和依据。
鉴于ＳＩＰ协议应用范围广泛，项目组在编写时将整个协议规范分为３个分册： 第一分册：《总体要求》 第二分册：《协议细则》 第三分册：《信令流程》 本分册为《信令流程》分册。
本标准由中国电信集团公司提出。
本标准由中国电信集团公司归口。
本标准2003年12月31日首次发布。
本标准由中国电信集团公司负责解释- 1 -目录1.编制说明 (4)1.1范围 (4)1.2参考文献 (4)2.环境说明 (4)3.用户注册 (5)3.1成功的注册 (5)3.1.1基本注册过程 (5)3.1.2注册信息的更新 (7)3.1.3注销 (7)3.2不成功的注册 (7)4.鉴权认证 (8)4.1注册鉴权 (8)4.2呼叫鉴权（假定对Invite消息的鉴权） (8)5.基本呼叫 (8)5.1SIP用户-SIP用户 (8)5.1.1成功呼叫 (8)5.1.2不成功的呼叫建立 (14)5.1.3定时器检验 (16)5.2SIP用户-PSTN用户(采用Profile B) (19)5.2.1成功的呼叫 (19)5.2.2不成功的呼叫建立 (21)5.3PSTN用户-SIP用户(采用Profile B) (24)5.3.1成功的呼叫 (24)5.3.2不成功的呼叫建立 (26)5.4PSTN用户-PSTN用户(Profile C，要求临时性响应可靠传送) (28)5.4.1成功的呼叫 (28)5.4.2不成功的呼叫建立 (30)- 2 -6.业务控制 (32)6.1SIP用户-SIP用户 (32)6.1.1Presence (32)6.1.2Fork应用 (36)6.1.3通过重定向实现的业务（类似呼叫前转） (44)6.1.4呼叫保持 (48)6.1.5呼叫等待 (50)6.1.6主叫显示禁止（CLIR） (52)6.2SIP用户-PSTN用户(SIP-ISUP互通，Profile B) (52)6.2.1呼叫前转（包括立即前转、无应答前转、遇忙前转） (52)6.2.2呼叫保持 (55)6.2.3呼叫等待 (56)6.2.4主叫显示禁止（CLIR） (56)6.3PSTN用户-SIP用户(SIP-ISUP互通，Profile B) (56)6.3.1通过重定向实现的业务（类似于呼叫前转业务） (56)6.3.2呼叫保持 (56)6.3.3呼叫等待 (57)6.3.4主叫显示禁止（CLIR） (57)6.4PSTN用户-PSTN用户(SIP-ISUP互通，Profile C) (58)6.4.1呼叫前转（包括立即前转、无应答前转、遇忙前转） (58)6.4.2呼叫保持 (61)6.4.3呼叫等待 (61)6.4.4主叫显示禁止（CLIR） (62)- 3 -- 4 -1. 编制说明1.1 范围1. 本分册对基本语音业务、典型补充业务的实现作了流程说明，同时做出规定的还包括Presence 、并行/串行的呼叫流程，涉及的用户包括PSTN 用户、SIP 用户等。
SIP协议呼叫流程及协议分析
SIP协议呼叫流程及协议分析SIP（Session Initiation Protocol）是一种用于建立、修改和终止多媒体会话的协议。
它允许用户在互联网上进行实时语音、视频通话以及即时消息传递等。
SIP协议的呼叫流程可以简要概括为：建立连接、呼叫邀请、会话建立、会话修改和会话终止。
1.建立连接：2.呼叫邀请：发起呼叫的一方（称为呼叫发起方）向被呼叫方发送一个INVITE请求，其中包括被呼叫方的SIP地址。
INVITE请求中还包含了与呼叫相关的会话描述信息（SDP）。
3.会话建立：被呼叫方收到INVITE请求后，可以采取以下步骤来进行会话建立：a.被呼叫方返回一个响应（称为200OK）给呼叫发起方，表示接受呼叫邀请。
b. 被呼叫方收到100 Trying响应后，表示已收到呼叫邀请。
c. 被呼叫方可以发送180 Ringing响应给呼叫发起方，表示正在被呼叫方正在响铃。
d.呼叫发起方接收到200OK响应后，表示会话建立成功。
4.会话修改：在会话建立后，呼叫发起方和被呼叫方之间可以根据需要对会话进行修改。
例如，可以设置音频编解码器、视频分辨率等参数。
SIP协议提供了多种消息来进行会话修改，如ACK、BYE、CANCEL、OPTIONS等。
5.会话终止：当通话结束时，任何一方可以发送BYE请求来终止通话。
接收到BYE请求的一方会发送一个200OK响应，表示通话已终止。
1.灵活性：SIP协议使用文本格式，易于阅读和理解，且允许在会话建立后对会话进行修改。
2.易于扩展：SIP协议定义了许多扩展机制，使其适应不断增长的需求和新的通信技术。
3.开放性：SIP协议是一个开放的协议，允许与其他协议（如H.323、XMPP等）进行互操作。
4.易于管理：SIP协议允许用户和终端设备具有自由度，可在各种网络环境和设备上进行使用和管理。
然而，SIP协议也存在一些挑战和问题：1.安全性：SIP协议的开放性也带来了安全问题，如拒绝服务攻击、身份伪造等。
SIP协议
SIP协议简介SIP（Session Initiation Protocol）是一种用于建立、修改和终止多媒体会话的协议。
它是互联网工程任务组（IETF）定义的一种应用层协议，被广泛应用于语音通话、视频通话、即时消息和多媒体会议等实时通信领域。
SIP协议的主要目标是提供一种灵活、可扩展的机制，用于建立和管理通信会话。
它采用文本格式的消息交换方式，基于请求‑应答模式进行通信。
SIP协议使用统一资源标识符（URI）来标识终端设备和用户，通过SIP消息的交换来实现会话的控制。
SIP协议的设计思想是简单、可扩展和松散耦合。
它允许在不同的网络环境中使用各种传输协议，如UDP、TCP和TLS等。
同时，SIP协议也提供了灵活的会话控制功能，包括呼叫的建立、会话参数的修改和会话的终止。
SIP协议在实时通信领域有着广泛的应用。
它被广泛用于VoIP（Voice over IP）系统，使得用户可以通过互联网进行语音通话。
此外，SIP协议还支持视频通话、实时消息传递和多媒体会议等功能。
它提供了一种开放的架构，允许不同厂商的设备和应用进行互操作。
然而，SIP协议也面临着一些安全性和挑战。
由于SIP协议的开放性和可扩展性，攻击者可能利用其中的漏洞进行恶意攻击。
因此，实施SIP协议时需要采取一些安全措施，如认证、加密和防火墙等，以保护通信的安全和隐私。
总之，SIP协议作为一种用于建立和管理多媒体会话的协议，为实时通信提供了一种灵活、可扩展的机制。
它在VoIP 和其他实时通信应用中发挥着重要的作用，并为用户提供了丰富的通信体验。
然而，为了确保通信的安全性，使用SIP 协议时需要注意相关的安全措施。
SIP协议的工作原理SIP（Session Initiation Protocol）协议是一种基于文本的协议，用于建立、修改和终止多媒体会话。
它采用了简单而灵活的工作原理，使得通信设备能够进行会话的控制和管理。
SIP协议的工作原理可以概括为以下几个步骤：1.定位和寻址：SIP协议使用统一资源标识符（URI）来标识终端设备和用户。
sip协议报文类型
sip协议报文类型SIP（Session Initiation Protocol）是一种应用层协议，常用于建立、修改和结束实时多媒体会话，例如语音通话、视频通话和即时消息。
SIP定义了一系列的消息类型，用于在用户终端之间传递信息和控制会话的各个方面。
下面将介绍SIP协议中的一些常用的报文类型。
1.请求消息（Request）:SIP协议中的请求消息用于向服务器发送请求，以请求某种操作或服务。
常见的请求消息包括：- INVITE：用于建立一次会话或邀请其他终端参与会话。
- ACK：用于回复对INVITE请求的确认。
- BYE：用于结束会话。
- REGISTER：用于用户的注册和注销。
2.响应消息（Response）:SIP协议中的响应消息是服务器对请求消息的回应。
常见的响应消息包括：- 1xx：表示请求已被接收，需要进一步处理。
- 2xx：表示请求已成功完成。
- 3xx：表示请求被重定向到其他服务器或终端。
- 4xx：表示请求包含错误，无法完成。
- 5xx：表示服务器出现错误，无法完成请求。
- 6xx：表示服务器无法处理请求。
3.媒体描述消息（SDP）:SDP（Session Description Protocol）用于描述会话中的媒体流信息，如编解码器、传输协议、媒体格式等。
SIP协议中的媒体描述消息使用SDP来描述媒体流的相关信息。
4.信息消息（INFO）:INFO消息用于向会话中的参与者传递一些附加的信息，如DTMF信号、键盘输入等。
5.订阅/通知消息（SUBSCRIBE/NOTIFY）:SUBSCRIBE消息用于向服务器请求订阅某种事件，如其他用户的状态变化。
服务器在事件发生时，会使用NOTIFY消息通知订阅者。
6.选项消息（OPTIONS）:OPTIONS消息用于向服务器查询对某个请求支持的能力、状态或配置。
7.重定向消息（REDIRECT）:重定向消息用于向用户提供其他服务器或终端的地址，以便进一步处理请求。
网络协议知识：SIP协议的基本工作流程和通信过程
网络协议知识：SIP协议的基本工作流程和通信过程SIP协议的基本工作流程和通信过程SIP协议（Session Initiation Protocol）是一种用于建立、修改和终止多媒体传输会话的信令协议。
它被广泛地应用于互联网电话（VoIP）、视频会议、实时文本等领域。
在本文中，我们将介绍SIP协议的基本工作流程和通信过程。
一、SIP协议的基本工作流程SIP协议的基本工作流程包括会话描述、会话建立、呼叫传送和会话终止四个部分。
1.会话描述在建立会话之前，需要先进行会话描述，包括会话类型、参与者、所需资源和传输协议等信息。
这些信息被包含在SIP消息中，由发送者向接收者发送。
2.会话建立会话建立是SIP协议的核心部分，它分为两个阶段：呼叫请求和呼叫响应。
（1）呼叫请求：呼叫请求由客户端发起，它包含了所需资源和参与者的信息。
首先，客户端需要向第三方服务器发送INVITE消息，请求建立一次会话。
在INVITE消息中，需要包含被叫方的地址信息、消息头部信息和描述被呼叫方资源的SDP（Session Description Protocol）。
（2）呼叫响应：被呼叫方在收到INVITE消息之后，会返回一个响应。
响应分为三种：1xx、2xx和3xx+。
其中，1xx表示正在进行中，2xx表示成功建立，3xx+表示需要重定向。
“成功建立”的响应会包含会话描述信息，即SDP。
在响应中，还可以通过Location字段告知客户端新的地址信息。
3.呼叫传送呼叫传送是会话建立之后，实际传输媒体数据的阶段。
SIP协议支持多种传输协议，包括UDP、TCP和TLS等。
在呼叫传送消息过程中，需要用到RTCP（Real-time Transport Control Protocol）和RTP （Real-time Transport Protocol）协议进行音视频流传输控制。
4.会话终止当一次会话结束时，需要发送一个BYE消息。
BYE消息用于释放会话资源，并告知接收方会话已经结束。
SIP知识培训-信令分解
Q&A Thank you!
目录
SIP简介
信令分解
FAQ
整体框架
整体架构
SIP是一个应用层的控制协议，可以用来建立、修改、和终止多媒体会话。
SIP本身不提供服务，只是作为一个部件与其他协议一起组成完整的多媒体架构。
SIP
DNS
RTCP
RTP
TCP
UDP
IPV4 IPV6 数据链路层 物理层
信令分解
协议现状
一、SIP在VCS的应用相对较少，主要因为： 1.市面看到的服务器均无法有效支撑NAT、视频、带宽控制、辅流的实现。 2.高级业务没有明确RFC标准，即使能够支持NAT、视频的MCU在辅流的兼容性上差强人意。
一方SDP不支持RTCP-FB，则默认采用INFO，但需要注意的是，服务器可能连INFO也不支持， 回复415 Unsupprot，此时黑屏概率较大。 视频丢帧现象回忆：建立呼叫丢第一帧出现黑屏，通话过程丢帧出现花屏。
信令分解 Info DTMF
Info不仅可以用于帧同步，还可以用于DTMF发送，区别在于Content-Type头域不同。另外加
400 Bad Request，请求错误，一般为注册服务器后开启BFCP呼叫导致。
403 Forbidden，鉴权错误，一般为注册时密码错误导致。
404 Nofound，未发现，一般指呼叫的号码不存在。 408 Temporarily unavaialbe，请求超时，一般网络异常或远端不可用，导致呼叫网络超时。 415 Unsupported media type，不支持的媒体类型，一般为服务器不支持INFO帧同步导致。 480 Unavaiable，临时失效，比较常见的是对方号码未注册或者远端终端异常拒绝。 488 Not Acceptabale，请求不接受，一般协商失败导致，注意查看Codec使用情况。
SIP呼叫典型流程图解及详细解释
SIP呼叫典型流程图解及详细解释目录1.Sip协议的相关术语： (2)2.注册流程 (4)3.注销流程： (6)4.基本呼叫建立过程： (7)5.会话更改流程： (9)6.正常呼叫释放过程： (12)7.被叫忙呼叫释放： (13)8.被叫无应答流程一： (14)9.被叫无应答流程二： (15)10.遇忙呼叫前转： (16)11.无应答呼叫前转流程： (18)12.呼叫保持： (20)13.呼叫等待： (23)14.盲转流程 (27)15.询问转的流程 (30)16.彩铃的流程 (31)17.三方通话 (34)1.Sip协议的相关术语：A拨打B,A到proxy是一个session，一个dialog，proxy到b是另一个dialog，有另一个session name。
Invite，ack，bye，option，update，cancel消息，每发一个就是一个事务。
每发一个请求，cseq加1，但cancel，ack，bye请求的cseq同invite的cseq。
Callid，from tag，to tag标识一次对话。
Invite消息中有from tag，没有to tag，100 trying应答也没有to tag。
被叫发的bye 中from，to的tag和180和200ok的值。
每个事务用via字段里的branch的值来区分，invite到200ok之间属于一个事务，bye是另一事务。
语音流，被叫收到ack后发一个rtp流。
2.注册流程3.注销流程：终端代理代理服务器REGISTER (1)200 OK (4)标题（1） 终端向代理服务器送Register 消息注销，其头中expire 字段置0。
（2） 代理服务器收到后回送200 OK 响应，并将数据库中的用户有关信息注销。
4.基本呼叫建立过程：5.会话更改流程：用户代理服务端用户代理客户端通话 (1)Invite (2)200 OK (3)ACK (4)标题（2） 用户代理服务端向用户代理客户端发送Inivte消息,带有新的SDP协商信息。
SIP事件扩展REFER方法研究
-1-
以下是 Refer 方法的文本描述 Message One (F1) REFER sip:Bob@Bob.example SIP/2.0 Via: SIP/2.0/UDP Alice.example;branch=z9hG4bK39203984 To: sip:Bob@Bob.example From: sip:Alice@Alice.example;tag=39092342 Call-ID: 2203900ef0299349d9209f023a CSeq: 1239930 REFER Max-Forwards: 70 Contact: <sip:Alice.example> Refer-To: <sip:Carol@target.example> Referred-By: <sip:Alice@Alice.example>
;cid="20398823.2UWQFN309shb 3@Alice.example" Content-Type:multipart/mixed;boundary=uniq ue-bound Content-Length: (appropriate value)
中国电信 SIP协议细则
（试行）
2004 年 4 月发布
2004 年 4 月试行
中国电信集团公司发布
前
言
SIP 协议是下一代网络中的接口协议之一， 属于应用控制协议。 本标准是以 IETF 和 ITU-T 的相关标准为基础，结合中国电信网络的实际情况，并综合中国电信集团 公司对下一代网络的实验成果制定的。 它是中国电信在下一代网络建设中引进、测试和研发软交换设备、SIP 终端设 备以及其他基于 SIP 协议相关设备的规范和依据。鉴于 SIP 协议应用范围广泛，项 目组在编写时将整个协议规范分为 3 个分册： 第一分册： 《总体要求》 第二分册： 《协议细则》 第三分册： 《信令流程》
Байду номын сангаас-3-
中国电信 SIP 协议规范----协议细则
中国电信 SIP 规范 章节 7.4.1 7.4.2 7.5 标题 Message Body Type Message Body Length Framing SIP messages 用户终端 代理服务 器 UA ------------SIP-ISUP 互通单元 ------B2BUA ------注册服务 器 ------说明
-4-
中国电信 SIP 协议规范----协议细则
中国电信 SIP 规范 章节 8 标题 General User Agent Behavior 用户终端 代理服务 器 UA ----SIP-ISUP 互通单元 --B2BUA --注册服务 器 --1. 说明 本章主要描述 User Agent 的行为， 但由于实现 proxy 功能的实体在处理消息时 可能转而承担 UAC 或 UAS 的角色，因此 16 章 中有些内容的描述也参照 了本章。但本章中的某些 细节性规定并不适合 UAC 或 UAS 在第 16 章中 的应用场合。 根据第 1 点的说明，本章 中对 Proxy 的要求实质上 是对实现 Proxy 功能的实 体在转而承担 UAC 或 UAS 角色时的要求，因此 本章内容对此种应用场合 下的 UAC 或 UAS 而言可 能都是部分要求。为了说 明上的方便，本章内容对 于 “Proxy” 只存在 “要求” 或“不适用”，如果有特 殊考虑将在“说明”一栏 中进行解释
Sip 临时消息可靠传输
Sip 临时消息可靠传输SIP标准中规定，规定了在呼叫建立过程中对临时消息可靠传输的定义，在其他过程中，可以借鉴这种机制，但不是作为标准制定。
如果呼叫建立需要支持临时消息的可靠性，需要加上SIP头——supported或者require，该头部任选参数为100rel。
require表明需要对端支持，supported表明本次呼叫不要求可靠传输，但本端支持，由UAS决定。
如果对断不支持，需要回420消息，并且在头部中加上Unsupported字段，并且该字段的参数为100rel。
举例说明，如果Invite消息中包含require或者supported字段，并且为100rel，则对端在100 Trying后，发送后续101-199事件需要设定指数类型的定时器。
此时钟和invite应答的重传时钟应该相互独立。
当收到PRACK后，需要对进行匹配，如果匹配的话，重传时钟就可以中止了。
所谓匹配就是指PRACK和临时响应处于同一个会话，且RAck中的方法，CSeq-num,response-num在此一对消息中都是吻合的。
C->S:INVITE sip:watson@ SIP/2.0Via: SIP/2.0/UDP Supported: 100relFrom: sip:alexander@To: sip:watson@Call-ID: 70710@CSeq: 1 INVITESubject: Come here WatsonS->C:SIP/2.0 100 TryingVia: SIP/2.0/UDP From: sip:alexander@To: sip:watson@Call-ID: 70710@CSeq: 1 INVITES->C:SIP/2.0 183 ProceedingRequire: 100relVia: SIP/2.0/UDP RSeq: 776655From: sip:alexander@To: sip:watson@;tag=11Call-ID: 70710@CSeq: 1 INVITEContent-Type: application/sdpv=0s=Let's talkb=CT:128c=IN IP4 m=audio 3456 RTP/A VP 5 0 7m=video 2232 RTP/A VP 31C->S:PRACK sip:watson@ SIP/2.0RAck: 776655 1 INVITEVia: SIP/2.0/UDP From: sip:alexander@To: sip:watson@;tag=11Call-ID: 70710@CSeq: 2 PRACKContent-Type: application/sdpv=0s=Let's talkb=CT:128c=IN IP4 m=audio 3456 RTP/A VP 5 0 7m=video 2232 RTP/A VP 31S->C:SIP/2.0 200 OKVia: SIP/2.0/UDP From: sip:alexander@To: sip:watson@;tag=11Call-ID: 70710@CSeq: 2 PRACKS->C:SIP/2.0 182 Two in the QueueVia: SIP/2.0/UDP Require: 100relRSeq: 776656From: sip:alexander@To: sip:watson@;tag=11Call-ID: 70710@CSeq: 1 INVITES->C:SIP/2.0 182 One in the QueueVia: SIP/2.0/UDP Require: 100relRSeq: 776657From: sip:alexander@To: sip:watson@;tag=11Call-ID: 70710@CSeq: 1 INVITEC->S:PRACK sip:watson@ SIP/2.0RAck: 776656 1 INVITEVia: SIP/2.0/UDP From: sip:alexander@To: sip:watson@;tag=11Call-ID: 70710@CSeq: 3 PRACKC->S:PRACK sip:watson@ SIP/2.0RAck: 776657 1 INVITEVia: SIP/2.0/UDP From: sip:alexander@To: sip:watson@;tag=11Call-ID: 70710@CSeq: 4 PRACKS->C:SIP/2.0 200 OKVia: SIP/2.0/UDP From: sip:alexander@To: sip:watson@;tag=11Call-ID: 70710@CSeq: 3 PRACKS->C:SIP/2.0 200 OKVia: SIP/2.0/UDP From: sip:alexander@To: sip:watson@;tag=11Call-ID: 70710@CSeq: 4 PRACKS->C:SIP/2.0 200 OKVia: SIP/2.0/UDP From: sip:alexander@To: sip:watson@;tag=11Call-ID: 70710@CSeq: 1 INVITEContent-Type: application/sdpv=0s=Let's talkb=CT:128c=IN IP4 m=audio 3456 RTP/A VP 5 0 7m=video 2232 RTP/A VP 31C->S:ACK sip:watson@ SIP/2.0Via: SIP/2.0/UDP From: sip:alexander@To: sip:watson@;tag=11Call-ID: 70710@CSeq: 1 INVITECaller Calleed| || ||(1) INVITE ||---------------------- ------->|| || ||(2) 100 ||<------------------------------||(2) 183 ||<------------------------------|| || ||(3) PRACK ||------------------------------>|| || ||(4) 200 PRACK ||<------------------------------|| ||(5) 182 two ||<----------------------------- || || ||(6) 182 one ||<------------------------------|| ||(7) PRACK ||------------------------------>||(8) PRACK ||------------------------------>||(9) 200 PRACK ||<------------------------------|| ||(10) 200 PRACK ||<------------------------------|| ||(11) 200 ok ||<-------------------------------|| ||(12) ACK ||<-------------------------------|以上的例子摘自draft-ietf-sip-100rel-02.txt，从这个例子中可以看到PRACK发送的原理和参数要求。
sip协议以及其编码标准
IP电话、传真业务总体技术要求前言本标准对不同IP电话运营者之间的互通、IP电话的网络体系结构、协议、编号、网络性能等多方面内容作出了明确规定。
从国际标准化的符合程度和互通方面考虑，目前我国IP电话/传真网的建设应以ITU-T H. 323 建议为基础。
本标准主要参照见H.323v2 随着V oIP技术的不断发展．需要对本标准进行补充和完善。
IP电话业务包括电话到电话、PC到电话、电话到PC和PC 和PC，本标准对电话到电话和PC到电话作了明确的规定，电话到PC的业务有待进一步研究，故仅对编号作了规定，PC到PC业务不属于本标准规定的范畴。
IP实时传真业务（简称IP传真）包括传真机到传真机、IAF（Internet Aware Fax）到传真机、传真机到IAF 和IAF到IAF 4种，目前只开放传真机到传真机的业务。
本标准为我国IP电话/传真网络的规划、设备研制、工程设计和运营维护提供技术依据。
本标准的附录A为标准的附录。
本标准由信息产业部电信研究院提出并归口。
本标准起草单位：信息产业部电信传输研究所深圳市华为技术有限公司上海贝尔有限公司本标准主要起草人：蒋林涛叶冠华叶华陈忠杨昆沈群谢玮1 范围本标准规定了开展IP电话／传真业务的网络体系结构、协议、编号、计费、用户认证、地址解析、网络性能和不同运营者的IP电话之间的互通等要求。
本标准适用于国内IP电话/传真网络的规划、设备研制、工程设计和运营维护。
2 引用标准下列标准所包含的条文，通过在本标准中引用而构成为本标准的条文。
在标准出版时，所示版本均为有效。
所有标准都会被修订，使用本标准的各方应探讨使用下列标准最新版本的可能性。
ITU- T H.323：1998 用于提供不保证质量的业务本地网上的可视电话系统和终端设备ITU- T H．225．0：1998用于不保证质量的业务本地网上的可视电话系统的媒体流的打包与同步ITU-TH245：1998 多媒体通信的控制协议RFC2138：1997 RADIUS协议RFC2139：1997 RADIUS计费协议ITU-T T.30：1998 文件传真在公用电话交换网上的传输规程ITU- T T．38：1998 三类终端间通过IP网络的实时通信的规程TU-T G．711：1988 话音频率的脉冲编码调制ITU- T G729：1996 运用共轭结构代数码线形预测激励的8kbit/s语音编码ITU-T G．728：1992 采用线形预测激励的低时延码在16kbit／s速率上的语音编码ITU-T G.723.1:1996 以5.3kbit/s和6.3kbit/s 为速率的多媒体通信的双速语音编码器3 定义本标准采用下列定义：IP电话（IP Telephony）：在IP网上传送的具有一定服务质量的语音业务。
sip 协议讲解
sip 协议讲解SIP协议是一种用于建立、修改和终止实时通信会话的协议。
它是一种应用层协议，用于在互联网上传输多媒体通信数据。
SIP协议的全称是Session Initiation Protocol，它的设计目标是提供一种简单、灵活、可扩展的通信协议，以便在不同的网络环境下进行实时通信。
SIP协议的核心思想是基于客户端-服务器模型的，其中有两个重要的角色：用户代理（User Agent）和SIP服务器。
用户代理可以是一个软件应用或硬件设备，它负责与用户进行交互，并将用户的请求发送到SIP服务器。
SIP服务器则负责处理这些请求，并根据请求的内容来建立、修改或终止通信会话。
SIP协议定义了一系列消息格式，包括请求消息和响应消息。
请求消息用于向服务器发送请求，而响应消息则是服务器对请求的回应。
这些消息可以通过网络传输，以实现通信会话的建立和管理。
SIP 协议还定义了一些重要的功能，如呼叫转移、呼叫等待和呼叫会议等。
在建立通信会话时，SIP协议使用统一资源标识符（Uniform Resource Identifier，URI）来标识参与通信的各方。
URI是一种用于唯一标识资源的字符串，它可以是一个电话号码、一个电子邮件地址或一个网址等。
通过URI，SIP协议可以将不同的通信终端连接起来，实现实时通信。
SIP协议还支持会话描述协议（Session Description Protocol，SDP），用于描述通信会话的参数和能力。
SDP可以包含音频、视频和其他媒体的编码格式、传输协议和网络地址等信息，以便各方能够正确地进行媒体数据的传输和解码。
总的来说，SIP协议是一种强大而灵活的通信协议，它可以在不同的网络环境下实现实时的多媒体通信。
它的设计目标是简单易用、可扩展和高效可靠的。
通过SIP协议，我们可以实现语音通话、视频通话、实时消息和在线会议等多种实时通信应用。
SIP协议的发展和应用将进一步推动互联网通信的发展，为人们的生活和工作带来更多的便利和可能性。
SIP协议参数详解
SIP协议参数详解1.1 SIP消息分类SIP协议是以层协议的形式组成的，就是说它的⾏为是以⼀套相对独⽴的处理阶段来描述的，每个阶段之间的关系不是很密切。
SIP协议将Server和User Agent之间的通讯的消息分为两类：请求消息和响应消息。
请求消息：客户端为了激活特定操作⽽发给服务器的SIP消息，包括INVITE、ACK、BYE、CANCEL、OPTION和UPDATE消息。
SIP请求的6种⽅法： 1、邀请（INVITE）——邀请⽤户加⼊呼叫 2、确认（ACK）——确认客户机已经接收到对INVITE的最终响应 3、可选项（OPTIONS）——请求关于服务器能⼒的信息 4、再见（BYE）——终⽌呼叫上的两个⽤户之间的呼叫 5、取消（CANCEL） 6、注册（REGISTER）——提供地址解析的映射，让服务器知道其它⽤户的位置响应消息：服务器向客户反馈对应请求的处理结果的SIP消息，包括1xx、2xx、3xx、4xx、5xx、6xx响应1.2 SIP消息结构请求消息和响应消息都包括SIP消息头字段和SIP消息体字段；SIP消息头主要⽤来指明本消息是有由谁发起和由谁接受，经过多少跳转等基本信息；SIP消息体主要⽤来描述本次会话具体实现⽅式；1.3 消息格式1.3.1 请求消息格式SIP请求消息的格式，由SIP消息头和⼀组参数⾏组成，如图3-1所⽰。
通过换⾏符区分命令⾏和每⼀条参数⾏。
图1-1 SIP请求消息结构注意：参数⾏的顺序不是固定的。
对应的参数解释见6.3 。
消息体定义：Call-ID：头字段是⽤来将消息分组的唯⼀性标识 From：头字段是指⽰请求发起⽅的逻辑标识，它可能是⽤户的注册地址。
From头字段包含⼀个URI和⼀个可选的显⽰名称 CSeq：头字段⽤于标识事务并对事务进⾏排序。
它由⼀个请求⽅法和⼀个序列号组成，请求⽅法必须与对应的请求消息类型⼀致 Max-Fowords：头字段限定⼀个请求消息在到达⽬的地之前允许经过的最⼤跳数。
sip refer 流程
sip refer 流程SIP（Session Initiation Protocol）是一种用于建立、修改和终止多媒体会话的通信协议。
在SIP通信中，"Refer"是一种重要的消息类型，它允许一个用户代理（UA）将正在进行的会话转发给另一个UA。
下面我将用人类的视角，向您描述一下SIP Refer流程。
假设Alice和Bob是两个使用SIP协议的用户。
Alice希望将她正在进行的会话转发给Bob，于是她的UA向Bob的UA发送一个"Refer"消息。
在这个消息中，Alice的UA会提供一些必要的信息，比如会话的标识符、目标UA的地址等等。
当Bob的UA收到"Refer"消息后，它会首先验证该消息的合法性。
如果一切正常，Bob的UA会向Alice的UA发送一个"202 Accepted"消息，表示它接受了这个转发请求。
接着，Bob的UA会根据"Refer"消息中提供的信息，与目标UA建立新的会话。
在这个过程中，Bob的UA会发送一个INVITE消息给目标UA，邀请它参与会话。
如果目标UA接受了这个邀请，它会回复一个"200 OK"消息，表示它已经准备好参与会话了。
当Bob的UA收到目标UA的"200 OK"消息后，它会向Alice的UA发送一个"200 OK"消息，表示新的会话已经建立成功。
同时，Bob的UA会将Alice的UA从原来的会话中删除，这样Alice和Bob之间的会话就被成功转发了。
需要注意的是，SIP Refer流程中还有一些额外的细节和步骤，比如身份验证、会话描述协议的交换等等。
但为了简化描述，我在这里只介绍了基本的流程。
通过上述描述，我们可以看到SIP Refer流程的整体步骤。
它允许一个用户将正在进行的会话转发给另一个用户，为实现实时通信提供了便利。
05 sip字段说明
SIP协议的各字段分析和各种功能的应用一、SIP字段说明1．Request-LineRequest-Line = Method SP Request-URI SP SIP-Version包含method名字、一个Request-URI和一个用空格隔开的协议版本号。
Method包含SIP协议的6种命令：Register、Invite、ACK、Cancel、BYE和Options；Request-URI：标注被叫的号码或者是名字以及服务器的地址或者是URI地址；SIP-Version：在请求消息和应答消息中都包含有SIP的协议版本号，一般是“SIP/2.0”。
2．ResponsesStatus-Line = SIP-Version SP Status-Code SP Reason-Phrase应答命令是用来回应请求命令的，状态行包含协议版本、状态码和原因描述（用文本方式描述状态）；状态码有1XX、2XX、3XX、4XX、5XX和6XX等六种，分别描述不同的内容。
3．Header FieldsVia：用来标识应答消息的返回路径，包含SIP版本、通过的路径、branch；在应答包中会看到此包经过别的路径后加进去的路径参数，如果是经过了NA T，那么里面会加上received=ip,rport=port这类的参数Max-Forwards：用来表示这个包最多可以被传送多少跳，当此值为0还没有到达目的地时，系统会回483（Too Many Hops）；一般在含有request的源包里面带有这个字段，默认值正常的都是设置为70User-Agent：终端设备自己填写的关于设备方面的信息，没有具体用处From：源的display name和源的URI；&前面带的是设备号或者是主叫号码，&后面带的是proxy的地址To：目的地的绝对地址，包含被叫display name和被叫URI；&前面带的是设备号或者是被叫号码，&后面带的是proxy的地址Call-ID：是一个唯一的标识符，在一通呼叫中请求和应答消息中的Call-ID是唯一的Contact：包含源的URI信息，用来给响应消息直接和源建立连接用CSeq：用来标识命令和命令顺序，用32位无符号整数来表示，要小于2**31Expires：在注册包和注册应答包中携带，用来协商URI的有效时间，当为0的时候表示注销设备，没有Expires的时候会被系统拒绝（现在做了修改，如果没有这个字段，系统会把此值当作是3600）Allow：允许的命令Supported：支持的操作，例如：replace等Content-Type：指明消息体的类型Content-Length：指明消息体的字节大小4．Message bodySDP协议版本会话名，例如：SIP CALLConnection Information：Connect Network Type现在只有IN（Internet）；Connection Address Type 现在只有IP4和IP6两种；Connection Address可以为单播地址或多播组地址，如果是多播组地址还必须有一个生存时间（TTL）值，如：c＝IN IP4 224.2.1.1/127，表示TTL＝127秒Time Description：标明会话的开始时间和终止时间Media Description：包含媒体类型、端口、传送层和格式列表4部分，传送层描述的是Media Protocol，例如：RTP/A VP表示IETF RTP协议，udp表示UDP协议；格式列表列举出支持的codec类型Media Attribute：有两种描述方式：a=<属性>或a=<属性>：<值>，第一种形式称为特殊属性，无须规定数值，如：a=recvonly表示该媒体信道是“只收”信道；第二种形式称为数值属性，例如：Media Attribute Value：18 G729/8000这种形式二、一些功能信令流程1．Refer（Transfer业务）命令的使用对于SIP信令的Transfer应用，主要用到的命令就是Refer，在B挂机后会向系统发出Refer命令，系统回应一个Accepted（202）命令，然后系统再会一个Notify命令，B回应200 OK后，过程结束，具体的信令流程和信令内容请查看SIP Transfer文档，下面列举如下：Attended Call TransferMessage 1REFER sip:b@ SIP/2.0Via: SIP/2.0/UDP ;branch=z9hG4bK2293940223To: <sip:b@>From: <sip:a@>;tag=193402342Call-ID: 898234234@CSeq: 93809823 REFERMax-Forwards: 70Refer-To: (whatever URI)Contact: sip:a@Content-Length: 0Message 2SIP/2.0 202 AcceptedVia: SIP/2.0/UDP ;branch=z9hG4bK2293940223To: <sip:b@>;tag=4992881234From: <sip:a@>;tag=193402342Call-ID: 898234234@CSeq: 93809823 REFERContact: sip:b@Content-Length: 0Message 3NOTIFY sip:a@ SIP/2.0Via: SIP/2.0/UDP ;branch=z9hG4bK9922ef992-25To: <sip:a@>;tag=193402342From: <sip:b@>;tag=4992881234Call-ID: 898234234@CSeq: 1993402 NOTIFYMax-Forwards: 70Event: referSubscription-State: active;expires=(depends on Refer-To URI)Contact: sip:b@Content-Type: message/sipfrag;version=2.0 普通呼叫的type为：application/sdp Content-Length: 202．Replace的使用过程如下图所示：3．Early Media Applications在SIP的Early Media中使用的是183信令来实现，如下图：4．SIP自动callback的应用5．用Instant Message to Transfer a Call6．SIP Message Waiting7．SIP Call Control in Conferencing三、新功能1．SigCompthe Signaling Compression (SigComp) add-on module is a solution for compressing SIPsignaling. Since SIP messages are text based, they are not optimized in terms of size. For example, typical SIP messages range from a few hundred bytes to two thousand bytes or more (RFC 3261). With the planned usage of these protocols in wireless and cellular handsets, and as part of the 3GPP (Third Generation Partnership Project) requirements for IMS (IP Multimedia Subsystem), the large message size is problematic and message compression is mandatory.2．DLA (Dynamic Local Address)enables the dynamic opening and closing of the local IPaddresses, which are used for request sending and reception, at any moment of the SIP Stack life cycle. This feature is typically used with multihomed host. DLA is used for broadband (DSL, cable), as well as wireless and cellular networks, to support handoffs and IP address changes by service providers.3．IP_TOSdetermines the value of the Type of Service field in the IP header of all packets that aresent over the outgoing connections. (Supported for IPv4 addresses only.)4．Transmitter Objectthe SIP Stack uses transmitter objects for message sending. Each transactionobject holds a single transmitter object and uses it to send SIP messages and message retransmissions. The application can use this new object for sending an out-of-scope request or response without using the Transaction layer.5．REFER RFC 3515REFER is a SIP method defined by RFC 3515 (Session Initiation ProtocolRefer Method). The REFER method indicates that the recipient of the REFER request should contacta third party using the contact information provided in the REFER request. RFC 3515 provides a mechanism allowing the party that is sending the REFER to be notified of the outcome of the referenced request with a NOTIFY request. This implementation uses subscription objects forREFER implementation. It replaces the previous REFER implementation and is introduced due to standard modifications.6．Client-side forkingin previous SIP Toolkit versions, if a request was forked, the SIP Stack on theclient side automatically connected the first established dialog, and did not allow the application to choose a different dialog or connect multiple dialogs. In the current version, the Call-leg and Subscription modules were enhanced to allow this flexibility.7．Merging disablingif a proxy forks a request and eventually the two requests are terminated at the same User Agent Server (UAS), the UAS needs to merge them into one request. There are cases where the UAS is a gateway and therefore will want to avoid the message merging. This flexibility is currently available.8．Transport Layer enhancementstwo functionalities were added. An application can now block incoming connections even before data was received on them .This lets the application implement a white/black IP address list and handle the denial of service attacks in a better way. Access to the incoming raw buffer so that the application candump buffer to file or discard the buffer, for example.9．A-synchronous DNSDNS functionality was enhanced and is now a-synchronous, improving performance especially formulti-session applications such as gateways and servers.10．DNS server runtime configurationin some cases, it is required to change the DNS server that is being used at runtime. This is now possible via the SIP Toolkit APIs.11．Manual PRACKthe application can now control the sending of PRACK/200. This is an addition to the automatic functionality available in previous versions.12．Primitives compilation flagthis new compilation flag replaces the EXTRA_LEAN compilation flag. It removes the dialog layer, allowing application to work directly above the Transaction layer. Additionally, it removes specific support of certain headers. The application can still use these headers by adding specific support in the application itself.13．Middle Layer for low-level servicesthe RADVISION operating system abstraction layer was wrapped and some of its APIs are now exposed so the application can use services such as timers and select.14．Via header controlsome implementations, such as when using a STUN/TURN server, require manual modification of the Via header after DNS was completed. This control and flexibility is now possible.15．Subscription high availabilitythe RADVISION SIP Stack provides a store and restore mechanism that enables the application to back up subscriptions in the ACTIVE state. Backing up subscriptions lets application developers implement redundancy capabilities in their systems, allowing back-up systems to “take over” when the primary system goes down. When storing an active subscription, all of the subscription parameters are copiedinto a consecutive buffer. The application can then save this buffer and use it when restoring the backup object.16．Authentication enhancementthe authentication mechanism enables a User Agent Client (UAC) to prove authenticity to servers or proxies which require authentication. The SIP Stack supports SIP authentication using the HTTP Digest Scheme as described in RFC 3261 and RFC 2617. In the current version, support of the “auth-int” quality of protection (qop) was added. For server-side authentication, only “auth” qop is supported.17．Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP) 【rfc4189】A Session Initiation Protocol (SIP) User Agent (UA) does not always trust all intermediaries in its request path to inspect its message bodies and/or headers contained in its message. The UA might want to protect the message bodies and/or headers from intermediaries, except those that provide services based on its content. This situation requires a mechanism called "end-to-middle security" to secure the information passed between the UA and intermediaries, which does not interfere with end-to-end security. This document defines a set of requirements for a mechanism to achieve end-to-middle security18．The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP) 【rfc4168】This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport mechanism between SIP (Session Initiation Protocol) entities. SCTP is a new protocol that provides several features that may prove beneficial for transport between SIP entities that exchange a large amount of messages, including gateways and proxies. As SIP is transport-independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP19．Session Initiation Protocol (SIP)-H.323 Interworking Requirements 【rfc4123】This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function (SIP-H.323 IWF) that will allow the interworking between SIP andH.32320．Transcoding Services Invocation in the Session Initiation Protocol (SIP)Using Third Party Call Control (3pcc)【rfc4117】This document describes how to invoke transcoding services using Session Initiation Protocol (SIP) and third party call control. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals21．Usage of the Session Description Protocol (SDP)Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)【rfc4092】This document describes how to use the Alternative Network Address Types (ANAT) semantics of the Session Description Protocol (SDP) grouping framework in SIP. In particular, we define the sdp-anat SIP option-tag. This SIP option-tag ensures that SDP session descriptions that use ANAT are only handled by SIP entities with ANAT support. To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT22．Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP) 【rfc4083】The 3rd-Generation Partnership Project (3GPP) has selected Session Initiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of Release 5 of the 3GPP specifications. Although SIP is a protocolthat fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this document, we express the requirements identified by 3GPP to support SIP for Release 5 of the 3GPP IMS in cellular networks23．Update to the Session Initiation Protocol (SIP)Preconditions Framework【rfc4032】This document updates RFC 3312, which defines the framework for preconditions in SIP. We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility24. Interworking SIP and Intelligent Network (IN) Applications【rfc3976】Public Switched Telephone Network (PSTN) services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network (IN). This document addresses means to support existing IN services from Session Initiation Protocol (SIP) endpoints for an IP-host-to-phone call.The call request is originated on a SIP endpoint, but the services to the call are provided by the data and procedures resident in the PSTN/IN. To provide IN services in a transparent manner to SIP endpoints, this document describes the mechanism for interworking SIP and Intelligent Network Application Part (INAP)25．The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP) 【rfc3969】This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) and SIPS Uniform Resource Identifier (URI) parameters, and their values. It alsolists the already existing parameters to be used as initial valuesfor that registry26．The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)【rfc3968】This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) header field parameters and parameter values. It also lists the already existing parameters and parameter values to be used as the initial entries for this registry27．Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP) 【rfc3960】This document describes how to manage early media in the Session Initiation Protocol (SIP) using two models: the gateway model and the application server model. It also describes the inputs one needs to consider in defining local policies for ringing tone generation28．The Session Initiation Protocol (SIP) "Join" Header 【rfc3911】This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logicallyjoin an existing SIP dialog with a new SIP dialog. This primitivecan be used to enable a variety of features, for example: "Barge-In", answering-machine-style "Message Screening" and "Call Center Monitoring".Note that definition of these example features is non-normative29．Session Initiation Protocol (SIP) Extension for Event State Publication【rfc3903】This document describes an extension to the Session InitiationProtocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is for the publication of presence information. The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose30．Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format【rfc3893】RFC 3261 introduces the concept of adding an S/MIME body to a Session Initiation Protocol (SIP) request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an ’authenticated identity body’, a digitally-signed SIP message, or message fragment. A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs byrecipients of SIP messages with such bodies are also given 31．The Session Initiation Protocol (SIP) Referred-By Mechanism【rfc3892】The Session Initiation Protocol (SIP) REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI,the referee will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present32．The Session Initiation Protocol (SIP) "Replaces" Header 【rfc3891】This document defines a new header for use with Session Initiation Protocol (SIP) multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable avariety of features, for example: "Attended Transfer" and "Call Pickup". Note that the definition of these example features is non- Normative33．S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)【rfc3853】RFC 3261 currently specifies 3DES as the mandatory-to-implement ciphersuite for implementations of S/MIME in the Session Initiation Protocol (SIP). This document updates the normative guidance of RFC 3261 to require the Advanced Encryption Standard (AES) for S/MIMEOnline Resources for SIPHenning Schulzrinne’s SIP Page/sip and supplementary SIP and SIPPING archives:/sipwg/drafts//sipping/drafts/IP Telephony Web PageSIP ForumSIP CenterSIP Products at 。
SIP协议解析(华为内部)
4
PRACK
5
ACK
6
BYE
7 487 Request Terminated
SGA
成功的SIP-T呼叫流程
SoftX3000A
SoftX3000B
IAM
1 INVITE
IAM
ACM
2 100 Trying 3 180 Ring
4 200 OK
ACM ANM
ANM
5 ACK
SGB
Conversation
呼叫参数； 呼叫处理和控制：包括呼叫重定向、呼叫转移、终止
呼叫等等。
术语
呼叫 事务
SIP是一个客户/服务器协议。客户和服务器之间的操 作从第1个请求至最终响应为止的所有消息构成一个 SIP事务。
SIP URL——寻址方式，例如：
Sip; 55500200@127.0.0.1:5061; User=phone; Sip: alice@;method=REGISTER;
ACK
证实已收到对于INVITE请求的最终响应。该消息仅和INVITE消息配套 使用。
BYE
结束会话
CANCEL
取消尚未完成的请求，对于已完成的请求（即已收到最终响应的请求） 则没有影响
REGISTER 注册
OPTIONS 查询服务器的能力
响应消息
序号 1xx
2xx 3xx 4xx
5xx 6xx
状态码
200 OK
SIP实体之间的SIP呼叫流程
SIP PhoneA
SoftX3000
SIP PhoneB
1
INVITE
2 100 Trying
3
407
4
ACK
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
SIP协议 REFER 信令标准用法
随着互联网技术的发展，VoIP（Voice over Internet Protocol，互联网通信方式）已经得到了广泛的应用。
而在VoIP通信中，SIP （Session Initiation Protocol，会话初始协议）作为一种重要的协议，扮演着连接用户、发起、参与和结束多媒体会话的关键角色。
在SIP
协议中，REFER信令标准用法是一个基础而又重要的部分。
在本文中，我们将从SIP协议的基本介绍开始，逐步展开对REFER信令标准用法的解释和讨论，帮助读者更深入地了解SIP协议REFER信令的标准用法，并且为其在实际应用中的场景提供参考。
一、SIP协议基本介绍
1. SIP协议的定义
SIP协议是一种应用层控制协议，用于在IP网络上建立、修改和终止
会话。
它是一种典型的C/S（Client/Server，客户端/服务器）架构协议，其主要特点包括灵活性、可扩展性和与传统通信方式网络的互通性。
2. SIP协议的特点
SIP协议具有以下几个特点：
（1）灵活性：SIP协议可以在不同的网络环境和设备上运行，支持多
种媒体数据传输方式；
（2）可扩展性：SIP协议的结构简单，易于扩展，可以适应不断变化的网络需求；
（3）与传统通信方式网络的互通性：SIP协议可以与传统通信方式网络相互连接，实现VoIP与PSTN（Public Switched Telephone Network，公共交换通信方式网）之间的互通。
二、REFER信令标准用法
1. REFER信令的定义
在SIP协议中，REFER信令用于请求用户代理（User Agent，UA）将当前的通信会话引导至另一个目的地。
一般来说，REFER信令包含了被引用资源的标识符，以及引用原因的描述。
2. REFER信令的标准用法
REFER信令的标准用法包括以下几个方面：
（1）REFER请求的生成与处理：用户代理可以向服务器发起REFER 请求，并且服务器也可以将REFER请求转发给其他参与者；
（2）REFER请求的应答：当服务器接收到REFER请求后，需要作出相应的应答，以通知用户代理REFER请求的处理结果；
（3）REFER请求的超时处理：如果REFER请求在规定的时间内没有得到应答，需要进行超时处理，以保证通信会话的正常进行。
三、REFER信令标准用法的应用场景
1. 媒体服务协商
在VoIP通信中，可能需要对媒体服务进行协商，以提供更好的通话质量和用户体验。
REFER信令可以用于引导通信会话至支持特定媒体服务的服务器或代理，从而实现媒体服务的协商和提供。
2. 通话转移
在实际通信中，可能会涉及到通话转移的情况，例如用户移动至其他地点，需要将通话从一个终端转移到另一个终端。
REFER信令可以被用于引导通话转移，实现通话在不同终端之间的切换。
3. 会话协商
在多方通话的场景中，可能需要对通话参与者进行动态管理和调整。
REFER信令可以用于引导通话会话的加入、退出和切换，从而实现多方通话的灵活管理。
四、实际应用案例
以一个企业内部多方通话为例，假设企业中共有A、B、C三名员工，分别使用不同的终端进行通话。
在通话过程中，A希望将通话引导至另一个特定的会话终端，以便进行更深入的讨论。
在这种情况下，A可以向服务器发起REFER请求，指定新的通话目的地，并附上引用原因的描述。
服务器收到REFER请求后，可以根据引用原因和目的地的信息，作出相应的应答，并将通话会话引导至新的终端。
五、总结
SIP协议REFER信令标准用法作为SIP协议的一个重要组成部分，对于实现VoIP通信的灵活管理和协商具有重要意义。
通过对REFER信令标准用法的深入了解，可以帮助人们更好地应用SIP协议的功能，实现更多样化、灵活化的通信需求。
在实际应用中，我们需要根据具体的场景和需求，合理地使用REFER 信令，以实现通话会话的引导、转移和协商。
只有充分了解和掌握REFER信令的标准用法，才能更好地发挥SIP协议在VoIP通信中的作用，为用户提供更好的通话体验和服务质量。
通过以上的介绍和讨论，相信读者对SIP协议REFER信令标准用法有了更深入的了解。
希望本文能够对读者在实际应用中的SIP协议有所帮助，为VoIP通信的发展和应用提供一定的参考和借鉴价值。