SIP (Session Initiation Protocol) 协议

Session Initiation Protocol 介绍

SIP是VoIP技术最常使用的协议，它是一种应用程序层协议，可与其他应用程序层协议配合使用，以控制Internet上的多媒体通信会话。

VoIP 技术

开始之前先对VoIP做些了解.

  • VoIP是一项允许您通过Internet传递语音和多媒体（视频，图片）内容的技术。这是利用Internet的可用性随时随地进行通信的最便宜的方法之一。

  • 其优点包括

    • 便宜

    • 可移植性

    • 灵活性

    • 视频会议

  • 对于VoIP通话，您所需要的只是一台具有Internet连接的计算机/笔记本电脑/移动电话。下图描述了如何进行VoIP呼叫

　　VoIP

 

SIP – 总览

以下是SIP的几点介绍

  • SIP是一种信令协议，用于创建，修改和终止多媒体会话。会话仅仅是两个端点之间的通话。这个端点可以是智能手机，便携式计算机或任何可以接收和发送多媒体内容的设备。

  • SIP标准文档为RFC3261.

  • SIP基于客户端-服务器架构，url类似于HTTP协议，文本编码和头部类型与SMTP协议类似.

  • SIP使用SDP (Session Description Protocol)协议描述会话，使用RTP (Real Time Transport Protocol)协议传输音视频数据.

  • SIP也可以被用作单播多播会话.

  • SIP其他方面的应用包括文件传输，即时消息，视频会议，在线游戏，流媒体分发等.

SIP的网络层次

SIP是一个应用层协议. 它是一种简单的网络信令协议，创建中断一个或多个会话. SIP被设计为独立于基础的传输协议之上，所以它既可以基于TCP，也可以基于UDP运行.

下图描述了SIP在通用方案中的位置:

SIP Layers

通常，SIP协议用于两个或多个端点之间的网络电话和多媒体分发。一如，一个人可以使用SIP向另一个人发起电话呼叫，或者某个人可以与许多参与者简历电话会议。

SIP协议被设计的非常简单，仅有有限个命令集，它是基于文本的协议，因此任何会话中的参与者都可以阅读SIP消息.

SIP网络元素

以下几种网络元素构成了SIP网络体系.SIP中每一种网络元素都由SIP URI (Uniform Resource Identifier) 地址所标识.

  • User Agent
  • Proxy Server
  • Registrar Server
  • Redirect Server
  • Location Server

User Agent

它是端点，SIP网络中最重要的元素之一. 端点可以邀请，修改，中断一次会话. UA是SIP中最智能的设备或网络元素. 它可以是softphone, mobile, 或者是 laptop.

UA在逻辑上被分为两部分:

  • User Agent Client (UAC) − 发送请求接受响应的设备.

  • User Agent Server (UAS) − 接收请求做出回应的设备.

SIP基于C/S架构，呼叫着的电话充当客户端，被呼叫的电话充当服务端.

Proxy Server

将一个UA的请求转发给其他用户的设备.

  • 扮演了类似于路由器的角色.

  • 具有一定的智能可以理解SIP请求，并借助URI提前发送.

  • 位于两个UA之间.

  • UA之间最多可以有70个代理server.

有两种典型的代理server

  • 无状态代理服务器 − 仅仅转发收到的消息，不存储任何呼叫和事务方面的信息.

  • Stateful Proxy Server − 这种类型的代理服务器会跟踪收到的每个请求和响应，并在将来需要时可以使用它。如果没有及时的响应，它可以重新发送请求.

Registrar Server

注册服务器从UA接收注册请求. 帮助用户进行网络验证. 它将URI和用户的位置存储在数据库中以帮助同一域中的其他SIP服务器.

下图是SIP注册的流程.

SIP Registration Example

呼叫者想在TMC域中注册，因此发送REGISTER请求给TMC’s服务器，服务器返回200 OK响应授权给客户端.

Redirect Server

重定向服务器接收到请求，然后从注册服务商创建的数据库中查找预期的收件人.

重定向服务器使用数据库获取位置信息并以3xx响应用户.

Location Server

本地服务器向代理服务器、重定向服务器提供有关呼叫者可能的位置信息.

仅有代理服务器或重定向服务器可以联系本地服务器.

下图描绘了每个网络元素在建立会话中所扮演的角色.

Location Server

SIP – 系统架构

SIP被构造为分层协议，这意味着它的行为是根据一组相当独立的处理阶段来描述的，每个阶段之间只有一个松散的耦合.

System Architecture

  • 最底层是SIP的语法和编码. 它的编码被指定使用增强型 Backus-Naur Form grammar (BNF).

  • 第二层是传输层，它定义了Client/Server如何发送接收消息. 所有的SIP元素都包含传输层

  • 事务层. 事务是Client向Server发送的所有请求以及Server的所有回应. 任何UAC任务的完成都以事务的形式发生. 无状态的代理没有事务层.

  • 最上层成为事务用户. 每个SIP实体除了Stateless proxies, 都是一个事务用户.

SIP - 基本通话流程

下图是一个SIP session的通话流程图.

SIP Call Flow

解释如下

  • 一个 INVITE 请求开始一个会话.

  • 代理服务器马上发送 100 Trying 响应给Alice阻止 INVITE request的重传.

  • 代理服务器从本地服务器查询Bob的地址，获取地址后，它将进一步转发 INVITE 请求.

  • 此后，由Bob产生的180 Ringing (临时响应) 返回给 Alice.

  • 200 OK 响应通常在Bob拿起电话不久后就会产生.

  • Alice收到 200 OK. 返回给Bob一个 ACK.

  • 同时会话被创建，RTP数据包开始在两端流动.

  • 会话结束后，任何参与者都可以发送 BYE 请求来终止会话.

  • BYE 直接从Alice到Bob，绕过代理服务器.

  • 最后，Bob发送  200 OK 响应 BYE ，中断会话.

  • 以上基本通话流程，包含3个事务（1,2,3）.

完整的通话（从 INVITE 到 200 OK）被称作 对话.

SIP 梯形

下图显示代理如何帮助连接两个用户.

SIP Trapezoid

图片中显示的拓扑结构被称为SIP梯形

  • 当呼叫方发起呼叫时，一个 INVITE 消息被发送给代理服务器. 收到 INVITE 后，代理服务器在DNS服务器的帮助下解析被叫者的地址.

  • 获得下一跳的路由后，Proxy 1, 也被称为 outbound 出站代理服务器转发 INVITE 请求到 Proxy 2  inbound 入站代理服务器给被叫者.

  • inbound 代理服务器联系本地服务器获取被叫者注册过的地址信息 .

  • 获得地址信息后，转发呼叫到目的地.

  • 一旦用户UA获得他们的地址，他们就可以绕过呼叫，直接传递会话.

SIP - 消息传递

SIP消息分为两类 请求 和 响应.

  • 请求的开始行包含一个定义请求的方法，以及一个将请求发往何处的URI.

  • 同样，响应中也包含一个响应码.

请求Method

SIP请求是用于建立通信的代码。为了补充它们，通常有一些SIP响应指示请求是成功还是失败。

这些方法使SIP消息可以运行起来.

  • METHODS 可以被视为SIP请求，因为它们请求由另一个用户代理或服务器采取的特定操作.

  • METHODS 被分为两类−

    • 核心方法

    • 扩展方法

核心方法

以下6个核心方法将被讨论.

INVITE

INVITE 用来启动一次会话. 换句话说, 一个 INVITE 方法被用来在UA之间建立媒体会话.

    • INVITE 可以在 消息体 内包含呼叫者的媒体信息.

    • 会话建立的标志是: INVITE 收到了成功的响应(2xx) 或 发送出去一个 ACK.

Invite

  • 一个成功的 INVITE 请求，在两个UA之间建立了一个 dialog （对话），直到发送 BYE 中断会话.

  • 在一个建立的dialog中再次发送 INVITE 被称作 re-INVITE.

  • Re-INVITE 被用来改变会话的特征或刷新dialog状态.

INVITE 举例

下面的代码显示了INVITE的使用.

INVITE sips:Bob@TMC.com SIP/2.0 
Via: SIP/2.0/TLS client.ANC.com:5061;branch=z9hG4bK74bf9 
Max-Forwards: 70 
From: Alice<sips:Alice@TTP.com>;tag=1234567 
To: Bob<sips:Bob@TMC.com>
Call-ID: 12345601@192.168.2.1  
CSeq: 1 INVITE 
Contact: <sips:Alice@client.ANC.com> 
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces 
Content-Type: application/sdp 
Content-Length: ...  

v=0 
o=Alice 2890844526 2890844526 IN IP4 client.ANC.com 
s=Session SDP 
c=IN IP4 client.ANC.com 
t=3034423619 0 
m=audio 49170 RTP/AVP 0 
a=rtpmap:0 PCMU/8000

BYE

BYE 用来中断一个建立的会话. 这个请求可以被呼叫者或被呼叫者发送.

  • 代理服务器不能发送.

  • BYE 请求通常跳过代理服务器，端到端发送.

  • BYE 不能发送给一个等待 INVITE 或 一个未建立的会话.

REGISTER

REGISTER 方法是UA用来发送注册请求. 这个请求是UA发给 注册服务器.

  • REGISTER 请求可以转发或代理知道到达指定域的权威注册商为止.

  • 它在 To 字段中携带正在被注册的用户的 AOR (Address of Record).

  • REGISTER 请求包含时间周期 (3600sec).

  • 一个UA可以代表另一个UA发送 REGISTER 请求. 这就是所谓的 第三方注册. 

CANCEL

CANCEL 被用来终止未建立的会话. UA使用这个请求取消先前发起的挂起的呼叫尝试.

  • 它可以被UA或代理服务器发送.

  • CANCEL 是一个逐跳的请求，它通过UA之间的服务设备接收一个有状态设备的响应.

Hop By Hop

ACK

ACK 是对 INVITE方法的最后响应. ACK 可能包含SDP消息体如果它在INVITE中不可用.

SDP Ack

  • ACK不能用来修改已经在初始  INVITE 中发送的媒体描述.

SDP Acknowledgement

  • 有状态的代理接收到ACK必须确定是否这个ACK应该被转发另一个代理或UA.

  • 对于 2xx 的响应, ACK 是端到端的，对于其他最终响应，有状态的代理是逐跳工作的.

OPTIONS

OPTIONS 方法被用来查询UA或代理服务器的功能. 响应列出可用的功能. 代理不会生成 OPTIONS 请求.

扩展方法

SUBSCRIBE

SUBSCRIBE 被用来建立订阅，以获取关于特定事件的通知i.

  • 它包含一个 Expires 头指示订阅的持续时间.

  • 时间过期后自动终止订阅.

  • 订阅在UA之间建立会话.

  • 你可以在过期之前发送另一个 SUBSCRIBE .

  • 一个 200 OK 从用户那里收到.

  • 用户和已发送另一个过期值为0的 SUBSCRIBE 取消订阅.

Example Subscribe

NOTIFY

UA使用NOTIFY来获取特定事件的发生. 通常，当订阅者和通知程序之间存在订阅时，将在触发通知.

  • 每一个 NOTIFY，当被通知人收到后，会回复 200 OK.

  • NOTIFY 包含一个 Event 头来指示事件，一个 subscriptionstate 头指示当前状态.

  • 一个 NOTIFY 在订阅的开始和中断时发送.

PUBLISH

PUBLISH 被用来发送事件状态信息给服务器.

Publish

  • PUBLISH 非常有用当有多个事件信息源的时候.

  • PUBLISH 与 NOTIFY 非常类似, 只是不再对话中发送.

  • PUBLISH 必须包含 Expires 字段和 Min-Expires 字段.

REFER

REFER 用来被一个UA引用另一个UA来访问对话的URI.

  • REFER 必须包含 Refer-To 域. 

  • REFER 的发送可以在对话期间也可以不在.

  • 202 Accepted 将会触发 REFER 请求，表明其他UA已经同意了引用.

INFO

INFO 被一个UA发送信令信息给另一个UA与它建立媒体会话.

  • 这是一个端到端的请求.

  • 代理设备会始终转发 INFO 请求.

UPDATE

UPDATE 被用来修改会话状态当会话未建立时，用户可以使用UPDATE 修改编码.

Update

如果会话已经建立，使用 re-Invite 改变或更新会话.

PRACK

PRACK 用于确认收到了可靠的临时回复(1XX).

  • 通常 当client收到一个包含RSeq的可靠序列号和支持的:100rel 报头.

  • PRACK 包含 (RSeq + CSeq) 值 rack 头.

  • PRACK 方法适用于所有的临时响应，除了从未可靠的传输中收到 100 Trying 响应.

  • PRACK 可以包含一个消息体，用来 offer/answer 交换.

MESSAGE

使用SIP发送即时消息. 一个IM通常包含的内容比较短.

Message

  • MESSAGE 的发送可以在对话期间也可以不在.

  • MESSAGE 内容在消息体中携带，作为一个 MIME 附件.

  • 200 OK 响应收到后，表明消息已经发送到它的目的地.

SIP - 响应码

SIP 响应消息通常由UAS或SIP server发出，它可以是一个正式的确认，防止UAC重传请求.

  • 响应可能包含一些UAC需要的报头信息.

  • SIP 有六类响应.

  • 1xx t到 5xx 借用于HTTTP，6xx 由 SIP 引入.

  • 1xx 是临时回复，其它的是最终回复.

响应码Function & Description
1xx Provisional/Informational Responses

信息响应用来显示呼叫的进度. 通常响应是端到端的(除了 100 Trying).
2xx Success Responses

这类响应表明请求已经被收到.
3xx Redirect Responses

通常这类响应由重定向服务器发送，来响应INVITE. 它们也被称为重定向类响应.
4xx

Request Failure Responses

由于客户端的错误，服务器响应表明请求不能被满足.
5xx Server Failure Response

这类响应表明Server端遇到错误无法完成请求的内容.
6xx Global Failure Response

这类响应表明请求在任何地方都无法得到回应，都会失败.

SIP - Headers

报头是SIP消息的组件，传达该消息的信息. 它是一组结构化的报头序列.

SIP 报头大部分情况下跟HTTP报头采用相同的规则. 报头以 NAME:VALUE的形式定义，NAME用来表明报头字段名，VALUE是包含信息的令牌. 

SIP Headers - 紧凑形式

许多常见的SIP报头字段都有一个紧凑的形式，其中报头字段名称由单个小写字符表示. 下面给出一些例子 -

HeaderCompact Form
To T
Via V
Call-ID I
Contact M
From F
Subject S
Content-Length I

SIP Header Format

下图显示了典型SIP报头的结构.

SIP Header Format

SIP - Session Description Protocol

SDP 会话描述协议. 它以一种参与者可以理解的形式来描述多媒体会话. 根据此描述，一方决定是否加入，何时加入，如何加入会议.

  • 会议的所有者，通过网络，发送包含会话描述的多播消息，例如：所有者的名称、会话的名称、编码、时间等. 根据这些信息，接收者决定是否参与会议.

  • SDP 通常包含在SIP的BODY体内.

  • SDP 协议文档 RFC 2327. An SDP message is composed of a series of lines, called fields, whose names are abbreviated by a single lower-case letter, and are in a required order to simplify parsing.

SDP使用的原因

目的是在多媒体会话中传递有关媒体流的信息，帮助参与者加入或收集特定会话的信息.

  • SDP 是一种简短的结构化文本描述.

  • 它传达了会话的名称和目的、媒体、协议、编解码器格式、时间和传输信息.

  • 一个试探性参与者检查这些信息，决定是否加入会话，如何以及什么时候加入会话.

  • 该格式以<type> = <value>形式展示, <type> 定义了一个唯一的会话参数，<value> 为参数提供了一个特定的值.

  • SDP消息的通用格式为: x = parameter1 parameter2 ... parameterN

  • 每行以一个小写字母开始，例如， x.  字母和=之间没有空格，每个参数之间只有一个空格. 每个字段有一定数量的参数.

Session Description Parameters

会话描述(* 表示可选)

  • v=(协议版本)
  • o=(所有者/创建者会话标识符)
  • s=(会话名)
  • i=*(会话信息)
  • u=*(URI)
  • e=*(email地址)
  • p=*(电话号码)
  • c=*(连接信息 - 如果包含在所有的媒体中则不需要)
  • b=*(带宽信息)
  • z=*(时区调整)
  • k=*(加密秘钥)
  • a=*(零或多个会话属性行)

Protocol Version

v= 字段包含SDP版本号. 由于当前SDP版本是0，一个有效的SDP消息总是以v=0开始.

Origin

o= 字段包含会话参与者和会话标识符信息. 次字段用于唯一表示会话.

  • 次字段包含 −

    o=<用户名><会话id><版本><网络类型><地址类型>

  • <用户名>包含发起者的登录名或主机名.

  • <会话id>Network Time Protocol (NTP) 时间戳或一个随机确保唯一性.

  • <版本>每次会话的更改这个数字字段都会增加，建议使用NTP时间戳.

  • <网络类型>总是 IN . <地址类型> IP4 或 IP6 对应 IPv4 或 IPv6 地址，既可以是点分十进制或全限定的主机名.

Session Name and Information

s= 字段包含了会话的名称. 它可以包含任何大于零个数量的字符. i= 字段包含会话的信息. 可以包含任意数量字符.

URI

u= 字段包含一个唯一资源定位符 (URI) 提供更多会话的信息.

E-Mail Address 和 Phone Number

e= 包含一个e-mail 会话主机的地址. p= 包含一个电话号码.

Connection Data

c= 包含媒体连接信息.

    • c =<network-type><address-type><connection-address>.

    • <connection-address>发送媒体数据包的IP地址或主机， 可以是单播或多播.

    • 如果是多播， <connection-address>=多播地址/ttl/地址数量

ttl 生存时长的值， 从多播基地址开始包含多少连续的多播地址.

Bandwidth

b= 包含需要的带宽信息. 格式为 b=modifier:bandwidth − value

Time, Repeat Times, and Time Zones

t= 字段包含会话开始和结束时间. t=start-time stop-time

r= 重复时间信息， 包含 NTP 或 天(d)， 时(h)， 分(m).

z= 时区调整，时区偏移量的信息. 

Media Announcements

m= 包含媒体会话信息 m= media port transport format-list

  • media 可以是 audio, video, text, application, message, image, or control.

  • port 参数表示端口号.

  • transport 参数表示传输协议 RTP 等.

  • format-list 包含更多媒体的信息. 通常包含媒体载荷类型 RTP audio/video .

Example:
m = audio 49430 RTP/AVP 0 6 8 99

Attributes

a= 包含媒体会话属性. 它被用来扩展SDP 以提供更多媒体信息，如果SDP user不能完全理解，可以被忽略. 列出的每一个媒体类型可以包含一个或多个次字段.

Attributes 可以是:

  • 会话级别
  • 媒体级别

会话级别，它被列在SDP媒体行的第一列. 该属性应用于下面的所有媒体行.

媒体级别，它被列在媒体行之后. 该属性仅应用于次特定的媒体流.

SDP 可以同时包含会话级别和每一级别属性. 如果相同的属性同时出现， 对特定的流媒体级别属性会覆盖会话级别的属性. 连接数据字段可以是媒体级别或会话级别.

SDP 示例

摘自 RFC 2327 −

v=0
o=mhandley2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu(Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416udp wb
a=orient:portrait

SIP - Offer/Answer 模式

RFC 3264 提供了SIP使用SDP offer/answer. SIP默认的消息体类型为application/sdp.

  • 主叫方在SDP中列出他们可接受的媒体，通常在一个INVITE or ACK消息中.

  • 被叫方在 INVITE 的200 OK响应中，列出了他们实现的媒体类型.

一个典型的SIP 使用的SDP包含了一下字段：version, origin, subject, time, connection, 和一个或多个 media 和 attribute.

  • SIP不使用 subject 和 time 字段，但是为了兼容还是加进去了.

  • 在SDP标准中，subject字段是必须项，必须包含至少一个字符，如果没有内容，建议使用 s=-.

  • time 字段通常被设置为 t = 00. SIP 使用 connection, media, 和 attribute 字段在UAs之间建立会话.

  • origin 字段对于SIP来时使用有限.

  • session-id 贯穿整个SIP会话中保持不变.

  • SDP每次改变时，version 都会增加. 如果SDP发送的与前一次的相同，版本保持不变.

  • 由于要使用的媒体会话类型和编解码器是连接协商的一部分，所以SIP可以使用SDP来指定多种备选媒体类型，并有选择地接受或拒绝这些媒体类型.

offer/answer 规范，RFC 3264建议一个 attribute 包含一个 a=rtpmap: 被每一个media使用. SDP响应中，将对应媒体字段的端口号设置为0，来拒绝媒体流的响应.

Example

下面的例子里，主叫Tesla 想要建立一个音频和视频的通话包含两个可用的音频编码和一个视频编码

v=0 
o=John 0844526 2890844526 IN IP4 172.22.1.102  
s=- 
c=IN IP4 172.22.1.102 
t=0 0 
m=audio 6000 RTP/AVP 97 98 
a=rtpmap:97 AMR/16000/1 
a=rtpmap:98 AMR-WB/8000/1 
m=video 49172 RTP/AVP 32 
a=rtpmap:32 MPV/90000

编解码器类型97、98，为RTP/AVP 所规定

 被叫 Marry ，为第一个media选择了第二种编解码 ，拒绝了第二种媒体形式，仅仅希望AMR会话.

v=0 
o=Marry 2890844526 2890844526 IN IP4 172.22.1.110 
s=- 
c=IN IP4 200.201.202.203 
t=0 0 
m=audio 60000 RTP/AVP 8 
a=rtpmap:97 AMR/16000 
m=video 0 RTP/AVP 32

如果不接受只有音频的通话，会在发送完ACK后发送BYE取消通话.否则，音频通话将会建立，随后通过RTP报文进行数据交互.

如本例所示，除非保持媒体域的顺序不变，否则主叫方无法确定哪个媒体会话被接受，哪个取消.

下面总结了 offer/answer 的规则.

Offer规定

一个SDP offer 必须包含所需要的SDP字段(包括 v=, o=, s=, c=, t=). 这些是必填项.

通常还包括 media 字段 (m=) 但不是必须的. 媒体行按照优先顺序列出了所有的编解码类型. 唯一的例外是，如果端点支持大量的编解码类型，则应该列出最可能被接受或最首选的编解码类型. 不同的媒体类型，包括音频，视频，文本，MSRP，BFCP等等.

Answer规定

SDP 响应一个 offer 必须按照以下规则来构造

  • answer 必须与有相同数量和顺序的编号行 m= .

  • 通过设置端口号为0来拒绝单个媒体流.

  • 发送一个非0端口号，流就会被接受.

  • 列出的每一种媒体类型的载荷，必须是在 offer 中已经列出了得.

  • 对于动态类型载荷，相同的动态类型载荷号码不需要被用在每个方向，通常仅选择一种类型.

修改会话的规定

任何一方都可以发起另一个 offer/answer 交换来修改会话

  • origin (o=) 行版本号，必须和上一次发送的相同，这表明这个SDP和前一个是相同的，或者被增加一个，表明新的SDP必须被解析.

  • offer 必须包含所有存在的媒体行，它们必须以相同的顺序发送.

  • 增加的媒体流，可以加载m= 行列表末尾.

  • 一个已经存在的媒体流，可以通过设置端口号为0，来删除. 这条媒体行必须保留在SDP和所有以后进行的 offer/anser交换会话中.

呼叫保持

通话中一方可以暂时保持另一方. 这需要发送一个INVITE，与原来 INVITE 相同的SDP， 且带有 a=sendonly 属性.

通过发送另一个带有 a=sendrecv 的INVITE 使通话变得活跃起来.

Call Hold

SIP - 移动性

Personal mobility，个人移动性是在多个设备之间拥有恒定标识符的能力. SIP支持使用REGISTER 方法，实现基本的个人移动性，这种方法允许移动设备更改其IP地址和互联网连接点，但仍然能够接收来电.

SIP 也支持服务移动性 - 当移动时保持相同服务的能力

SIP 交接时的移动性

设备通过简单的sip注册将其联系的URI与记录的地址绑定。根据设备的IP地址，注册授权此信息在sip网络中自动更新.

在切换期间，用户代理在不同的运营商之间路由，它必须再次注册一个联系人作为AOR与另一个服务提供商.

例如，UA临时接收了一个带有新的服务提供商新的SIP URI，UA执行两次注册

  • 第一次注册是在新的服务运营商那里进行的，该运营商将设备的联系人URI与新的服务提供商的AOR URI绑定.

  • 第二次 REGISTER 请求被路由回原来的服务提供商，并提供新服务提供商的AOR作为联系URI.

当请求进入原始服务提供商的网络时，INVITE被重定向到新的服务提供商，然后该服务提供商将通话路由到用户.

SIP Mobility

对于第一次注册，包含设备URI

REGISTER sip:visited.registrar1.com SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK97a7ea349ce0fca 
Max-Forwards: 70 
To: Tom <sip:UA1@registrar1.in> 
From: Tom <sip:UA1@registrar1.in>;tag = 72d65a24 
Call-ID: 4e719d1c1fc9000803630373300@172.22.1.102 
CSeq: 1 REGISTER 
Contact: <sip:Tom@172.22.1.102:5060> 
Expires: 600000 
Content-Length: 0

第二个带有漫游URI的注册消息

REGISTER sip:home.registrar2.in SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bKah4vn2u 
Max-Forwards: 70 
To: Tom <sip:UA1@registrar2.in> 
From: Tom <sip:UA1@registrar2.in>;tag = 45375 
Call-ID:87nr43i@172.22.1.102 
CSeq: 6421 REGISTER 
Contact: <sip:UA1@registrar2.in> 
Content-Length: 0

第一个 INVITE 将被发送到 sip:registrar2.in； 第二个 INVITE 将被发送到 sip: sip:Tom@registrar2.in， 将被转发到 sip:Tom@172.22.1.102. 它到达Tom并允许建立会话. 两个注册都需要定期刷新.

通话时的移动性(re-Invite)

用户代理可以在会话期间改变它的IP地址，因为它从一个网络交换到另一个网络.  基本SIP支持此场景，一个对话期间re-INVITE可以用于更新联系人URI和更改SDP中的媒体信息.

  • Tom发现一个新的网络,

  • 使用DHCP请求一个新的IP地址

  • 执行re-INVITE，让信令和媒体流使用新的IP地址.

如果UA可以从两个网络接收媒体流，中断可以忽略不计. 如果不是这样，一些媒体包可能会丢失，导致通话轻微中断.

Mobility During Call

re-INVITE如下：

INVITE sip:Jerry@TTP.com SIP/2.0  
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a 
Max-Forwards: 70 

To: <sip:Harry@TTP.com> 

From: sip:Tom@PPT.com;tag = 70133df4 
Call-ID: 76d4861c19c 
CSeq: 1 INVITE 
Accept: application/sdp 
Accept-Language: en 

Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,REFER,NOTIFY,SUBSCRIBE 
Contact: <sip:172.22.1.102:5060>; 
Content-Type: application/sdp 
Content-Length: 168 

v=0
o=PPT 40467 40468 IN IP4 192.168.2.1 
s=- 
c=IN IP4 192.168.2.1 
b=AS:49 
t=0 0 
b=RR:0 
b=RS:0 
a=rtpmap:97 AMR/8000/1 
m=audio 6000 RTP/AVP 96 
a=fmtp:102 0-15 
a=ptime:20 
a=maxptime:240

中间呼叫的移动性(With replace Header)

在中途移动中，真实的路由集合(SIP消息必经过的SIP代理集合)必须改变. 这时我们不能使用re-INVITE.

例如，如果一个NAT需要一个代理，然后Contact URI必须被修改 — 一个新的对话必须被创建. 因此，必须发送一个新的INVITE使用Replaces header标识现有会话.

Note − 假设A和B通话，如果A获得另一个INVITE(来自C的)带有Replaceheader(应该匹配现有对话)，那么A必须接受INVITE，同时中断和B的会话，传输所有资源到新建立的对话.

Mobility In Midcall

  • Tom和Jerry的通话包括了老的VisitedProxy服务器.

  • 新的通话使用了新的代理服务器的无线网络.

  • Tom发送一个Replaces INVITE请求，创建一个新的通话使用新的VisitedProxyServer而不是旧的.

  • 当Jerry接受了INVITE，BYE自动被发送中断路由到老的代理服务器的通话，使其不再参与会话.

  • 生成的媒体会话使用Tom发送的INVITE中SDP的新IP地址建立.

服务迁移

SIP服务可以被任何代理或UAs提供. 跟随个人移动性提供服务移动性是个挑战，除非用户的设备提供了相同的服务.

SIP基于internet可以很容易支持服务移动.当连接到互联网，一个UA 配置使用印度的的代理服务器时，在欧洲漫游时任然可以使用这些代理. 它对媒体会话的质量没有任何影响，因为媒体总是在两个UAs之间流动而不经过代理服务器. 只有当终端连接到互联网上时，终端驻留服务才可使用. 如果终端暂时失去了它的Internet连接，那么终端服务(如在终端中实现的呼叫前转服务)将失败. 因此一些服务在网络中使用SIP代理服务器实现.

SIP - Forking

有时一个代理服务器将一个SIP呼叫转移到多个SIP终端，这个过程被称为forking. 这是一个呼叫可以同时ring多个终端.

通过SIP forking，可以使你的固话、软件电话或手机上的SIP电话同时响铃，允许你很容易的从任何设备接听电话.

通常，在办公室，老板不能接电话或离开，SIP forking允许秘书接听他的分机.

一个有状态代理使Forking变得可能，当它需要执行和响应它收到的多个呼叫.

有两种类型的forking −

  • 平行Forking
  • 顺序Forking

平行Forking

在这个场景中，代理服务器将会同时fork INVITE 到两个设备(UA2，UA3). 两个设备将同时产生180Ringing，任何接到电话的人将会产生200 OK. 先到达发起者的响应，将会和这个设备建立会话，另一个响应将会触发CANCLE.

Parallel Forking

如果发起者同时接收到两个响应，根据q-value转发响应.

顺序Forking

在这个场景中，代理服务器将会fork INVITE 到一个设备，如果这个设备此时不可达或繁忙，然后代理将会fork它到另一个设备.

Sequential Forking

分支- ID and Tag

分支IDs帮助代理匹配响应到forked请求. 没有分支IDs，一个代理服务器就不能理解forked响应. 分支-id  在Via头部中提供.

UAC Tags被用于区分多个不同的UAS最终响应. 一个UAS不能解析是否请求已经被forked，因此需要加一个tag.

代理也可以增加tags，如果它生成一个最终的响应，他们从不插入一个tags到他们转发的请求或响应中.

单个请求也可以被多个代理服务器forked. fork的代理应该增加它自己的唯一IDs到它创建的分支.

Call leg 和 Call ID

call leg指的是两个UA之间一对一的信令关系. call ID是SIP消息里携带的唯一指代这次通话的标识. 一次通话是call legs的集合.

一个UAC以发送INVITE开始. 由于forking，它可能收到多个200 OK从不同的UAs. 在同一通话中每个对应一个不同的call-leg.

一次通话是一组call legs. 一个call leg指的是UAs之间端到端的连接.

call leg的CSeq空间在两个方向上是独立的. 在单个方向中，在每个事务上序列号是递增的.

Call Leg Id

语音信箱

对企业用户来说语音邮件变得非常普遍. 它是一个电话应用. 当被叫不可用或无法接电话时，PBX将会发出语音消息通知给被叫.

如果被叫号码不可达，UA会得到一个3xx的响应或重定向到语音信箱服务器. 然而，需要某种SIP扩展来指示语音信箱系统哪个邮箱被使用--即哪个欢迎语被播放，语音消息被记录到哪里.

有两种方式可以达成此目的 -

  • 使用SIP头字段扩展

  • 使用Request-URI通知这个信息

假设 sip:Tom@tutorialspoint.com 有一个语音信箱系统使用 sip:voicemail.tutorialspoint.com 提供语音信箱，INVITE的Request-URI 当它转发到语音信箱服务器时显示为−

sip:voicemail.tutorialspoint.com;target = sip:Tom@tutorialspoint.com;cause = 486

下图展示了Request-URI如何携带邮箱标识符和原因(这里是486)：

SIP Voicemail

SIP - 代理和路由

我们知道，代理服务器可以是无状态的，也可以是有状态的。在本章中，我们将更多地讨论代理服务器和SIP路由.

无状态代理服务器

无状态代理服务器只是转发它接收到的消息。这种服务器不存储通话或事务的任何信息.

  • 无状态代理在SIP请求被转发后就会忘记它.
  • 通过无状态代理，事务将变得很快.

有状态代理服务器

有状态代理服务器跟踪它接收到的每个请求和响. 如果需要，它可以在将来使用存储的信息. 如果没有收到对方的响应，它可以重新发送请求.

  • 有状态代理在请求被转发后会记住请求，因此它们可以将其用于提前路由. 有状态代理维护事务状态。事务意味着事务状态，而不是通话状态.

  • 使用有状态代理的事务不如无状态代理快.

  • 有状态的代理如果需要可以fork和重传.(例如：呼叫转发忙碌).

Via 和 Record-route

Record-Route

Record-Route头部通过代理插入到请求中，这些代理希望进入针对相同call-id的后续请求的路径中. 然后，用户代理使用它来路由后续请求.

Via

Via 头由服务器插入到请求中以检测循环和帮助响应找到返回客户端的路径. 这只对响应到达它们的目的地有帮助.

  • UA发送请求时，在Via头中生成和添加它自己的地址.

  • 代理转发请求时添加自己的地址到Via header地址列表顶部.

  • 代理或UA对一个请求生成一个响应，从请求里拷贝所有Via header字段按顺序放入响应中，然后发送响应到Via header指定的地址.

  • 代理收到响应，检查Via header字段然后匹配自己的地址. 如果匹配失败，响应会被丢弃.

  • 最上面的Via header 会被移除，响应转发到下一个Via header指定的地址.

Via header包含协议名称，版本号，传输层协议 (SIP/2.0/UDP, SIP/2.0/TCP, etc.)，端口号和参数，例如：received，rport，branch.

  • 如果一个UA或代理从不同地址收到一个请求，收到的tag将被加到Via header.

  • UAs和代理将分支参数添加到Via header中，它将作为 Request-URI, To, From, Call-ID, CSeq number的hash函数计算.

SIP 到 PSTN

SIP (Softphone) 和 PSTN (Old telephone)是两种不同的网络说着不同的语言. 因此我们需要一个翻译器（网关）在这两个网络之间交流.

让我们举个例子来说明SIP电话如何通过PSTN网关将电话呼叫到PSTN的.

在这个例子中，Tom (sip:tom@tutorialspoint.com) 是SIP电话，Jerry使用一个全球电话号码 +91401234567.

SIP 到 PSTN 通过网关

下图显示了从SIP通过网关到PSTN.

SIP to PSTN

下面是一步一步的解释说明.

  • 首先，(Tom) SIP电话拨打全球号码 +91401234567到Jerry. SIP UA将它解析做一个全球号码同时转换它到request-uri 使用的DNS中并触发请求.

  • SIP电话发送INVITE直接到网关.

  • 网关通过选择SS7 ISUP中继向PSTN侧下一个电话交换机发起呼叫.

  • 从INVITE中拨出的数字映射到ISUP IAM中。由PSTN返回ISUP address complete message (ACM)，表示中继已经创建完成.

  • 电话产生铃声，铃声传到电话开关。网关将ACM映射到183会话进度响应，该响应包含一个SDP协议，该协议表示网关将使用该协议从PSTN桥接音频.

  • 接收到183后，呼叫者的UAC开始接收从网关发送的RTP包，并向呼叫者呈现音频，这样他们知道被呼叫者在PSTN中通话进度.

  • 被叫应答后，通话结束，电话交换机向网关发送应答消息(ANM)。.

  • 然后网关在两个方向切断PSTN音频连接，并向呼叫者发送一个200 OK响应。由于RTP媒体路径已经建立，网关183中回复SDP，但对RTP连接没有改变.

  • TUAC发送一个ACK来完成SIP信令交换。由于在ISUP中没有等价的消息，网关接收ACK.

  • 呼叫者发送BYE到网关终止。网关将BYE映射到ISUP发布消息(REL)中.

  • 网关向BYE发送200OK，然后从PSTN接收RLC.

SIP - 编解码器

codec，是coder-decoder的缩写，执行两种基本的操作 −

  • 首先，它将模拟语音信号转换成等效的数字形式，以便于方便地传输.

  • 此后，它将压缩后的数字信号转换回其原始模拟形式，以便能够重新播放.

市场上有许多编解码器——一些是免费的，而另一些则需要许可。编解码器的音质不同，带宽也相应不同.

电话和网关等硬件设备支持几种不同的编解码器. 在相互交谈时，他们会协商使用哪种编解码器.

在本章中，我们将讨论一些广泛使用的流行SIP音频编解码器.

G.711

G.711是国际电联于1972年推出的一种用于数字电话的编解码器。编解码器有两个变种:A-Law在欧洲和国际电话线路中使用，u-Law在美国和日本使用。

  • G.711使用对数压缩。将每个16位的样本压缩为8位，压缩比为1:2.

  • 一个方向的比特率是64kbit /s，因此通话消耗128kbit /s.

  • G.711是PSTN网络使用的相同的编解码器，因此它提供了最好的语音质. 然而，它比其他编解码器消耗更多的带宽.

  • 它在有大量可用带宽的局域网络中工作得最好.

G.729

G.729是一种低带宽要求的编解码器，它提供了良好的音频质量.

  • 编解码器以10毫秒长的帧对音频进行编码。给定8 kHz的采样频率，10毫秒帧包含80个音频样本.

  • 编解码器算法将每帧编码为10个字节，因此在一个方向上得到的比特率为8kbit /s.

  • G.729是一个经过许可的编解码器. 想要使用这种编解码器的终端用户应该购买实现它的硬件(可以是VoIP电话或网关).

  • G.729的一个常用变体是G.729a. 它与原始的编解码器是线兼容的，但有较低的CPU要求.

G.723.1

G.723.1是国际电联宣布的一项竞赛的结果，竞赛的目的是设计一种可允许在28.8和33kbit /s调制解调器链路上通话的编解码器.

  • 我们有G.723.1的两种变体。它们都是在30毫秒(即240个样本)的音频帧上运行，但算法不同.

  • 第一个变体的比特率是6.4 kbit/s，而第二个变体是5.3 kbit/s.

  • 这两种变体的编码帧分别为24和20字节.

GSM 06.10

GSM 06.10是为GSM移动网络设计的一种编解码器. 它也被称为GSM全速率.

  • 这种变体的GSM编解码器可以免费使用，因此您经常可以在开源VoIP应用程序中找到它.

  • 编解码器对20毫秒长的音频帧(即160个样本)进行操作，并将每个帧压缩为33字节，因此得到的比特率为13 kbit/s.

SIP - B2BUA

一种背靠背的UA (B2BUA) 是SIP应用程序中的逻辑网络元素. 它是一种SIP UA，它接收SIP请求，然后重新制定请求，并将其作为新请求发送出去.

与代理服务器不同，它维护通话状态，并且必须参与在它建立的通话上发送的所有请求。B2BUA打破了SIP的端到端本质.

B2BUA – 如何工作?

一个B2BUA代理操作在两个电话终端，并将两个通信通道分成两个call legs. B2BUA 是一个UAC和UAS之间的连接. 它参与了它已经建立的呼叫两端之间的所有SIP信令. 由于对话的B2BUA可用，服务提供者可能

实现一些增值特性. 在原始的call leg中，B2BUA充当用户代理服务器(UAS)，并作为用户代理客户端(UAC)处理到目的地端的请求，处理端点之间背靠背的信令.

B2BUA维护它掌握的通话完整状态. B2BUA的每一侧作为RFC 3261中指定的标准SIP网络单元操作.

B2BUA方法

B2BUA 提供了以下方法 −

  • Call management (billing, automatic call disconnection, call transfer, etc.)

  • Network interworking (perhaps with protocol adaptation)

  • Hiding of network internals (private addresses, network topology, etc.)

通常，B2BUAs也在媒体网关中实现，桥接媒体流，以完全控制会话.

B2BUA举例

许多私有分支交换机(PBX)企业电话系统采用了B2BUA逻辑.

一些防火墙内置了ALG(应用层网关)功能，它允许防火墙授权SIP和媒体流量，同时仍然保持高水平的安全性.

B2BUA的另一种常见类型是会话边界控制器(SBC).

posted @ 2023-03-07 10:35  阿风小子  阅读(914)  评论(0)  编辑  收藏  举报