SIP协议及其安全机制的研究与实现_第二章SIP协议分析_15_25
第二章SIP协议分析
第二章 SIP协议分析[1]
2.1 SIP消息
SIP是一种基于文本的协议，SIP消息使用UTF-8编码[8]。SIP消息分为请求消息和响应消息两种，请求消息由客户机发送到服务器，响应消息由服务器返回给客户机。所有的请求和响应消息都遵循由RFC2822所规定的基本格式[9]，由一个起始行（start-line）、若干个消息头域（message-header）、一个空白行（empty-line）、可选的消息体（message-body）几个部分构成，消息中的每一行均以换行和回车字符（CRLF）作为结尾。对于请求消息，起始行为请求行（Request-Line），而对于响应消息，起始行为状态行（Status-Line）。SIP消息可以表示如下：
generic-message = start-line
*message-header
CRLF
[message-body]
start-line = Request-Line / Status-Line
2.1.1 请求消息
SIP请求消息的请求行由一个方法名（Method）、一个请求URI（Request-URI）和一个协议版本（SIP-Version）组成，三个部分之间以空格字符（SP）间隔。请求消息的格式可以表示如下：Request-Line = Method SP Request-URI SP SIP-Version CRLF
z Method：决定请求消息的类型与目的，在RFC3261中规定了六种方法，方法的名称与意义如表2-1所示。这六种方法完成了SIP协议的基本功能，其中，INVITE、ACK和BYE三种方法可以构成一次基本的会话建立直至终止的过程。除此之外，在其它的SIP相关RFC中还定义了REFER、SUBSCRIBE、NOTIFY、MESSAGE、UPDATE、INFO和PRACK七种方法[4]，用于即时消息等附加功能。
名称意义
REGISTER 向注册服务器登记实际地址信息，提供地址映射
INVITE 邀请某个用户加入媒体会话
ACK 确认对于一个INVITE消息的最终响应
BYE 终止一条已经存在的媒体会话
CANCEL 取消一个尚未完成的请求
OPTIONS 查询服务器的当前状态及其所支持的媒体功能
表2-1 SIP Methods
z Request-URI：表明了请求消息的目的地址。SIP协议使用一种类似于Email地址的统一资源标识符（Uniform Resource Identifier, URI）地址格式[10]，称为SIP URI。SIP URI通常采用“sip:user@host”的形式，例如“sip:bob@https://www.wendangku.net/doc/a413532028.html,”，其中“bob”是用户名，“https://www.wendangku.net/doc/a413532028.html,”是为该用户提供SIP服务的域，此外SIP协议还提供一种安全URI方案，称为SIPS URI，例如“sips:bob@https://www.wendangku.net/doc/a413532028.html,”。通常，请求消息中的Request-URI是一种SIP URI或SIPS URI，但SIP协议也支持一些其它类型的Request-URI方案，如“tel” URI方案、“im” URI方案等。
z SIP-Verison表示请求消息或响应消息使用的SIP协议版本号，SIP协议当前的版本号是2.0，
东南大学硕士学位论文
所有的请求与响应消息都必须将SIP-Verison设置为“SIP/2.0”。
2.1.2 响应消息
SIP响应消息的状态行由一个协议版本（SIP-Version），一个状态码（Status-Code）和一个原因说明（Reason-Phrase）组成，类似于请求消息，三个部分之间也以空格字符（SP）间隔。响应消息的格式可以表示如下：
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
状态码是一个100～699之间的3位正整数，它表示对于一个请求消息的响应结果。原因说明是一串可以显示的字符，用于对响应的状态码进行简短说明。
状态码的第一位决定了响应消息的类型，状态码在100～199之间的响应消息归类为“1xx response”，状态码在200～299之间的响应消息归类位“2xx response”，以此类推，响应消息被分为六种类型，如表2-2所示，其中1xx响应通知客户机请求消息正在接受处理，还会有后继的响应消息被服务器返回，因此被称为临时响应，其它的五种响应均表示与这个请求相关的处理已经完毕，被称为最终响应。
类型描述状态码表示的意义
1xx 临时响应
（Provisional）之前的请求消息已经收到，并准备接着处理后面的请求消息。
2xx 成功响应
（Success）
操作成功，请求消息已被收到并且成功地处理。
3xx 重定向响应
（Redirection）服务器向客户端返回其它可能的位置，客户端应当根据响应中包含的地址信息向另一个服务器重发请求消息。
4xx 客户端错误
（Client Error）请求由于客户端的错误而失败，客户端可以根据响应状态码修改并重发刚才的请求消息。
5xx 服务器错误
（Server Error）请求由于服务器的错误而失败，客户端可以向另一个服务器重发请求消息。
6xx 全局错误
（Global Failure）请求失败，客户端不应该再向任何服务器重发该请求消息。
表2-2 SIP响应消息分类
2.1.3 消息头域
SIP消息的头域大部分与HTTP消息的头域相同，其格式符合RFC2822的规定，可以表示成“field-name: field-value”的形式。其中，field-name是消息头域的名称，field-value是消息头域所携带的信息。有些消息头域既可以用于请求消息，也可以用于响应消息；而有些消息头域只能用于请求消息或响应消息的一种。在一个合法的SIP请求消息中必须包含六种头域：From、To、Call-ID、CSeq、Max-Forwards和Via，在这六种头域中包含了构成一条SIP请求消息所需要最基本的信息。
对几种重要的消息头域说明如下：
1)From：表示请求消息发起方的逻辑地址，它的一般格式为：
display-name
其中，“display-name”是一个可选的用户名，用来在用户界面上显示；所有的From头域都必须包含一个“tag”参数，它由会话发起方在请求消息中插入，是一个由会话发起方生成的全局唯一的标识，From头域和To头域中的两个“tag”参数，与Call-ID头域一起唯一地标识一条SIP对话。
From头域示例如下：
From: "Bob"
第二章SIP协议分析
2)To：指定请求消息目的接收者的逻辑地址，它与From头域的格式类似。To头域的“tag”参数由
请求消息的目的接收者在响应消息中插入。
To头域示例如下：
To: Carol
To: sip:babage@https://www.wendangku.net/doc/a413532028.html,;tag=2443a8f7
3)Call-ID：唯一标识某次邀请过程或者某个客户机的所有注册。Call-ID通常由一个随机的逻辑标
识、一个“@”字符、一个域名或IP地址组成，由于会话的发起方在自己的域上具有唯一的逻辑标识，逻辑标识和域名共同组成的Call-ID是全局唯一的。
Call-ID头域示例如下：
Call-ID: 34a5d553192cc35@15.34.3.1
4)CSeq：用于对SIP事务进行标识和排序，区分新的请求消息与重传的请求消息，它包含一个序列
数和一个方法名，方法名必须与请求消息的方法名相同。
CSeq头域示例如下：
CSeq: 4711 INVITE
5)Max-Forwards：用于限制一个请求消息在到达目的地之前所经过的跳数，每经过一跳，值减1，
当值减到0时，请求被拒绝。
Max-Forwards头域示例如下：
Max-Forwards: 70
6)Via：记录请求消息所经过的路径，并且指定响应消息的路由，防止在消息传递过程中产生回路。
Via头域中必须包含一个branch ID，用来对由该请求消息创建的SIP事务进行标识。
Via头域示例如下：
Via: SIP/2.0/UDP 100.101.102.103 ;branch=z9hG4bK776a
7)Contact：用来表示用户当前所在的实际地址，它由一个显示名、一个URI和几个参数组成。在
一次呼叫过程中，Contact头域中保存的用户地址被暂存下来，用来向该用户直接发送请求消息，例如：对于一条INVITE消息的200 OK响应中包含一个Contact头域，该头域中的URI指出了被叫用户当前所在的实际地址，之后由主叫方向被叫方发送的ACK消息和其它的任何请求消息都直接发往这个地址，而不经过网络中的代理服务器。在一次注册过程中，Contact头域被包含在REGISTER请求消息和200 OK响应消息中，用来建立用户逻辑地址到实际地址的绑定，其中的“expire”参数指出该绑定的有效期。
Contact头域示例如下：
Contact: sip:bob@https://www.wendangku.net/doc/a413532028.html,
Contact: Bob
2.1.4 消息体
SIP消息可能会带有消息体，消息体可以包含多种类型的信息，最常见的是SDP信息，用于承载用SDP协议描述的媒体参数。一些消息头域用来对消息体进行说明，如：Content-Type头域说明了消息体的类型，Content-Length头域指定消息体的长度，Content-Encoding表示消息体的编码方式。
2.2 SIP网络元素
SIP网络中包含两种元素：SIP用户代理（User Agent, UA）和SIP网络服务器，如图2-1所示。UA 是SIP网络中的终端系统和用户接口；SIP网络服务器向UA提供服务，用于用户注册和消息路由，根据功能上的不同分为3类：代理服务器（Proxy Server）、重定向服务器（Redirect Server）和注册服务器（Registrar），这三种服务器都需要访问一个位置服务（Location Service），来查询或修改一些用户
东南大学硕士学位论文
的地址信息。图2-1中的实线部分，即UA和各种SIP网络服务器之间的交互均采用SIP协议；虚线部分，即SIP网络服务器对位置服务的访问不属于SIP网络的范畴，一般不使用SIP协议，常用的有轻量目录访问协议(Lightweight Directory Access Protocol, L DAP)[11]等。
图2-1 SIP网络示意图
2.2.1 用户代理
UA是一个支持SIP协议的网络终端，用户通过UA建立媒体会话，使用多媒体服务。根据UA在会话中扮演角色的不同，又分为用户代理客户机（user agent client, UAC）和用户代理服务器(user agent server, UAS)，它们之间的关系如图2-2所示。UAC是一个客户机应用，根据外部激励（如用户按键、
电话线上的信号等）发出请求消息，并处理响应消息；UAS是一个服务器应用，它接收并处理UAC
发起的请求消息，并根据处理结果向UAC返回响应消息。通常一个UA同时具有UAC和UAS两种功能。
图2-2 UAC与UAS
2.2.2 代理服务器
代理服务器构成SIP网络结构的骨干，它负责将请求消息路由到UAS，将响应消息路由到UAC。
在转发请求消息时，代理服务器通常通过位置服务来确定下一跳的地址。位置服务作为一个全局数据库，作用类似于DNS服务器，根据用户的逻辑地址查询并返回实际的位置信息。
从运行机制上，代理服务器与UA有以下三个主要的区别：
1)代理服务器不发起请求消息，它仅根据收到的请求消息向UA返回一定的响应；
2)代理服务器不具有媒体协商能力；
3)代理服务器仅仅根据SIP消息的头域处理消息路由，不解析消息体。
一个代理服务器可以工作在有状态和无状态两种模式下，称为有状态代理服务器和无状态代理服务器。无状态代理服务器仅仅对消息进行转发，不保存消息状态，因此效率较高；有状态代理服务器为每一个转发的请求消息记录状态信息，并使用这些信息影响以后对响应消息的处理，有状态的代理服务器是SIP域的主要管理者。
第二章SIP协议分析
代理服务器是一个逻辑角色，根据具体的应用场景，它可以扮演代理服务器的角色，对消息进行路由，也可以扮演UAS的角色，直接对请求消息给予响应，例如，对于格式错误的请求消息给予报错响应。
2.2.3 重定向服务器
重定向服务器也通过查询位置服务对UA提供消息路由的功能，但不同于代理服务器，它不利用查询到的位置信息转发任何请求消息，而是将此位置信息封装在一个3xx响应消息中返回给UAC，让UAC自行尝试下一跳的位置。
2.2.4 注册服务器
在SIP系统中，用户使用URI进行标识，通常，与Email地址一样，用于标识用户的URI是一个逻辑地址，并不能直接表示用户当前所在的实际位置，它又被称为记录地址（address of record, AOR）。因此，用户必须首先向一个服务器登记他当前所在的位置，将自己的AOR地址绑定到当前所在的实际地址上，才能被呼叫者找到，如果用户的位置发生变化，就必须向服务器重新注册新的位置。
注册服务器的作用就是完成对用户的注册，它将用户的AOR地址绑定到用户当前所在的实际地址，并将这个绑定的位置信息存储到位置服务中，例如，将一个逻辑上的AOR地址sip:bob@https://www.wendangku.net/doc/a413532028.html, 绑定到一个可以对应到IP地址的位置sip:bob@https://www.wendangku.net/doc/a413532028.html,上去。
2.3 协议层次结构
SIP协议具有分层的体系结构，协议的运行机制由四个相对独立的层次描述，从下向上分别为语法与编码层（syntax and encoding）、传输层（transport）、事务层（transaction）和事务用户层（transaction user, TU），如下图所示：
图2-3 SIP协议的层次结构
2.3.1 语法与编码层
语法与编码层是SIP协议的最底层，它规定了SIP的消息格式和编码方式，使用BNF语法[12]进行描述，所有的SIP网络元素都具有语法与编码层。
东南大学硕士学位论文
2.3.2 传输层
传输层是SIP协议的第二层，它负责SIP网络内所有请求和响应消息的发送与接收，所有的SIP网络元素都具有传输层。根据RFC3261的规定，SIP协议必须支持UDP和TCP作为传输协议。当使用面向连接的传输协议时，SIP传输层必须具备连接管理的功能，包括连接的开启、维护和撤销，以及确定当前要使用的连接等等。
2.3.3 事务层
事务层位于SIP协议的第三层，它负责管理协议运行过程中的所有事务（transaction）。除了无状态代理服务器之外的所有SIP网络元素都具有事务层。
事务，被定义为一条请求消息以及对应于该请求消息的全部响应消息，包括0个或多个临时响应和一个或多个最终响应。事务是SIP协议的基本组成部分，UA、代理服务器等各个网络元素的行为都由一系列的事务组成，通过对事务的管理，事务层处理上层的各种需求，完成请求与响应消息的匹配和重传等控制功能。
事务又分为客户机事务（client transaction）和服务器事务（server transaction）两种。客户机事务发送请求消息，接收并处理服务器事务返回的响应消息；服务器事务接收并处理客户机发送的请求消息，返回响应消息。图2-4通过UA与有状态代理服务器之间的交互表示出了客户机事务与服务器事务之间的关系，在这个例子中，UAC创建并执行一个客户机事务，将请求消息发送给代理服务器，代理服务器在收到请求消息之后为它创建一个服务器事务，接着，代理服务器又创建一个客户机事务将请求消息转发给UAS，UAS收到请求消息后创建一个服务器事务，对请求消息进行处理并返回响应消息。
图2-4 客户机事务与服务器事务
根据发起事务的请求消息的不同，事务又分为INVITE事务和非INVITE事务，当请求消息为
INVITE消息时，事务被称为INVITE事务，否则事务被称为非INVITE事务，相应的，客户机事务被
分为INVITE Client Transaction（ICT）和Non-INVITE Client Transaction（NICT），而服务器事务被分为INVITE Server Transaction（IST）和Non-INVITE Server Transaction（NIST）。INVITE事务是一
个三步握手过程：
1)客户机事务发送INVITE消息；
2)服务器事务返回响应消息；
3)客户机事务发送ACK消息。
非INVITE事务不使用ACK消息，它仅仅是一次简单的请求～响应过程。
事务的功能是通过对事务状态机的维护来实现的，ICT、NICT、IST、NIST四种事务分别对应于四种不同类型的事务状态机。
第二章SIP协议分析
2.3.4 事务用户层
事务用户层是SIP协议的最顶层，顾名思义，事务用户是事务层的“使用者”，它利用一系列事务来完成SIP网络元素的各种行为。除了无状态代理服务器之外，每一种SIP网络元素都可以被当作一个事务用户。当一个事务用户要发送请求消息时，它创建一个客户机事务，并将该请求消息和目的IP地址、端口、传输方式传递给这个客户机事务；当收到一条请求消息时，事务用户创建一个服务器事务，对请求消息进行处理，并将响应消息传递给这个服务器事务；事务用户还可以通过发送CANCEL消息撤销一个已经创建的事务。
除了无状态代理服务器之外，SIP协议的各个网络元素都具有相同的语法与编码层、传输层和事务层，它们之间的区别就在于由事务用户层所定义的不同的行为方式，又称为核心（core）。对于UA，UA Core定义了UAC和UAS的各种操作，包括发起请求，处理请求和返回响应；对于代理服务器，Proxy Core定义了对于请求和响应消息的路由机制；对于注册服务器，Registrar Core定义了对于REGISTER消息的处理，用户注册和位置服务的维护等。
对于UA Core，存在两个重要的概念——对话（dialog）和呼叫（call），对它们解释如下：
z对话
对话代表两个UA之间的一种端对端的关系，它是一个对UA之间传递的消息进行解释的“上下文”，保存若干状态信息以辅助消息的排序和路由。UA使用对话标识（dialog ID）来唯一标识一条对话，对话标识由一个Call-ID、一个本地标识和一个远程标识组成，其中，Call-ID的值总是与消息中的Call-ID头域相同；对于UAC，本地标识被设置为消息中From头域的“tag”参数，远程标识被设置为消息中To头域的“tag”参数；对于UAS，本地标识被设置为消息中To头域的“tag”参数，远程标识被设置为消息中From头域的“tag”参数，因此，对话一端UA的本地标识总是与对话另一端UA的远程标识相同。一条对话由一条INVITE请求消息及相关的2xx和101～199响应消息创建，当UAC发出一条INVITE请求并收到100～199响应后，创建一条处于“early”状态的对话，表示UAC与UAS之间建立了初始的连接，当2xx响应消息到达UAC时，对话过渡到“confirmed”状态，表示UAC与UAS已经成功建立了媒体会话。
z呼叫
呼叫是指一个用户向另一个用户发送INVITE消息，邀请他加入会话。呼叫与对话的关系可以表述如下：如果UAC在发出INVITE消息后只收到3xx、4xx、5xx或6xx响应，则没有成功建立对话，呼叫失败；由于有的Proxy可能会把请求消息同时转发到不只一个可能的位置上，UAC可能会收到多个UAS返回的1xx响应，从而建立多个“early”状态的对话；如果某个UAS首先接受了这次呼叫，则Proxy只返回该UAS的2xx响应，使UAC与该UAS之间的对话转移到“confirmed”状态，并撤销之前对于其它UAS的呼叫。综上所述，一个呼叫可能对应于0条或多条“early”状态的对话，一个成功建立的呼叫总是对应于一条“confirmed”状态的对话。
2.4 主要的操作流程[13]
2.4.1 注册
图2-5表示一次简单的注册过程，用户Alice通过本域的注册服务器向位置服务注册当前所在的实际位置。
图2-5 注册
1)用户Alice向注册服务器发送REGISTER请求消息，消息的To头域和From头域中均包含用户
Alice的AOR地址：sip:alice@https://www.wendangku.net/doc/a413532028.html,，消息的Contact头域包含了Alice当前所在的实际位置，即Alice正在使用的UA的地址：sip:alice@https://www.wendangku.net/doc/a413532028.html,；
2)注册服务器从REGISTER消息中提取出Alice的AOR地址与实际地址，建立地址绑定，并将该
地址绑定保存到位置服务的数据库中；
3)注册服务器向Alice的UA返回200 OK响应，在响应消息的Contact头域中包含Alice当前已经
注册的地址列表。
2.4.2 会话的建立与终止
图2-6表示一次媒体会话的建立与终止过程，主叫方为用户Alice，被叫方为用户Bob，会话建立的过程以一个代理服务器为中介。
图2-6 媒体会话的建立与终止（经过代理服务器）
1)用户Alice通过发送INVITE消息发起呼叫，INVITE消息的Request-URI设置为用户Bob的AOR
地址sip:bob@https://www.wendangku.net/doc/a413532028.html,，由于并不知道Bob当前的实际位置，Alice通过DNS查询获得Bob 所在域的代理服务器的IP地址，将INVITE消息发送给这个代理服务器；
2)代理服务器收到INVITE消息后查询位置服务，获得Bob的实际地址：sip:bob@202.119.22.4；
3)代理服务器在收到的INVITE消息的基础上生成一个新的INVITE消息，并转发给Bob，在新的
第二章SIP协议分析
INVITE消息中，Request-URI设置为Bob的实际地址；
4)用户Bob的UA收到INVITE消息，返回180 Ring响应给代理服务器；
5)代理服务器把180 Ring响应转发给Alice；
6)Bob接受这次呼叫，返回200 OK响应，其中包含一个Contact头域，给出Bob的实际地址；
7)代理服务器把200 OK响应转发给Alice，至此，会话双方都获得了对方的实际地址，此后的通
信不再经过代理服务器；
8)Alice收到200 OK响应后发送ACK消息给Bob进行确认；
9)Bob收到ACK消息，媒体会话成功建立；
10)Bob发送BYE消息给Alice，请求终止会话；
11)Alice收到BYE消息后向Bob返回200 OK响应，会话断开。
在上述过程中，代理服务器也可以选择始终驻留在会话的路径之中，方法是在转发INVITE消息时插入一个包含自身地址的Record-Route头域，这样一来，之后的ACK和BYE消息仍然需要经过代理服务器的转发。
如果用户Alice与用户Bob通过重定向服务器建立媒体会话，则重定向服务器不转发INVITE 消息，而是在查询到Bob的实际地址之后，将它包含在3xx响应的Contact头域中返回给Alice，Alice 通过这种方式就得到了Bob的实际地址，此后的消息交互直接在Alice与Bob之间进行，如下图所示：
图2-7 通过重定向服务器建立媒体会话
2.4.3 呼叫撤销
图2-8表示一次呼叫撤销的过程，用户Alice向用户Bob发起呼叫，但是在Bob接受邀请（返
回200 OK响应）之前放弃了这次呼叫。
东南大学硕士学位论文
图2-8 呼叫撤销
1) 在收到180 Ringing 响应之后，Alice 决定放弃这次呼叫，于是发送CANCEL 消息。CANCEL
消息必须与之前的INVITE 消息“匹配”，即具有相同的Request-URI ，Call-ID 和To 头域，CSeq
头域中的数值也和INVITE 消息中的相等。CANCEL 消息沿着之前的路径发送给代理服务器；
2) 代理服务器收到CANCEL 消息后向Alice 返回200 OK 响应；
3) 代理服务器将CANCEL 消息转发给Bob ；
4) Bob 在收到CANCEL 消息后返回200 OK 响应给代理服务器；
5) Bob 返回487 Request Terminated 响应；
6) 代理服务器收到487 Request Terminated 响应后向Bob 发送ACK 消息进行确认；
7) 代理服务器把487 Request Terminated 响应转发给Alice ；
8) Alice 收到487 Request Terminated 响应后向代理服务器发送ACK 消息进行确认。
从上述过程可以看出，CANCEL 消息总是用200 OK 响应逐跳确认，而非端到端的确认，这是由于CANCEL 消息中总是只含有一个Via 头域，其中包含的地址与被撤销的INVITE 消息中最顶部的一个Via 头域相同。
在图2-8中，如果CANCEL 消息被Bob 收到之前，Bob 已经返回了200 OK 响应，Alice 将发送ACK 消息对响应进行确认，然后再向Bob 发送BYE 消息终止呼叫。
2.5 本章小结
本章介绍了SIP 消息的格式与分类，对SIP 网络中几个关键元素的特点、作用和区别进行了细致地说明，然后从协议分层的角度对SIP 协议的层次结构进行分析，最后结合实例给出了SIP 系统中几个主要的操作流程。
通过上面的研究，理清了SIP 协议的结构，熟悉了协议中的各个操作流程和基本特性，为后面SIP 协议栈软件的设计与实现打下了坚实的基础。
第三章SIP网络安全机制的研究
第三章 SIP网络安全机制的研究
3.1 攻击与威胁
SIP系统往往运行在公共因特网等开放的环境里，在这样的网络环境中，攻击者可以方便地读取网络中的任何数据包，因此SIP系统面临着诸多的安全威胁，攻击者可能修改SIP消息，窃取服务，窃听SIP网络元素之间的通信，干扰终端媒体会话等等。普遍存在于大多数SIP部署中的攻击手段与安全威胁主要有注册劫持、假冒服务器、篡改消息体、中断会话和拒绝服务攻击五种[1]。
3.1.1 注册劫持
注册劫持是指攻击者冒充合法用户使用SIP注册机制，对合法用户的注册信息进行恶意修改或删除。SIP注册机制允许用户向注册服务器登记自己当前所在的位置，注册服务器总是使用REGISTER 消息的From头域进行判断，决定是否可以修改某个用户的地址绑定。UA的所有者可以任意地改变SIP 请求消息中的From头域，这就使恶意注册成为可能。如果攻击者也向注册服务器发送REGISTER消息，并在消息的From头域中插入合法用户的AOR地址，就可以向注册服务器冒充合法用户，通过对消息的Contact头域进行一定的设置来恶意修改合法用户的注册信息。
图3-1是一个注册劫持的例子，攻击者Carol冒充合法用户Alice向Alice所在域的注册服务器发送REGISTER消息，将消息的From头域设置成Alice的AOR地址，而将消息的Contact头域设置成自己的实际地址，注册服务器将伪造的地址绑定写入了位置服务中。这样一来，当用户Bob试图与Alice进行通信时，Alice所在域的代理服务器向位置服务进行查询后得到的却是Carol的位置，从而将本应转发给Alice的消息转发给了Carol。
图3-1 注册劫持
注册劫持攻击奏效的原因是注册服务器对UA缺乏认证措施，它说明任何一种提供有价值服务的服务器，包括代理服务器、注册服务器和UAS，都需要对它收到的请求消息进行认证以控制请求发起者所能够访问的资源。
SIP协议呼叫流程及协议分析
一、SIP协议介绍： 会话发起协议SIP（Session Initiation Protocol）是一个应用层控制信令协议，用于建立、更改和终止多媒体会话或呼叫。SIP作为一个基础，可以在其上提供很多不同的服务。目前已经定义的媒体类型有音频、视频、应用、数据、控制。 二、SIP呼叫流程： 注册流程： （1）用户首次试呼时，终端代理A 向代理服务器发送REGISTER 注册请求； （2）代理服务器通过后端认证/计费中心获知用户信息不在数据库中，便向终端代理回送401Unauthorized 质询信息，其中包含安全认证所需的令牌； （3）终端代理提示用户输入其标识和密码后，根据安全认证令牌将其加密后，再次用REGISTER 消息报告给代理服务器； （4）代理服务器将REGISTER 消息中的用户信息解密，通过认证/计费中心验证其合法后，将该用户信息登记到数据库中，并向终端代理A 返回成功响应消息200 OK。 呼叫流程：
（1）用户摘机发起一路呼叫，终端代理A 向该区域的代理服务器发起Invite 请求；（2）代理服务器通过认证/计费中心确认用户认证已通过后，检查请求消息中的Via 头域中是否已包含其地址。若已包含，说明发生环回，返回指示错误的应答；如果没有问题，代理服务器在请求消息的Via 头域插入自身地址，并向Invite 消息的To 域所指示的被叫终端代理B 转送Invite 请求； （3）代理服务器向终端代理A 送呼叫处理中的应答消息，100 Trying； （4）终端代理B 向代理服务器送呼叫处理中的应答消息，100 Trying; （5）终端代理B 指示被叫用户振铃，用户振铃后，向代理服务器发送180 Ringing 振铃信息； （6）代理服务器向终端代理A 转发被叫用户振铃信息； （7）被叫用户摘机，终端代理B 向代理服务器返回表示连接成功的应答（200 OK）；（8）代理服务器向终端代理A 转发该成功指示（200 OK）； （9）终端代理A 收到消息后，向代理服务器发ACK 消息进行确认； （10）代理服务器将ACK 确认消息转发给终端代理B； （11）主被叫用户之间建立通信连接，开始通话； 结束流程：
sip协议原理分析及总结
SIP协议学习总结 1、SIP协议定义 SIP（Session Initiation Protocol，即初始会话协议）是IETF提出的基于文本编码的IP电话/多媒体会议协议。用于建立、修改并终止多媒体会话。SIP 协议可用于发起会话，也可以用于邀请成员加入已经用其它方式建立的会话。多媒体会话可以是点到点的话音通信或视频通信，也可以是多点参与的话音或视频会议等。SIP协议透明地支持名字映射和重定向服务，便于实现ISDN，智能网以及个人移动业务。SIP协议可以用多点控制单元（MCU）或全互连的方式代替组播发起多方呼叫。与PSTN相连的IP电话网关也可以用SIP协议来建立普通电话用户之间的呼叫。 SIP协议在IETF多媒体数据及控制体系协议栈结构的位置 H.323SIP RTSP RSVP RTCP H.263 etc. RTP TCP UDP IP PPP Sonet AAL3/4AAL5 ATM Ethernet PPP V.34 SIP协议支持多媒体通信的五个方面： ◆用户定位：确定用于通信的终端系统； ◆用户能力：确定通信媒体和媒体的使用参数； ◆用户有效性：确定被叫加入通信的意愿； ◆会话建立：建立主叫和被叫的呼叫参数； ◆会话管理：包括呼叫转移和呼叫终止； SIP协议的结构 SIP是一个分层的协议，也就是说SIP协议由一组相当无关的处理层次组成，这些层次之间只有松散的关系。 SIP最底层的是它的语法和编码层。编码方式是采用扩展的Backus-Naur Form grammar (BNF范式)。 第二层是传输层。它定义了一个客户端发送请求和接收应答的方式，以及一 个服务器接收请求和发送应答的方式。所有的SIP要素都包含一个通讯层。 第三层是事务层。事务是SIP的基本组成部分。一个事务是UAC向UAS发送的一个请求以及UAS向UAC发送的一系列应答。事务层处理应用服务层的重发，匹配请求的应答，以及应用服务层的超时。任何一个用户代理客户端完成的事情都是
SIP协议相关文件
Osip2是一个开放源代码的sip协议栈，是开源代码中不多使用C语言写的协议栈之一，它具有短小简洁的特点，专注于sip底层解析使得它的效率比较高。 eXosip是Osip2的一个扩展协议集，它部分封装了Osip2协议栈，使得它更容易被使用。 一、介绍 Osip2是一个开放源代码的sip协议栈，是开源代码中不多使用C语言写的协议栈之一，它具有短小简洁的特点，专注于sip底层解析使得它的效率比较高。但缺点也专门明显，首先确实是可用性差，没有专门好的api封装，使得上层应用在调用协议栈时专门破裂；其次，只做到了transaction层次的协议过程解析，
缺少call、session、dialog等过程的解析，这也增加了使用的难度；再次，缺少线程并发处理的机制，使得它的处理能力有限。 eXosip是Osip2的一个扩展协议集，它部分封装了Osip2协议栈，使得它更容易被使用。eXosip增加了call、dialog、registration、subscription等过程的解析，使得有用性更强。然而eXosip局限于UA的实现，使得它用于registrar、sip server等应用时极其不容易。另外，它并没有增加线程并发处理的机制。而且只实现了音频支持，缺少对视频和其它数据格式的支持。 综合来讲，Osip2加上eXosip协议栈仍然是个实现Sip协议不错的选择。因此需要依照不同的需求来增加更多的内容。 二、Osip2协议栈的组成 Osip2协议栈大致能够分为三部分：sip协议的语法分析、sip 协议的过程分析和协议栈框架。 1、Sip协议的语法分析：
要紧是osipparser2部分，目前支持RFC3261和RFC3265定义的sip协议消息，包括INVITE、ACK、OPTIONS、CANCEL、BYE、SUBSCRIBE、NOTIFY、MESSAGE、REFER和INFO。不支持RFC3262定义的PRACK。 遵循RFC3264关于SDP的offer/answer模式。带有SDP的语法分析。 支持MD5加解密算法。支持Authorization、www_authenticate 和proxy_authenticate。 2、Sip协议的过程分析： 要紧是osip2部分，基于RFC3261、RFC3264和RFC3265的sip 协议描述过程，围绕transaction这一层来实现sip的解析。 Transaction是指一个发送方和接收方的交互过程，由请求和应答组成。请求分为Invite类型和Non-Invite类型。应答分为响应型的应答和确认型的应答。响应型的应答是指那个应答仅代表
sip协议简单解释
引言 节省费用以及想把语音和数据融合在一起的需求，促使了IP电话的蓬勃发展。 为了使IP电话为大众所接受，成为主流，甚至最终取代传统的POTS（Plain Old Telephone Service旧式电话服务），有两个条件必须满足： 第一，话音通信的质量至少要达到POTS同样的水准； 第二，必须有信令的支持，就像PSTN（Pubic Switched Telephone Networks）公用交换电话网）中有No.7信令一样。 目前，IP电话系统有H.323和SIP两个完整和独立的信令标准，它们都对IP电话系统信令提出了完整的解决方案。它们对呼叫的连接都具有建立、管理和撤销的能力，具有网络管理功能，使端点用户具有进行建立和交互QoS（Quality of Service）的能力，且容易扩充新功能，支持不同类型的互操作性。当然，这两个协议都包含关于语音编码的解压缩方面的要求，只是这部分对两个协议而言是一样的。我们主要是从信令的角度对它们进行比较分析。 2 H.323简介 H.323是ITU-T第16工作组的建议，H.323由一组协议构成，其中有负责音频与视频信号的编码、解码和包装，有负责呼叫信令收发和控制的信令，还有负责能力交换的信令。1999年７月前，多数已实现的系统是基于H.323第二版的，而在此之后，H.323第三版开始应用。 ２．１通信系统 H.323定义了４个主要部件构筑基于网络的通信系统：终端Terminals 、网关Gateways 、网守Gatekeepers 、多点控制单元（MCU）。 １终端 在基于IP的网络上是一个客户端点。它需要支持下面３项功能：支持信令和控制，即支持
SIP协议格式详解
1.SIP 1.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
Accept-Language 2xx - - - o m* o Accept-Language 415 - c - c c c Alert-Info R ar - - - o - - Alter-Info 180 ar - - - o - - Allow R - o - o o o Allow 2xx - o - m* m* o Allow r - o - o o o Allow 405 - m - m m m Authentication-Info 2xx - o - o o o Authorization R o o o o o o Call-ID c r m m m m m m Call-Info ar - - - o o o Contact R o - - m o o Contact 1xx - - - o - - Contact 2xx - - - m o o Contact 3xx d - o - o o o Contact 485 - o - o o o Content-Disposition o o - o o o Content-Encoding o o - o o o Content-Language o o - o o o Content-Length ar t t t t t t Content-Type * * - * * * Cseq c r m m m m m m Date a o o o o o o Error-Info 300-699 a - o o o o o Expires - - - o - o From c r m m m m m m In-Reply-To R - - - o - - Max-Forwards R amr m m m m m m Min-Expires 423 - - - - - m MIME-Version o o - o o o Organization ar - - - o o o Priority R ar - - - o - - Proxy-Authenticate 407 ar - m - m m m Proxy-Authenticate 401 ar - o o o o o Proxy-Authorization R dr o o - o o o Proxy-Require R ar - o - o o o Record-Route R ar o o o o o o Record-Route 2xx,18x mr - o o o o - Reply-To - - - o - - Require ar - c - c c c - o o o o o Retry-After 404, 413,
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消息头和一组参数行组成，如图1-1所示。通过换行符区分命令行和每一条参数行。
图1-1 SIP 请求消息结构 注意：参数行的顺序不是固定的。对应的参数解释见错误！未找到引用源。。 消息体定义： Call-ID ：头字段是用来将消息分组的唯一性标识 From ：头字段是指示请求发起方的逻辑标识，它可能是用户的注册地址。From 头字段包含一个URI 和一个可选的显示名称 CSeq ：头字段用于标识事务并对事务进行排序。它由一个请求方法和一个序列号组成，请求方法必须与对应的请求消息类型一致 Max-Fowords ：头字段限定一个请求消息在到达目的地之前允许经过的最大跳数。它包含一个整数值，每经过一跳，这个值就被减一。如果在请求消息到达目的地之前该值变为零，那么请求将被拒绝并返回一个483（跳数过多）错误响应消息。 Via ：头字段定义SIP 事务的下层（传输层）传输协议，并标识响应消息将要被发送的位置。只有当到达下一跳所用的传输协议被选定后，才能在请求消息中加入Via 头字段值。 expires ：参数指出了该值中包含的URI 地址的有效期。这个参数的值是以秒为单位计算的。如果没有提供该参数，那么URI 地址的有效期由Expires 头字段值来确定。 消息头
SIP协议讲解
SIP协议讲解 14 关于本章 SIP协议 内容本章描述内容如下表所示。标题 14.1 概述14.2 SIP 消息类型14.3 SIP消息结构14.4 SIP-T简介本节简要介绍SIP 协议的应用以及相关概念。本节介绍SIP消息的类型。本节介绍SIP消息的结构。本节介绍SIP-T的应用。 14.5 SIP消息流程本节举例介绍SIP相关的消息流程。本章将对SIP协议做一简要介绍，包括涉及的基本概念、消息结构以及简要的消息流程。 14.1 概述 SIP（Session Initiation Protocol）是一个应用层控制协议，用于创建、更改和终止会话。这里的会话类型包括多媒体会议、Inter电话等类似的应用。SIP是实现VOIP（Voice over IP）的关键协议之一。 SIP支持别名映射、重定向服务、ISDN和智能网业务。它支持个人移动（personal mobility），即终端用户能够在任何地方、任何时间请求和获得已订购的任何电信业务。总的来说，SIP能够支持下列五种多媒体通信的信令功能。 l用户定位：确定参加通信的终端用户的位置； l用户通信能力协商：确定通信的媒体类型和参数； l用户意愿交互：确定被叫是否乐意参加某个通信；
l建立呼叫：包括向被叫“振铃”，确定主叫和被叫的呼叫参数； l呼叫处理和控制：包括呼叫重定向、呼叫转移、终止呼叫等等。 SIP可以通过MCU（Multipoint Control Unit）、单播联网方式、或组播方式创建多方会话，支持PSTN和IP电话之间的网关功能。 SIP协议对低层协议作了最少的假设，低层协议可以为SIP协议提供可靠或非可靠传输，可以为分组或字节流业务。SIP可以使用UDP协议或TCP协议作为传输层协议，首选UDP协议。 14.1.1 相关概念 呼叫 一个呼叫是由一个会议中被同一个发起者邀请加入的所有成员组成的。一个SIP呼叫由Call-ID进行标识。因此，如果一个用户是被不同的人邀请参加同一个多点会议，那么每个邀请都构成一个呼叫。点到点IP电话会话是一种最简单的会话，它映射为单一的SIP呼叫。 呼叫分支 一个呼叫分支（Call leg）由Call-ID、To、From三个参数共同决定。在同一个Call-ID中，从A到B的请求与从B到A的请求都属于同一个呼叫分支，呼叫分支也可以理解成一次呼叫中消息经过的路径。 事务
sip协议解析与实现(c和c 使用osip)11
sip协议解析与实现(c和c++使用osip)11 第八章查询能力 SIP的OPTIONS方法允许一个UA查询另外一个UA或者一个代理服务器的能力。这能让客户端探测关于它们所支持的方法、内容类型、扩展和编码等信息，而不用"呼叫(ringing)"另外一端。例如，在客户端插入了一个Require头域到INVITE 中，并列出了不确定目标UAS是否支持的能力之前，它可以先使用OPTIONS方法查询目标UAS是否要查询的选项被目标UAS在应答的Supported头域中返回。所有UA必须支持OPTIONS方法。 OPTIONS方法的目标使用Request-URI来标识，因为它可以表示不同的UA或者SIP服务器。如果OPTIONS被定位到一个代理服务器，Request-URI不由客户端设置，这类似于REGISTER请求设置Request-URI的方法。 如果服务器接收到一个Max-Forwards头域的值为0的的OPTIONS请求，它要对这个请求进行应答而不用管Request-URI. 这个行为与HTTP/1.1一致。这个行为可以被用于"追踪路由线路(traceroute)"功能，从而使用发送一系列递增的 Max-Forwards值的OPTIONS请求的方法检查消息路由过程中个别服务器的能力。
作为一般UA的行为，如果OPTIONS长时间没有应答，事务层能够返回一个超时错误。这将指出，目标是不可到达的并且查询的能力是不可以使用的。 OPTIONS请求可能由建立一个对话的一端发送，用于查询对端在后面的对话中可能会被使用到的能力。 第一节构造OPTIONS请求 OPTIONS请求使用像RFC3261第8.1.1讨论的标准的构造SIP请求的规则来构造。 OPTIONS可能会有一个Contact头域。 应该包含一个Accept头域用来指出UAC希望接收到的应答中的消息体类型。典型的，这可能被设置成用来描述UA的媒体能力的类型，比如，SDP(application/adp)。OPTIONS请求的应答被认为是有限定范围的，它被限定在原始请求的Request-URI内。只有当OPTIONS被作为建立对话的一部分发送，它保证会话中后继的请求也由应答OPTIONS的服务器所接收时，对OPTIONS请求的应答才是可用的。 OPTIONS请求的例子： OPTIONS sip:carol@https://www.wendangku.net/doc/a413532028.html, SIP/2.0 Via: SIP/2.0/UDP https://www.wendangku.net/doc/a413532028.html,;branch=z9hG4bKhjhs8ass877 Max-Forwards: 70
SIP协议扩展分析
协议分析 协议扩展分析 STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ????STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ???STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ???STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ?
SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK 与传统 Telephony 业务互通的场景 ?Encapsulation –'Transparent' Transit of ISUP Messages –SIP 与ISUP 协议不可能一一映射 –如果为了保证SP1－SP2之间业务的无缝互通，只有SP1发出的ISUP 消息能够透传到SP2–将ISUP 消息封装在SIP 消息体里–Content-Type: application/ISUP
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ?可STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK SIP GW INVITE SIP Proxy PSTN PSTN IAM SIP GW Transaction STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ???准?STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK SIP GW INVITE SIP Proxy PSTN PSTN IAM SIP GW STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ?规则CANCEL ???
SIP协议讲解
14 SIP协议关于本章
本章将对SIP协议做一简要介绍，包括涉及的基本概念、消息结构以及简要的消息流程。 14.1 概述 SIP（Session Initiation Protocol）是一个应用层控制协议，用于创建、更改和终止会话。这里的会话类型包括多媒体会议、Internet电话等类似的应用。SIP是实现VOIP（Voice over IP）的关键协议之一。 SIP支持别名映射、重定向服务、ISDN和智能网业务。它支持个人移动（personal mobility），即终端用户能够在任何地方、任何时间请求和获得已订购的任何电信业务。总的来说，SIP能够支持下列五种多媒体通信的信令功能。 l用户定位：确定参加通信的终端用户的位置； l用户通信能力协商：确定通信的媒体类型和参数； l用户意愿交互：确定被叫是否乐意参加某个通信； l建立呼叫：包括向被叫“振铃”，确定主叫和被叫的呼叫参数； l呼叫处理和控制：包括呼叫重定向、呼叫转移、终止呼叫等等。 SIP可以通过MCU（Multipoint Control Unit）、单播联网方式、或组播方式创建多方会话，支持PSTN和IP电话之间的网关功能。 SIP协议对低层协议作了最少的假设，低层协议可以为SIP协议提供可靠或非可靠传输，可以为分组或字节流业务。SIP可以使用UDP协议或TCP协议作为传输层协议，首选UDP协议。 14.1.1 相关概念 呼叫 一个呼叫是由一个会议中被同一个发起者邀请加入的所有成员组成的。一个SIP 呼叫由Call-ID进行标识。 因此，如果一个用户是被不同的人邀请参加同一个多点会议，那么每个邀请都构成一个呼叫。点到点IP电话会话是一种最简单的会话，它映射为单一的SIP呼叫。 呼叫分支 一个呼叫分支（Call leg）由Call-ID、To、From三个参数共同决定。在同一个Call-ID中，从A到B的请求与从B到A的请求都属于同一个呼叫分支，呼叫分支也可以理解成一次呼叫中消息经过的路径。 事务 事务是发生在客户端和服务器之间的，包括从客户端发给服务器的第一个请求消息直到服务器端发给客户端的最终响应消息，这期间的所有的消息。 事务是由一个呼叫分支中的CSeq顺序号来标识的。但也有例外，比如一个ACK 请求与对应的INVITE请求具有相同的CSeq，但它们却构成了各自的事务。 一个正常的呼叫一般包含三个事务。其中，呼叫启动包含两个操作请求：邀请（INVITE）和证实（ACK），前者需要回送响应，后者只是证实已收到最终响应，不需要回送响应。呼叫终结包含一个操作请求：再见（BYE）。 定位服务 SIP重定位服务器或代理服务器用来获得被叫位置的一种服务，可由定位服务器提供，但SIP协议不规定SIP服务器如何请求定位服务。 代理服务器 代理服务器（Proxy Server）是用于将SIP请求路由到目的地的中间路径。它既是客户端也是服务器。用户请求可以直接被代理服务器处理或被转发给别的代理服务器。代理服务器在转发之前要对消息进行解析，必要时还会改写请求。 重定向服务器
SIP协议介绍及应用前景分析
2017年第2期信息通信2017 (总第170 期）INFORM ATION & COMMUNICATIONS (Sum. No 170) SIP协议介绍及应用前景分析 杜鑫 (中国人民解放军9155〇部队3分队） 摘要:S IP是一种源于互联网的IP语音会话控制协议，具有灵活、易于实现、便于扩展等特点。文章介绍了 S IP协议的发 展历史、网络组成，通过与传统的电信网络协议对比分析了 S IP协议的特点，结合S IP协议特点及现状对其应用前景进 行了分析。 关键词：SIP ;融合通信;VO LTE;互联网 中图分类号:TN913.23 文献标识码:A文章编号：1673-1131(2017)02-0105-02 1S IP协议的发展历史 SIP(Session Initiation Protocal)会话初始化协议的概念在 1996年出现，主要运用在Internet的不同文本类型当中，用于 电子邮件以及文字聊天等各项环节中。1999年由IE T F最初 建立，应用于Internet的相关网络环境结构当中，实现实时性 通讯。二H世纪初，由IE T F当中的S IP工作团队发出 RFC3261建议后才得到了逐渐推广。 S IP协议最初应用于Internet网络中，实现多媒体的会话 建立控制，后来作为IMS(IP M ultim edia Subsystem IP多媒体 子系统）的主要信令应用于电信领域的VOBB(V oiceover Broad Band宽带语音)，近年来随着LT E的推广，SIP成为LTE 的语音最终解决方案V O LTE的主要信令协议，其应用范围从 特定环境逐步扩展至主流多媒体通信环境。 2 S IP网络组成 2.1 S IP协议在IM S中的应用 S IP协议是IM S中的基本协议,应用于M w、U t、ISC、M i、M g、M j、M k、M r等众多接口，整个IM S网络的会话控制功能 都是由S IP协议完成，具体使用情况如图1所示： P-CSCF ATS IM-SSF SIPl 4 M RFC UGC 19 图1S IP协议在IM S网络中应用示意图 2.2 S IP网络架构 S IP使用CS(Client/server客户端/服务器)架构如图2所 示，交互形式为请求、响应的方式。User Agent C lie n t即客户 端，发起S IP请求;User Agent Server即服务器端，进行S IP请 求处理，并进行响应，Request Proxy Server起到消息路由转发的功能。 3.2认证测试标准 系统B模型采用的简表是07B0,根据K N X协议必须满 足如表1所列的功能需求。认证测试将会针对这些基本功能 来设计测试例进行测试。 按照测试规范[6]要求，先通过E TS配置软件配置好K N X 设备后，采用E IT T软件编写好测试例，运行测试序列，所有测 试例均通过，说明该协议栈符合K N X协议规范要求。在软件 开发过程中，可以通过该方式进行各个功能点的验证，从而保 证软件的可靠性，缩短最终的认证周期。 表1系统B的基本功能表 协议栈主要功能 数据链路层数据帧的封装和解析、应答、数据过滤 网络层正确设置路由计数器 传输层支持四种传输模式；支持style3的状态机 配置和管理直接内存访问；用户内存的直接内存访问；验证模式；接口对象处理；下载状态机；运行状态机；重启；授权；设备描述业务；编程模式；K N X序列号；地址表?，关 联表；组对象表；应用相关参数 4结语 本文介绍的系统B模型的K N X设备是基于LPC处理器、L in u x系统来设计和实现的，并采用了 NCN5120芯片作为 K N X总线收发模块。该设备通过了第三方认证测试实验室的 认证测试，符合K N X协议规范。系统B模型K N X具有更丰 富的资源，可应用于复杂的智能家居和楼宇控制系统中，具有 广阔的市场价值和应用前景。 参考文献： [1]夏长凤.基于K N X总线智能家居控制系统的设计[J].电 器自动化，2016, 38⑴. [2]任志勇.基于K N X智能家居的应用[J].重庆电子工程职 业学院学报,2010, 19(4). [3]Jason Richards,Development o f Complex K N X Devices. W EINZIERL ENGINNERING GmbH,2010. [4]Konnex Association.Konnex Standard,Vol3,System Specifications,2013. [5]Konnex Association.Konnex Standard,Vol6,Profiles,2013. [6]Konnex Association.Konnex Standard,Vol8,System Test Specifications,2013. 作者简介:朱莉(1979-)，女，四川省资中县人，电子工程师，硕 士学位，主要研宄方向为智能家居、大数据、LTE。 105
SIP协议测试总结
SIP协议测试总结 一：响应码定义 1、响应（Response） 1）1XX：临时响应，表示请求消息正在被处理。 2）2XX：成功响应，表示请求已被成功接收，完全理解并被接受。 3）3XX：重定向响应，表示需采取进一步以完成该请求。 4）4XX：客户机错误，表示请求消息中包含语法错误信息或服务器无法完成客户机请求。 5）5XX：服务器错误，表示服务器无法完成合法请求。 6）6XX：全局故障，表示任何服务器无法完成该请求。 100：临时响应，正在尝试 180：振铃，UA收到INVITE请求之后用该响应通知用户，该响应也可以再发起一个本地回铃 181：呼叫正在转发 182：排队 183：会话进行 200：OK 300网络协议不兼容:会话描述中的一个或多个网络协议不可用。 301网络地址格式不兼容:会话描述中的一个或多个地址格式不可用。 302传送协议不兼容:会话描述中的一个或多个传送协议不可用。 303带宽单位不兼容:会话描述中的一个或多个带宽度量单位不被理解。 304媒体类型不可用:对话描述中的一个或多个媒体类型不可用。 305媒体格式不兼容:对话描述中的一个或多个媒体格式不可用。 306媒体特征不被理解:对话描述中的一个或多个媒体特征不被支持。
307对话描述参数不被理解:除上述几种参数之外的参数不被理解。 330组播不可用:用户站点不支持组播。 331单播不可用:用户站点不支持单播通信(通常是由于防火墙的存在)。 370带宽不足:对话描述中定义的或者媒体定义的带宽超出可用带宽。 399混合告警:该告警表示用户存在的任意一种错误，收到该告警的系统不可以采取任何自动的动作 401：未授权 403：禁止 404：未找到 405：不允许的请求方法 406：不接受 407：代理服务器需要鉴权 408：请求超时 413：请求消息过大 415：不支持的媒体类型 414：Request-URI过长 415：不支持媒体类型 416：不支持的URI方案 420：错误的扩展 421：需要扩展支持 423：间隔太短 480：临时不可用 481：呼叫/事务不存在 482：检测到路由循环
SIP协议的认识及呼叫追踪分析实验
《软交换系统实验》实验报告四 实验室名称：现代通信网络实验室实验日期： 2011 年 6月 5日 学院（系）专业、班级姓名成绩 实验项目SIP协议的认识及呼叫追踪分析实验指导教师 教师评语 教师签名： 年月日 一、实验过程原始记录(数据、图表等) 1．设备配置实验记录 设备名称设备IP地址短号设置长号设置 EIA2016设备192.168.0.3 101 EIT200 SIP电话192.168.1.101 802 2．呼叫跟踪实验记录 3．1）主叫信息 群号： 1 短号： 101 长号：用户标识码: （2）被叫信息 群号：1 短号： 102 长号：用户标识码: （3）呼叫消息原始记录（包括：主叫方和被叫方与EIX交互的信令消息） ①主叫方与EIX交互的呼叫信令消息跟踪结果： [151-12:02:09:970] MSG :--->> to 192.168.0.3/58525 crypt:TRUE Phone Call proto:P2PV2 len:739 INVITE sip:25130016@192.168.0.3 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.3:2080;branch=z9hG4bK7155de6d801d63c038d6335428dfb99e ;rport From: