sip之路一:初入sip

SIP协议概述

  1. 最早是为了实现IP电话(VoIP),使用IP电话实现语音通话,以节省打电话的成本。
  2. 实现IP电话需要三类协议: 信令协议、媒体传输协议、其他支撑协议。
  3. Sip是Session Initiation Protocol的缩写,也叫做会话发起协议。
  4. Sip用于建立、修改和终止IP网上的双方或多方的多媒体会话
  5. SIP协议支持代理、重定向、登记、定位用户等功能。
  6. 支持用户的移动,与RTP/RTCP、SDP、DNS等协议配合。
  7. 可支持和应用于语音、视频、数据等多媒体业务。

注意:现在完全不用去在意下面细节,你可以简单的把下面这堆概念简单分为两类:SIP客户端,以及SIP服务器。
将UAC和UAS称作 "用户代理客户端” 和 “用户代理服务器”
至于“登记服务器”、“位置服务器”、“重定向服务器”,这些属于逻辑上的概念,当真正动手配置一台SIP服务器的时候,这些东西完全可以是在一台终端上。

User Agents -终端

  1. 用户代理,是一个软终端或者是一个支持SIP协议的电话。
  2. 对接收到的行为进行代理,发送到SIP网络中。
  3. 一个发起和终止会话的实体,包含两个功能实体:

User Agent Clients(UAC):发起SIP事务请求的功能实体;
比如:用户点击拨号键–通过UAC–翻译成invite请求消息。

User Agent Server(UAS):接收SIP事务请求的功能实体;
比如:sip向用户发送invite请求–通过UAS–翻译成相应的动作(振铃)。

Proxy Server -代理服务器

  1. 对收到的请求消息进行翻译和处理后,传递给其他的服务器。
  2. 为其它的客户机代理,进行SIP消息的转接和转发的功能
  3. 对SIP请求及响应进行路由。

Location Server-位置服务器

是一个数据库,用于存放终端用户当前的位置信息,为SIP 重定向服务器(Redirect Server)或代理服务器(proxy server)提供
被叫用户可能的位置信息

Redirect Server-重定向服务器

  1. 将用户新的位置返回给呼叫方。呼叫方可根据得到的新位置重新呼叫
  2. Redirect Server只是对请求消息进行响应,不产生请求消息。

Registrar Server-登记服务器

  1. 接受REGISTER 请求完成用户地址的注册。
  2. 可以支持鉴权的功能。

采用了因特网的URL

  1. 统一的资源定位:全球唯一地址。
  2. 支持因特网地址(IP地址)和PSTN地址。
  3. 一般的地址格式:name@domain
  4. 名称@域名(也可以是IP地址)
  5. 完整的URL地址:sip:808186@111.111.111.111:5060

SIP消息的类型和功能

  1. SIP 消息机制基于Client/Server方式,消息分为请求、响应。
  2. 为SIP终端用户提供定位功能
  3. 进行媒体属性协商
    封装协议:SDP(会话描述协议-SessionDescrible Protocol)
  4. 发起会话:采用请求消息:INVITE(邀请)。
  5. 改变会话:采用请求消息:Re-INVITE(重发邀请,Cseq增加)。
  6. 结束会话:采用请求消息: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消息的结构和重要头域

在这里插入图片描述

请求消息的首行格式

  1. 消息名称:REGISTER
  2. 请求的url:sip:808186@111.111.111.111:5060
  3. 协议版本号:SIP/2.0
  4. 一条完整的请求消息首行:REGISTER sip:808186@111.111.111.111:5060 SIP/2.0

响应消息中的首行

  1. 协议版本号:SIP/2.0
  2. 状态码:100
  3. 原因短语:Trying
  4. 一条完整的响应消息首行:SIP/2.0 100 Trying

重要头部字段

所有的请求和响应都必须包含:From 和 To 这两个字段

必须先理解一个词 Dialog

  1. Dialog直译是“会话”的意思
  2. Dialog还有个别名,叫做call leg,其实两者是一个意思,不要被各种名词搞混了。
  3. 它指的是两个SIP用户代理(User Agent, UA,可以是客户端,也可以是服务器)之间通过SIP消息交换建立的端到端的SIP关系。
  4. 这个会话发起和结束的时机是什么?
  5. 一个会话由一个SIP请求消息建立。
  6. 对于“登记”来说,REGISTER——200 OK是一个会话。
  7. 对于”发起并成功建立一次呼叫”这个过程中的INVITE——100 Trying——180 Ringing——200 OK——ACK,属于另一个会话。

From:请求的发起者

  1. 所有请求和响应消息必须包含此字段,以指示请求的发起者。
  2. 服务器将此字段从请求消息复制到响应消息。
  3. From字段的一般格式为:From:显示名(SIP URI);tag=xxx
  4. 显示名:这是可选的,“xsm”
  5. SIP URI:<sip:2@111.111.111.111>
  6. 标签:tag=928e0a737f0d4db791558ce9cb4255c5
  7. 示例:From:“xsm”<sip:2@111.111.111.111>;tag=928e0a737f0d4db791558ce9cb4255c5
  8. 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:指明请求的接收者

  1. 一条完整的To字段的一般格式:To:<sip:2@111.111.111.111>
  2. To可以有一个tag参数,注意,与From不通,这里用的是“可以有”。
  3. 因为当UAC发出请求时,Dialog 还没有建立,所以此时不包含to tag;然后当UAS收到INVITE请求时,再在响应中设置To tag。
  4. 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消息本身(包括FROMTO字段)中,端口号并不是必须包含的信息。

Call-ID

  1. 包含一个全局的唯一标志,用来唯一标志这个会话
  2. 每个会话的Call-ID必须是唯一的,以区分不同的会话。同一会话中的所有SIP消息都应该具有相同的Call-ID值。
  3. 在对话中的任一用户代理(User Agent)的所有请求和所有应答的Call-ID必须一致。
  4. 通过随机字串和softphone 的自己名字或者IP地址混和产生。
  5. 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:命令序号

  1. 客户在每个请求中应加入此字段,它由请求方法和一个十进制序号组成。
  2. 序号初值可为任意值,其后具有相同的CalID值,但不同请求方法、头部或消息体的请求,其Cseg序号应加1。
  3. 用于在同一个Dialog中标识与排序,以及区分新的请求与请求的重发。
  4. 如果是重发请求的序号保持不变。
  5. ACK和CANCEL请求的Cseq值与对应的INVITE请求相同
  6. BYE请求的Cseq值应大于INVITE请求,由代理服务器并行分发的请求其Cseq值相同。
  7. 服务器将请求中的Csea值复制到响应消息中去。
  8. 示例:CSeg:101 INVITE

Via

  1. 用以指示请求消息经历的路径。
  2. 可以防止请求消息传送产生环路,并确保响应和请求的消息选择同样的路径。
  3. 对请求消息而言,自下而上依次表示到当前所在的SIP节点为止,请求消息所经过的路径;
  4. 对响应消息而言,自上而下依次表示从当前节点开始,响应所应遵循的路径(即为响应消息的路由提供了路径记录:从哪来的到哪去)。
  5. Via字段的一般格式为:Via:发送协议 发送方 参数
  6. 发送协议的格式为:协议名/协议版本/传送层:SIP/2.0/UDP
  7. 发送方的格式为:发送方主机地址和端口号:111.111.111.112:62547
  8. 示例:Via:SIP/2.0/UDP 111.111.111.112:62547;参数

Contact

  1. 用于INVITE、ACK和REGISTER请求以及成功响应、呼叫进展响应和重定向响应消息。
  2. 作用:给出其后和用户直接通信的地址。就是填写最新的联系人地址,可以是和你当前发消息的地址不同。
  3. Contact字段的一般格式为:Contact:地址;参数
  4. Contact字段中给定的地址:不限于SIP URI,也可以是电话、传真等URL。
  5. 示例:Contact:<sip:2@111.111.111.112:62547;ob>

其他字段

  1. Max-Forwards:最大转发次数,是一个整数,每经过一跳时减一。如果Max-Forwards已经减到零,但还没有到达目的地,则产生一个483(too many hops)响应。
  2. Content-type:消息的类型
  3. Content-length:消息体的字节数

消息体

名称描述
Version:版本V=0
Origin:发起者o=
Session Name:会话名称s=
Times:会话的开始结束时间t=
Connection Data:连接的参数c=
Media:媒体流的参数m=

在这里插入图片描述

SIP基本消息流程

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值