SIP协议格式详解
SIP协议呼叫流程及协议分析
SIP协议呼叫流程及协议分析SIP（Session Initiation Protocol）是一种用于建立、修改和终止多媒体会话的应用层协议。
它是一种基于文本的协议，使用类似HTTP的请求-响应模式进行通信。
SIP协议在VoIP（Voice over Internet Protocol）和实时通信领域得到广泛应用。
本文将详细介绍SIP协议的呼叫流程及协议分析。
一、SIP协议呼叫流程1. 呼叫建立阶段呼叫建立阶段是SIP协议中最重要的阶段之一。
它包括以下步骤：- 呼叫发起方（Caller）向呼叫接收方（Callee）发送INVITE请求，该请求包含了呼叫的相关信息，如被叫方的SIP地址、媒体类型等。
- 呼叫接收方收到INVITE请求后，可以选择接受或拒绝呼叫。
如果接受呼叫，接收方将返回一个200 OK响应，表示呼叫已被接受。
- 呼叫发起方收到200 OK响应后，会发送一个ACK请求，确认呼叫已被接受。
2. 媒体协商阶段媒体协商阶段用于协商呼叫双方之间的媒体传输参数。
它包括以下步骤：- 呼叫发起方和呼叫接收方通过SDP（Session Description Protocol）交换媒体传输参数，如音频编解码器、传输协议等。
- 呼叫双方根据SDP中的参数进行媒体传输的配置。
3. 呼叫保持与呼叫转移呼叫保持和呼叫转移是SIP协议中的两个重要功能。
它们可以在呼叫过程中进行：- 呼叫保持：当一方需要将呼叫保持时，它会发送一个INVITE请求给另一方，并在请求中添加一个"hold"参数。
对方收到请求后，可以选择接受或拒绝呼叫保持。
- 呼叫转移：当一方需要将呼叫转移到另一方时，它会发送一个REFER请求给另一方，并在请求中指定新的被叫方。
对方收到请求后，可以选择接受或拒绝呼叫转移。
4. 呼叫结束阶段呼叫结束阶段用于终止呼叫。
它包括以下步骤：- 任何一方可以发送BYE请求给对方，表示希望终止呼叫。
SIP协议主要消息
SIP协议主要消息一、背景介绍SIP（Session Initiation Protocol）是一种用于建立、修改和终止会话的信令协议，广泛应用于VoIP（Voice over Internet Protocol）和实时通信系统中。
SIP协议主要消息是指在SIP通信过程中，各个参与方之间传递的消息，包括请求消息和响应消息。
本协议旨在规范SIP协议主要消息的格式和内容，以确保通信的可靠性和互操作性。
二、协议目的本协议的目的是定义SIP协议主要消息的标准格式，包括请求消息和响应消息的结构、字段和语义。
通过遵循本协议，各参与方能够准确理解和处理SIP协议主要消息，从而实现可靠的通信和互操作。
三、协议内容1. 请求消息格式：请求行：包括请求方法、请求URI和SIP协议版本。
头部字段：包括常用字段（如From、To、Call-ID、CSeq、Contact等）和可选字段（如Max-Forwards、User-Agent、Content-Type等）。
空行：用于分隔头部字段和消息体。
消息体：可选，用于传递附加数据。
2. 响应消息格式：状态行：包括SIP协议版本、状态码和原因短语。
头部字段：包括常用字段（如From、To、Call-ID、CSeq、Contact等）和可选字段（如Server、Content-Type等）。
空行：用于分隔头部字段和消息体。
消息体：可选，用于传递附加数据。
四、协议规范1. 请求方法：- INVITE：用于建立会话。
- ACK：用于确认接收到INVITE请求。
- OPTIONS：用于查询支持的功能和参数。
- BYE：用于终止会话。
- CANCEL：用于取消未被接受的请求。
- REGISTER：用于注册用户的位置信息。
- INFO：用于传递会话中的中间信息。
- PRACK：用于确认接收到可靠传输的请求。
2. 状态码：- 1xx：信息性响应，表示请求已被接收，但尚未完成。
- 2xx：成功响应，表示请求已成功处理。
VoIP技术协议之SIP协议
VoIP技术协议之SIP协议协议名称：VoIP技术协议之SIP协议一、引言本协议旨在规范VoIP（Voice over Internet Protocol）技术中的SIP（Session Initiation Protocol）协议的使用。
SIP协议是一种应用层协议，用于建立、修改和终止多媒体会话，如语音通话、视频会议等。
本协议详细描述了SIP协议的功能、消息格式、通信流程、状态码以及相关的扩展功能。
二、术语和定义1. VoIP：Voice over Internet Protocol的缩写，指通过互联网传输语音、视频和其他多媒体数据的技术。
2. SIP：Session Initiation Protocol的缩写，指用于建立、修改和终止多媒体会话的应用层协议。
3. 用户代理（User Agent）：指SIP协议的终端设备或软件，用于发起或接收SIP消息。
4. 代理服务器（Proxy Server）：指在SIP通信中转发消息的中间设备，负责处理请求和响应消息。
5. 注册服务器（Registrar Server）：指用于管理用户地址和状态信息的服务器，用于用户的注册和身份验证。
6. 会话描述协议（Session Description Protocol，SDP）：用于描述会话参数和媒体协商的协议。
三、SIP协议功能1. 会话管理：SIP协议允许用户代理发起、接受和终止会话，包括语音通话、视频会议等。
2. 用户定位：SIP协议通过URI（Uniform Resource Identifier）标识用户，可以根据URI找到用户的IP地址和端口号。
3. 媒体协商：SIP协议使用SDP协议进行媒体参数的协商，包括编解码器、传输协议、媒体格式等。
4. 会话控制：SIP协议支持会话的修改和终止，包括增加、删除或修改媒体流。
5. 身份验证：SIP协议支持用户的身份验证和安全机制，保护通信的机密性和完整性。
四、SIP消息格式SIP协议使用文本格式的消息进行通信，消息由请求和响应组成，具体格式如下：1. 请求消息格式：- 请求行：包括请求方法、URI和SIP协议版本。
sip协议register报文详解
sip协议register报文详解SIP协议的REGISTER报文是一种用于注册用户代理（UA）地址的请求消息。
当用户代理（UA）希望在SIP网络中注册其地址时，它会发送一个REGISTER请求消息到SIP注册服务器。
REGISTER请求消息的格式如下：```phpREGISTER sip:<registrar_server> SIP/Via: SIP//UDP<client_IP>:<client_port>;branch=z9hG4bKkdjuw5asdh234 From: <user_URI>To: <user_URI>Contact: <user_URI>Max-Forwards: 70Expires: <seconds>Authorization: <credentials>Content-Length: <length> (如果包含消息体)<message_body> (如果存在)```以下是REGISTER请求消息中各个字段的解释：`sip:<registrar_server>`：这是SIP注册服务器的地址。
`<registrar_server>`是SIP注册服务器的域名或IP地址。
`Via`：这是一个可选的字段，用于指定请求传递的路径。
它包含了一系列的SIP代理和网关的地址和端口信息，以及一个唯一的branch参数，用于标识该请求的唯一性。
`From`：该字段包含了发起请求的用户代理的地址。
它通常是一个SIP URI，表示发起请求的用户代理的身份。
`To`：该字段包含了接收请求的用户代理的地址。
它通常是一个SIP URI，表示接收请求的用户代理的身份。
`Contact`：该字段包含了发起请求的用户代理的地址。
它通常是一个SIP URI，表示发起请求的用户代理的直接联系地址。
SIP协议
1.简介SIP（Session Initiation Protocol）是一种用于实时通信的协议。
它被广泛应用于语音通话、视频会议、即时消息等领域。
SIP协议提供了一种机制，使得用户可以建立、修改和终止多媒体会话，同时允许参与者之间的媒体数据传输。
SIP协议的主要作用是在通信设备之间建立会话，包括语音通话、视频通话和多媒体会议等。
它定义了一套规则和消息格式，用于发起会话、管理会话状态以及传输媒体数据。
在实时通信中，SIP协议扮演着重要的角色。
它为用户提供了一种灵活且可扩展的方式来建立和管理通信会话。
通过SIP协议，用户可以轻松地与其他用户进行语音通话、视频通话或者发送即时消息。
SIP协议的重要性在于它的开放性和互操作性。
由于SIP是一个开放标准，各种通信设备和应用程序都可以通过实现SIP协议来实现互相之间的通信。
这种互操作性使得不同厂商和平台的设备可以无缝地进行通信，促进了实时通信的发展和普及。
总之，SIP协议在实时通信中发挥着关键的作用。
它通过定义会话的建立和管理方式，为用户提供了一种灵活、可扩展的通信方式，使得语音通话、视频通话和即时消息等应用成为可能。
其开放性和互操作性也为实时通信领域的发展做出了重要贡献。
2.SIP协议的基本原理SIP协议（Session Initiation Protocol）是一种基于文本的协议，用于建立和管理实时通信会话。
它采用了简单灵活的消息交换机制，允许参与者之间进行会话的发起、修改和终止。
SIP消息的格式SIP消息由文本行组成，每行以回车换行符（CRLF）结束。
常见的SIP消息有两种格式：请求消息和响应消息。
•请求消息：用于发起会话请求。
它包含请求行、头部字段和可选的消息体。
请求行指定了请求的方法（如INVITE、REGISTER、BYE等）和URI（统一资源标识符）。
•响应消息：用于回应请求消息。
它包含状态行、头部字段和可选的消息体。
状态行指定了响应的状态码（如200 OK、404Not Found等）和原因短语。
sip协议详解
SIP协议详解(中文)1、SIP协议介绍Internet的许多应用都需要建立和管理一个会话，会话在这里的含义是在参与者之间的数据的交换。
由于考虑到参与者的实际情况，这些应用的实现往往是很复杂的：参与者可能是在代理间移动，他们可能可以有多个名字，他们中间的通讯可能是基于不同的媒介（比如文本，多媒体，视频，音频等）－有时候是多种媒介一起交互。
人们创造了无数种通讯协议应用于实时的多媒体会话数据比如声音，影像，或者文本。
本SIP（会话初始协议）和这些协议一样，同样允许使用Internet端点（用户代理）来寻找参与者并且允许建立一个可共享的会话描述。
为了能够定位精确的会话参与者，并且也为了其他的目的，SIP允许创建基础的network hosts（叫做代理服务器），并且允许终端用户注册上去，发出会话邀请，或者发出其他请求。
SIP是一个轻形的，多用途的工具，可以用来创建，修改和终止会话，它独立运作于通讯协议之下，并且不依赖建立的会话类型。
2、SIP协议功能概况SIP是一个应用层的控制协议，可以用来建立、修改、和终止多媒体会话（或者会议）例如Internet 电话。
SIP也可以邀请参与者参加已经存在的会话，比如多方会议。
媒体可以在一个已经存在的会话中方便的增加（或者删除）。
SIP显示的支持名字映射和重定向服务，这个用于支持个人移动业务－用户可以使用一个唯一的外部标志而不用关系他们的实际网络地点。
SIP在建立和维持终止多媒体会话协议上，支持5个方面：用户定位：检查终端用户的位置，用于通讯。
用户有效性：检查用户参与会话的意愿程度。
用户能力：检查媒体和媒体的参数。
建立会话：”ringing”,建立会话参数在呼叫方和被叫方。
会话管理：包括发送和终止会话，修改会话参数，激活服务等等。
SIP不是一个垂直集成的通讯系统。
SIP可能叫做是一个部件更合适，它可以用作其他IETF协议的一个部分，用来构造完整的多媒体架构。
比如，这些架构将会包含实时数据传输协议（RTP）（RFC 1889）用来传输实时的数据并且提供QoS反馈，实时流协议（RSTP）(RFC 2326)用于控制流媒体的的传输，媒体网关控制协议（MEGACO）(RFC 3015)用来控制到公共电话交换网（PSTN）的网关，还有会话描述协议（SDP）（RFC 2327）用于描述多媒体会话。
SIP协议介绍(RFC3261)
》由代理服务器并行分发的请求，其Cseq值相同。
20
主要头部字段
Via 》请求消息经过的路径，用于响应的发送。响应和请求必须走相同的路
径。Branch参数用于识别事务。
Max_Forward 》请求的最大转发次数 Contact 》后续请求发送的目的地 Record_Route 》用于标识prxoy，指定后续消息必须经过该proxy Route
17
SIP消息的格式
SIP 消 息＝ 起 始 行 *消 息 头 部（1 个 或 多 个 头 部） CRLF ( 空 行 ) 〖 消息体〗
18
SIP消息格式
请求的起始行 Request-Line = Method SP Request-URI SP SIP-Version CRLF 响应的起始行 Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
协收到的协求消息协行协和协理后协协协其他的服协用于存放sip协重定向服协器或proxy提供用协一或者11sip接收sip协求把协求中的原地址映射协零个重定向服协器不协起自己的呼叫不协送协3xx协协行重定向12sipsipproxyserverredirectserverregisterserverserver可共存于一协协也可以分布在不同的物理协sip服协器完全是协协件协协可以根据需要proxyserverredirectserver角色不是固定不协的一个ua叫中可以是uac也可以是uasserver是一个sip协公共协源协信息咨协所采用的协协不是sip而是其lightdirectoryaccessprotoco呼叫和媒控制信息同协协送15sip协送和接收sip消息匹配事协状proxy外每个sip16sip2xx成功3xx重定向6xx全局协协ack用于invite的register注册17sipsip事协包括一协求和其中协包括invite事协协包括invite协求的2xxsipsip协求的起始行requestlinemethodsprequesturispsipversioncrlfsipversionspstatuscodespreasonphrasecrlf20协求的协协接收者totagfromtagcallid特定邀协或注的唯一协协cseq相同的callid协但不同协求方法协部或消息cseq序号invite协求相同bye协求的cseq协协大于invitecseq协相同
VoIP技术协议之SIP协议
VoIP技术协议之SIP协议协议名称：VoIP技术协议之SIP协议1. 引言本协议旨在规范VoIP（Voice over Internet Protocol，互联网语音通信协议）技术中的SIP（Session Initiation Protocol，会话初始协议）的使用。
SIP是一种应用层协议，用于建立、修改和终止多媒体味话，如语音通话、视频通话和即时消息等。
2. 范围本协议适合于使用SIP协议进行通信的VoIP系统、设备和应用程序。
3. 定义在本协议中，以下术语的定义如下：3.1. SIP User Agent（SIP UA）：SIP协议的终端设备或者应用程序，用于发起或者接收SIP会话。
3.2. SIP Proxy Server：SIP协议的服务器，用于转发SIP请求和响应。
3.3. SIP Registrar Server：SIP协议的服务器，用于注册SIP UA的位置信息。
3.4. SIP Redirect Server：SIP协议的服务器，用于重定向SIP请求到正确的位置。
3.5. SIP Session：使用SIP协议建立的会话，可以包括语音、视频、即时消息等多媒体数据。
4. 协议要求4.1. SIP消息格式4.1.1. SIP请求消息格式应包括请求行、消息头和消息体。
请求行由请求方法、URI（Uniform Resource Identifier）和SIP协议版本组成。
4.1.2. SIP响应消息格式应包括状态行、消息头和消息体。
状态行由SIP协议版本、状态码和原因短语组成。
4.1.3. 消息头应包括必要的字段，如From、To、Call-ID、CSeq等，以及可选的字段，如Via、Contact、Content-Type等。
4.1.4. 消息体可以包含多媒体数据，如SDP（Session Description Protocol）描述会话参数。
4.2. SIP会话建立4.2.1. SIP UA应能够通过SIP REGISTER消息将自身的位置信息注册到SIP Registrar Server。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1.SIP1.1.1.SIP格式每条SIP消息由以下三部分组成：（1）起始行（Start Line）：每个SIP消息由起始行开始。
起始行传达消息类型（在请求中是方法类型，在响应中是响应代码）与协议版本。
起始行可以是一请求行（请求）或状态行（响应）。
（2）SIP头：用来传递消息属性和修改消息意义。
它们在语法和语义上与HTTP头域相同（实际上有些头就是借自HTTP），并且总是保持格式：<名字>:<值>。
（3）消息体：用于描述被初始的会话（例如，在多媒体会话中包括音频和视频编码类型，采样率等）。
消息体能够显示在请求与响应中。
SIP清晰区别了在SIP起始行和头中传递的信令信息与在SIP 范围之外的会话描述信息。
可能的体类型就包括本文将要描述的SDP会话描述协议。
1.1.2.消息头Header field where proxy ACK BYE CAN INV OPT REG Accept R - o - o m* o Accept 2xx - - - o m* o Accept 415 - c - c c c Accept-Encoding R - o - o o o Accept-Encoding 2xx - - - o m* o Accept-Encoding 415 - c - c c c Accept-Language R - o - o o o“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节）-:这个头域是不适用的。
1.1.3.请求格式1.1.4.响应格式1.2.字段Request-URI :呼叫请求发送地址。
UA生成初始请求消息时，该域中的信息一般与TO中的地址相同，经过网络服务器后，由于实际路由问题，该值可能发生变化以，另外一个比较特殊的是REGISTER消息，在REGISTER消息中，在REQUEST-URI中将会填充注册服务器的地址（表示消息发往注册服务器），而此时TO域中的地址将会填充客户端实际的地址。
From 发起请求方的地址。
一般采用USERINFO@HOSTPORT形式。
该域同时带有一个TAG参数，是随机产生的整数。
To接受方地址。
同FROM域相同，也采用USERINFO@HOSTPORT的地址形式，当该域存在于最终响应消息中时，将会事有TAG参数。
Call－ID用于识别呼叫参数，在同一个DIALOG中，该参数不发生变化。
该参数与FROM 中的TAG参数、TO域中的TAG参数相结合用以保证呼叫的惟一性。
Cseq表征TRANSACEION的参数，由于同一个呼叫中会存在多个TRANSACTION,因此通过该能数来保证同一个USERAGENT发送的不同请求消息间的顺序。
Via该参数表征呼叫经过的路径，UA生成SIP消息时，会在该域中填写自己的地址：PROXY在转发请求消息时，将会增加一个填有自己地址的VIA域，表示才叫经过本PROXY。
VIA域的存在可以保证响应消息按照原路径返回到主叫方.代理服务器用它检查其内容，如果新端点已出现在via列表中，则表示有环路了。
Contact告知对端自己的地址。
当对端发送下一个请求消息时，可直接向该地址发送，不需要关心前一个路由信息（除非有特定原则，例如PROXY可以通过RECORD-ROUTE域来保证下一个请求消息必须经过本PROXY,即使CONTACT域中填写对端客户的地址。
Expires limits search time,给出消息内容超期的时间Record-Route 由于CONTACT域的存在使得两个用户后续的请求消息可能不经过PROXY,为了运营需要，PROXY在初始INVITE消息中增加了RECORD-ROUTE域，这样可以保证后续请求（例如BYE消息）经过PROXY.通过RECORD-ROUTE与CONTACT的结合，既可避免后续请求旁路网络服务器的行为，又可减少后续请求路径上的环节。
CONTENT-TYPE表征消息格式的参数，例如，呼叫采用了SDP进行会话描述，还是采用其他类型的会话描述协议。
Examples of SIP URIssip:*********************sip:*********************;transport=sip:******************.ch:5678sip:**********.200.27:3456sip:+41-76-456-9786@sipgate.sip:*****************.ch;user=sip:zhwin.ch;method=REGISTERDefaults:5060 (destination port)transport=udp (transport parameter)user=ip (user parameter)method=INVITE (SIP method)1.2.1.Via格式Via = ( "Via" | "v") ":" 1#( sent-protocol sent-by *( ";" via-params ) [ comment ] )via-params = via-hidden | via-ttl | via-maddr| via-received | via-branch | via-extensionvia-hidden = "hidden"via-ttl = "ttl" "=" ttlvia-maddr = "maddr" "=" maddrvia-received = "received" "=" hostvia-branch = "branch" "=" tokenvia-extension = generic-paramVia 处理流程received/rport处理001 INVITEsip:*******************.66.222SIP/2.0002 Via: SIP/2.0/UDP 211.123.66.223:5060;branch=a71b6d57-507c77f2003 Via: SIP/2.0/UDP 10.0.0.1:5060;received=202.123.211.25;rport=12345004 From:<sip:******************.66.223>;tag=108bcd14005 To:sip:*******************.66.222006 Contact:sip:***************.0.1007 Call-ID:*****************************************.19.6008 CSeq: 703141 INVITE009 Content-Length: 138010 Content-Type: application/sdp011 User-Agent: HearMe SoftPHONE012…………In the above trace, the IP address in line 003 of the SIP header is the IP address that the client thinks it is – i.e. the internal IP address (10.0.0.1). But the proxy knows from which IP address it actually received the packet, so it adds the “received” and “rport”tags with the IP address and port after the NAT mapping. These tags allow the proxy to forward SIP messages back to the client via the NAT.Branch处理used to distinguish between multiple responses to the same request.Forking Proxy: Issue a single request to multiple destinations.1.2.2.Route/Record-Route•Record-Route can be used:–ensures Firewall proxy stays in path• A Firewall proxy adds Record-Route header–Clients and Servers copy Record-Route and put in Route header for all messagesRequest routing例Only Proxy 3 remains in route1. UA1 is instructed to INVITE “sip:UA2@proxy1”2. The message should be sent to Proxy 13. The message should be sent to Proxy 24. The message should be sent to Proxy 35. The message should be sent to UA2.6. UA2 sends a “200 OK”, which should be sent back to UA1, through all three proxies.7. UA1 sends an ACK to Proxy 3.8. Proxy 3 sends the ACK to UA2.9. UA2 sends a BYE to proxy 3.10. Proxy 3 sends the BYE to UA1.11. UA1 sends a 200 OK through proxy 3 to UA2.1.2.3.ExpiresThe RFC is referring to a REGISTER request that includes an expires parameter on the Contact and one is a separate header field like this:Contact:<sip:***************>;expires=1000Contact:<sip:***************>Expires: 2000for the above, the foo contact should expire after 1000 seconds, and the bar contact after 2000 seconds.The test used the Contact header:Contact:<sip:*************************.com;Expires=1800>;EXPIRES=2970which means something else entirely. The ';expires=1800' inside the angle brackets is a part of the URI, not a field parameter of the Contact field. The ';expires=2970' outside is the field parameter, so it is correct to use it as the expiration time of the contact.The inner one is used by the proxy to control forking timeouts when this Contact is used, and has nothing to do with the registration expiration.Broad Band。