SIP协议概述
- 最早是为了实现IP电话(VoIP),使用IP电话实现语音通话,以节省打电话的成本。
- 实现IP电话需要三类协议: 信令协议、媒体传输协议、其他支撑协议。
- Sip是Session Initiation Protocol的缩写,也叫做会话发起协议。
- Sip用于建立、修改和终止IP网上的双方或多方的多媒体会话
- SIP协议支持代理、重定向、登记、定位用户等功能。
- 支持用户的移动,与RTP/RTCP、SDP、DNS等协议配合。
- 可支持和应用于语音、视频、数据等多媒体业务。
注意:现在完全不用去在意下面细节,你可以简单的把下面这堆概念简单分为两类:SIP客户端,以及SIP服务器。
将UAC和UAS称作 "用户代理客户端” 和 “用户代理服务器”
至于“登记服务器”、“位置服务器”、“重定向服务器”,这些属于逻辑上的概念,当真正动手配置一台SIP服务器的时候,这些东西完全可以是在一台终端上。
User Agents -终端
- 用户代理,是一个软终端或者是一个支持SIP协议的电话。
- 对接收到的行为进行代理,发送到SIP网络中。
- 一个发起和终止会话的实体,包含两个功能实体:
◆User Agent Clients(UAC):发起SIP事务请求的功能实体;
比如:用户点击拨号键–通过UAC–翻译成invite请求消息。
◆User Agent Server(UAS):接收SIP事务请求的功能实体;
比如:sip向用户发送invite请求–通过UAS–翻译成相应的动作(振铃)。
Proxy Server -代理服务器
- 对收到的请求消息进行翻译和处理后,传递给其他的服务器。
- 为其它的客户机代理,进行SIP消息的转接和转发的功能。
- 对SIP请求及响应进行路由。
Location Server-位置服务器
是一个数据库,用于存放终端用户当前的位置信息,为SIP 重定向服务器(Redirect Server)或代理服务器(proxy server)提供
被叫用户可能的位置信息。
Redirect Server-重定向服务器
- 将用户新的位置返回给呼叫方。呼叫方可根据得到的新位置重新呼叫。
- Redirect Server只是对请求消息进行响应,不产生请求消息。
Registrar Server-登记服务器
- 接受REGISTER 请求完成用户地址的注册。
- 可以支持鉴权的功能。
采用了因特网的URL
- 统一的资源定位:全球唯一地址。
- 支持因特网地址(IP地址)和PSTN地址。
- 一般的地址格式:name@domain
- 名称@域名(也可以是IP地址)
- 完整的URL地址:sip:808186@111.111.111.111:5060
SIP消息的类型和功能
- SIP 消息机制基于Client/Server方式,消息分为请求、响应。
- 为SIP终端用户提供定位功能。
- 进行媒体属性协商
封装协议:SDP(会话描述协议-SessionDescrible Protocol) - 发起会话:采用请求消息:INVITE(邀请)。
- 改变会话:采用请求消息:Re-INVITE(重发邀请,Cseq增加)。
- 结束会话:采用请求消息:BYE,CANCEL。
基本请求消息
消息 | 功能 |
---|---|
INVITE | 发起会话请求 |
ACK | 对INVITE请求的响应消息的确认 |
BYE | 结束会话 |
CANCEL | 取消尚未完成的请求 |
REGISTER | 注册 |
OPTIONS | 查询服务器的能力 |
SIP响应消息
消息 | 功能 | 举例 |
---|---|---|
1XX | 临时响应 | 100 Trying 180 Ringing(processed locally) 181 Call is Being Forwarded |
2XX | 成功 | 200 ok |
3XX | 重定向 | 300 Multiple Choices 301 Moved Permanently 302 Moved Temporarily |
4XX | 客户端错误 | 401 Unauthorized 408 Request Timeout |
5XX | 服务端错误 | 503 Service Unavailable 505 Version Not supported |
6XX | 全局错误 | 600 Busy Everywhere 603 Decline |
SIP消息的结构和重要头域
请求消息的首行格式
- 消息名称:REGISTER
- 请求的url:sip:808186@111.111.111.111:5060
- 协议版本号:SIP/2.0
- 一条完整的请求消息首行:REGISTER sip:808186@111.111.111.111:5060 SIP/2.0
响应消息中的首行
- 协议版本号:SIP/2.0
- 状态码:100
- 原因短语:Trying
- 一条完整的响应消息首行:SIP/2.0 100 Trying
重要头部字段
所有的请求和响应都必须包含:From 和 To 这两个字段
必须先理解一个词 Dialog
- Dialog直译是“会话”的意思
- Dialog还有个别名,叫做call leg,其实两者是一个意思,不要被各种名词搞混了。
- 它指的是两个SIP用户代理(User Agent, UA,可以是客户端,也可以是服务器)之间通过SIP消息交换建立的端到端的SIP关系。
- 这个会话发起和结束的时机是什么?
- 一个会话由一个SIP请求消息建立。
- 对于“登记”来说,REGISTER——200 OK是一个会话。
- 对于”发起并成功建立一次呼叫”这个过程中的INVITE——100 Trying——180 Ringing——200 OK——ACK,属于另一个会话。
From:请求的发起者
- 所有请求和响应消息必须包含此字段,以指示请求的发起者。
- 服务器将此字段从请求消息复制到响应消息。
- From字段的一般格式为:From:显示名(SIP URI);tag=xxx
- 显示名:这是可选的,“xsm”
- SIP URI:<sip:2@111.111.111.111>
- 标签:tag=928e0a737f0d4db791558ce9cb4255c5
- 示例:From:“xsm”<sip:2@111.111.111.111>;tag=928e0a737f0d4db791558ce9cb4255c5
- From字段包含一个tag参数,在UAC发出一个会话建立请求时,必须设置一个唯一的tag参数,作为Dialog ID的一部分。
误区:本机IP为:11.11.111.112 注册sip服务器的IP是:11.11.111.111:5060,抓包的数据FROM为:From:<sip:2@111.111.111.111>
关键点:From字段的 URI部分确实用于标识SIP请求的逻辑发起者,SIP URI 是用于在SIP网络中唯一标识用户或服务的逻辑地址,而不是物理地址(如IP地址)。
SIP URI 通常包含用户名(如 2)、主机名(或IP地址)和可选的端口号,以及可能的传输协议标识(如 sip:)。
在上述的例子中,sip:2@111.111.111.111 是一个SIP URI,它标识了用户 2 在主机 111.111.111.111 上的SIP账户,而不是直接表示发起请求的设备的IP地址。
当你向SIP服务器(如 11.11.111.111:5060)注册时,你实际上是在告诉服务器:“我是这个SIP URI(如 sip:2@111.111.111.111)的拥有者,当有人想要与我通信时,请通过我的IP地址(如 11.11.111.111)和端口(通常是SIP客户端监听的端口)与我联系。” ;但是,注册过程中的SIP URI 是与你的SIP账户相关联的,而不是直接与你当前的网络连接或IP地址绑定。
To:指明请求的接收者
- 一条完整的To字段的一般格式:To:<sip:2@111.111.111.111>
- To可以有一个tag参数,注意,与From不通,这里用的是“可以有”。
- 因为当UAC发出请求时,Dialog 还没有建立,所以此时不包含to tag;然后当UAS收到INVITE请求时,再在响应中设置To tag。
- To tag与From tag以及Call-ID一起,作为一个Dialog的唯一标识。
误区:请求消息首行sip:2@111.111.111.111:5060,但在FROM与TO字段中URL是sip:2@111.111.111.111,为什么没有端口号?
关键点:SIP URI主要用于在SIP网络中唯一标识用户或服务,而端口号更多地与具体的传输层协议(如UDP或TCP)和服务器配置相关。
请求头部包含端口号时,这通常是因为在建立连接或发送请求时,需要在传输层协议(如UDP或TCP)中指定端口号。然而,在SIP消息本身(包括FROM
和TO
字段)中,端口号并不是必须包含的信息。
Call-ID
- 包含一个全局的唯一标志,用来唯一标志这个会话。
- 每个会话的Call-ID必须是唯一的,以区分不同的会话。同一会话中的所有SIP消息都应该具有相同的Call-ID值。
- 在对话中的任一用户代理(User Agent)的所有请求和所有应答的Call-ID必须一致。
- 通过随机字串和softphone 的自己名字或者IP地址混和产生。
- Call-ID的格式通常遵循一定的规范,如UUID(Universally Unique Identifier,通用唯一识别码)格式,但也可以是其他形式的字符串,只要保证唯一性即可。
Call-ID并不是唯一一个用于标识SIP会话的字段,它和UAC在发出的请求消息中设置的From Tag以及UAS在其响应消息中设置的To Tag,三个字段一起作为一个SIP会话的Dialog-ID。
对Call-ID、From Tag、To Tag三者的作用和关系搞不清楚的话也没关系,抓几个包,根据SIP交互流程,分析一下它们在哪些报文里面是一样的,从哪个报文开始变化了。
Cseq:命令序号
- 客户在每个请求中应加入此字段,它由请求方法和一个十进制序号组成。
- 序号初值可为任意值,其后具有相同的CalID值,但不同请求方法、头部或消息体的请求,其Cseg序号应加1。
- 用于在同一个Dialog中标识与排序,以及区分新的请求与请求的重发。
- 如果是重发请求的序号保持不变。
- ACK和CANCEL请求的Cseq值与对应的INVITE请求相同。
- BYE请求的Cseq值应大于INVITE请求,由代理服务器并行分发的请求其Cseq值相同。
- 服务器将请求中的Csea值复制到响应消息中去。
- 示例:CSeg:101 INVITE
Via
- 用以指示请求消息经历的路径。
- 可以防止请求消息传送产生环路,并确保响应和请求的消息选择同样的路径。
- 对请求消息而言,自下而上依次表示到当前所在的SIP节点为止,请求消息所经过的路径;
- 对响应消息而言,自上而下依次表示从当前节点开始,响应所应遵循的路径(即为响应消息的路由提供了路径记录:从哪来的到哪去)。
- Via字段的一般格式为:Via:发送协议 发送方 参数
- 发送协议的格式为:协议名/协议版本/传送层:SIP/2.0/UDP
- 发送方的格式为:发送方主机地址和端口号:111.111.111.112:62547
- 示例:Via:SIP/2.0/UDP 111.111.111.112:62547;参数
Contact
- 用于INVITE、ACK和REGISTER请求以及成功响应、呼叫进展响应和重定向响应消息。
- 作用:给出其后和用户直接通信的地址。就是填写最新的联系人地址,可以是和你当前发消息的地址不同。
- Contact字段的一般格式为:Contact:地址;参数
- Contact字段中给定的地址:不限于SIP URI,也可以是电话、传真等URL。
- 示例:Contact:<sip:2@111.111.111.112:62547;ob>
其他字段
- Max-Forwards:最大转发次数,是一个整数,每经过一跳时减一。如果Max-Forwards已经减到零,但还没有到达目的地,则产生一个483(too many hops)响应。
- Content-type:消息的类型
- Content-length:消息体的字节数
消息体
名称 | 描述 |
---|---|
Version:版本 | V=0 |
Origin:发起者 | o= |
Session Name:会话名称 | s= |
Times:会话的开始结束时间 | t=
|
Connection Data:连接的参数 | c= |
Media:媒体流的参数 | m= |