- 会话发起协议教程
- SIP - 首页
- SIP - 简介
- SIP - 网络元素
- SIP - 基本呼叫流程
- SIP - 消息传递
- SIP - 响应代码
- SIP - 头部
- SIP - 会话描述协议
- SIP - 提供/应答模型
- SIP - 移动性
- SIP - 分支
- SIP - 代理和路由
- SIP 到 PSTN
- SIP - 编解码器
- SIP - B2BUA
- SIP 有用资源
- SIP 快速指南
- SIP - 有用资源
- SIP - 讨论
SIP 快速指南
会话发起协议 - 简介
会话发起协议 (SIP) 是 VoIP 技术中最常用的协议之一。它是一种应用层协议，与其他应用层协议协同工作，以控制互联网上的多媒体通信会话。
VoIP 技术
在进一步讨论之前，让我们先了解一下关于 VoIP 的一些要点。
VoIP 是一种允许您通过互联网传递语音和多媒体（视频、图片）内容的技术。它是利用互联网随时随地进行通信最便宜的方式之一。
VoIP 的一些优势包括：
低成本
可移植性
无需额外电缆
灵活性
视频会议
对于 VoIP 通话，您只需要一台具有互联网连接功能的计算机/笔记本电脑/移动设备。下图描述了 VoIP 通话是如何进行的。
有了这些基础知识，让我们回到 SIP 上来。
SIP – 概述
以下列出了一些关于 SIP 的要点：
SIP 是一种信令协议，用于在互联网协议上创建、修改和终止多媒体会话。会话只不过是两个端点之间的一个简单呼叫。端点可以是智能手机、笔记本电脑或任何可以通过互联网接收和发送多媒体内容的设备。
SIP 是一种由 IETF（互联网工程任务组）标准定义的应用层协议。它在 **RFC 3261** 中定义。
SIP 体现了客户端-服务器架构以及从 **HTTP** 中使用 URL 和 URI，以及从 **SMTP** 中使用文本编码方案和头部样式。
SIP 利用 SDP（会话描述协议）来描述会话，并利用 RTP（实时传输协议）在 IP 网络上传输语音和视频。
SIP 可用于双方（单播）或多方（多播）会话。
其他 SIP 应用包括文件传输、即时消息、视频会议、在线游戏和流媒体多媒体分发。
SIP 在哪里适用？
基本上，SIP 是一种应用层协议。它是一种简单的网络信令协议，用于与一个或多个参与者创建和终止会话。SIP 协议设计为独立于底层传输协议，因此 SIP 应用程序可以在 TCP、UDP 或其他低层网络协议上运行。
下图描述了 SIP 在总体方案中的位置：
通常，SIP 协议用于两个或多个端点之间的互联网电话和多媒体分发。例如，一个人可以使用 SIP 发起对另一个人的电话呼叫，或者有人可以与许多参与者创建电话会议。
SIP 协议的设计非常简单，命令集有限。它也是基于文本的，因此任何人都可以阅读 SIP 会话中端点之间传递的 SIP 消息。
SIP - 网络元素
有一些实体帮助 SIP 创建其网络。在 SIP 中，每个网络元素都由一个 **SIP URI**（统一资源标识符）标识，就像一个地址一样。以下是网络元素：
- 用户代理
- 代理服务器
- 注册服务器
- 重定向服务器
- 位置服务器
用户代理
它是端点，也是 SIP 网络中最重要的网络元素之一。端点可以发起、修改或终止会话。用户代理是 SIP 网络中最智能的设备或网络元素。它可以是软电话、移动电话或笔记本电脑。
用户代理在逻辑上分为两部分：
**用户代理客户端 (UAC)** - 发送请求并接收响应的实体。
**用户代理服务器 (UAS)** - 接收请求并发送响应的实体。
SIP 基于客户端-服务器架构，其中主叫方的电话充当客户端，发起呼叫，被叫方的电话充当服务器，响应呼叫。
代理服务器
它是接收来自用户代理的请求并将其转发到另一个用户的网络元素。
基本上，代理服务器的作用很像路由器。
它具有一定的智能，可以理解 SIP 请求并借助 URI 将其发送出去。
代理服务器位于两个用户代理之间。
在源和目标之间最多可以有 70 个代理服务器。
代理服务器有两种类型：
**无状态代理服务器** - 它只是简单地转发接收到的消息。此类服务器不存储任何呼叫或事务信息。
**有状态代理服务器** - 此类代理服务器会跟踪收到的每个请求和响应，并在将来需要时可以使用它们。如果在规定时间内没有收到另一方的响应，它可以重新发送请求。
注册服务器
注册服务器接受来自用户代理的注册请求。它帮助用户在网络中进行身份验证。它将用户的 URI 和位置存储在数据库中，以帮助同一域内的其他 SIP 服务器。
请查看以下示例，该示例显示了 SIP 注册的过程。
这里，主叫方想要在 TMC 域中注册。因此，它向 TMC 的注册服务器发送 REGISTER 请求，服务器返回 200 OK 响应，因为它授权了客户端。
重定向服务器
重定向服务器接收请求并在注册服务器创建的位置数据库中查找请求的预期接收者。
重定向服务器使用数据库获取位置信息，并向用户返回 3xx（重定向响应）。我们将在本教程的后面讨论响应代码。
位置服务器
位置服务器向重定向服务器和代理服务器提供有关呼叫者可能位置的信息。
只有代理服务器或重定向服务器才能联系位置服务器。
下图描述了每个网络元素在建立会话中扮演的角色。
SIP – 系统架构
SIP 被构建为分层协议，这意味着它的行为是根据一系列相当独立的处理阶段来描述的，每个阶段之间的耦合度很松散。
SIP 的最低层是其 **语法和编码**。其编码使用增强的 **巴克斯-诺尔范式语法** (BNF) 指定。
第二层是 **传输层**。它定义了客户端如何发送请求和接收响应，以及服务器如何接收请求和发送响应。所有 SIP 元素都包含传输层。
接下来是 **事务层**。事务是由客户端事务（使用传输层）发送到服务器事务的请求，以及从服务器事务返回到客户端的所有对该请求的响应。用户代理客户端 (UAC) 完成的任何任务都是使用一系列事务进行的。**无状态代理**不包含事务层。
事务层之上的层称为事务用户。除了 **无状态代理** 之外，每个 SIP 实体都是事务用户。
SIP - 基本呼叫流程
下图显示了 SIP 会话的基本呼叫流程。
以下是上述呼叫流程的分步说明：
发送到代理服务器的 INVITE 请求负责发起会话。
代理服务器立即向呼叫方（Alice）发送 **100 Trying** 响应，以停止 INVITE 请求的重新传输。
代理服务器在位置服务器中搜索 Bob 的地址。获取地址后，它将 INVITE 请求进一步转发。
此后，Bob 生成的 **180 Ringing**（临时响应）返回给 Alice。
Bob 接起电话后，很快就会生成 **200 OK** 响应。
Bob 在收到 **200 OK** 后，会收到来自 Alice 的 **ACK**。
同时，会话建立，RTP 数据包（对话）开始从两端流动。
对话结束后，任何参与者（Alice 或 Bob）都可以发送 **BYE** 请求以终止会话。
**BYE** 直接从 Alice 到 Bob，绕过代理服务器。
最后，Bob 发送 **200 OK** 响应以确认 BYE，会话终止。
在上述基本呼叫流程中，有三个 **事务**（标记为 1、2、3）。
完整的呼叫（从 INVITE 到 200 OK）称为 **对话**。
SIP 梯形
代理如何帮助一个用户连接到另一个用户？让我们借助下图找出答案。
图中所示的拓扑称为 SIP 梯形。该过程如下：
当主叫方发起呼叫时，会向代理服务器发送 INVITE 消息。收到 INVITE 后，代理服务器尝试借助 DNS 服务器解析被叫方的地址。
获取下一条路由后，主叫方的代理服务器（Proxy 1，也称为出站代理服务器）将 INVITE 请求转发到被叫方的代理服务器，该服务器充当被叫方的入站代理服务器（Proxy 2）。
入站代理服务器联系位置服务器以获取有关被叫方注册用户地址的信息。
从位置服务器获取信息后，它将呼叫转发到其目的地。
一旦用户代理了解其地址，它们就可以绕过呼叫，即对话直接传递。
SIP - 消息传递
SIP 消息有两种类型：**请求**和**响应**。
请求的开头行包含一个定义请求的方法和一个定义请求发送位置的 Request-URI。
类似地，响应的开头行包含一个响应代码。
请求方法
**SIP 请求**是用于建立通信的代码。为了补充它们，有一些 **SIP 响应** 通常指示请求成功还是失败。
这些被称为方法的 SIP 请求使 SIP 消息能够工作。
方法可以被视为 SIP 请求，因为它们请求另一个用户代理或服务器采取特定操作。
方法分为两种类型：
核心方法
扩展方法
核心方法
如下所述，共有六种核心方法。
INVITE
INVITE 用于与用户代理发起会话。换句话说，INVITE 方法用于在用户代理之间建立媒体会话。
INVITE 可以包含呼叫者在消息体中的媒体信息。
如果 INVITE 收到成功响应 (2xx) 或已发送 ACK，则认为会话已建立。
成功的 INVITE 请求会在两个用户代理之间建立一个**对话**，该对话将持续到发送 BYE 以终止会话。
在已建立的对话中发送的 INVITE 称为**重邀 (Re-INVITE)**。
重邀用于更改会话特性或刷新对话状态。
INVITE 示例
以下代码显示了如何使用 INVITE。
INVITE sips:[email protected] SIP/2.0 Via: SIP/2.0/TLS client.ANC.com:5061;branch = z9hG4bK74bf9 Max-Forwards: 70 From: Alice<sips:[email protected]>;tag = 1234567 To: Bob<sips:[email protected]> Call-ID: [email protected] CSeq: 1 INVITE Contact: <sips:[email protected]> 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 是用于终止已建立会话的方法。这是一个 SIP 请求，可以由呼叫者或被叫方发送以结束会话。
它不能由代理服务器发送。
BYE 请求通常端到端路由，绕过代理服务器。
BYE 无法发送到正在等待的 INVITE 或未建立的会话。
REGISTER
REGISTER 请求执行用户代理的注册。此请求由用户代理发送到注册服务器。
REGISTER 请求可能会转发或代理，直到到达指定域的权威注册服务器。
它在正在注册的用户**To**头中携带 AOR（记录地址）。
REGISTER 请求包含时间段（3600 秒）。
一个用户代理可以代表另一个用户代理发送 REGISTER 请求。这称为**第三方注册**。在这里，**From**标记包含代表**To**头中标识的方提交注册的方的 URI。
CANCEL
CANCEL 用于终止未建立的会话。用户代理使用此请求取消之前发起的挂起呼叫尝试。
它可以由用户代理或代理服务器发送。
CANCEL 是一个**逐跳**请求，即它通过用户代理之间的元素，并接收下一个有状态元素生成的响应。
ACK
ACK 用于确认对 INVITE 方法的最终响应。ACK 始终沿 INVITE 的方向发送。如果 INVITE 中没有 SDP 主体（媒体特性），则 ACK 可能包含 SDP 主体。
ACK 不能用于修改已在初始 INVITE 中发送的媒体描述。
接收 ACK 的有状态代理必须确定是否应将 ACK 下游转发到另一个代理或用户代理。
对于 2xx 响应，ACK 是端到端的，但对于所有其他最终响应，当涉及有状态代理时，它以逐跳方式工作。
OPTIONS
OPTIONS 方法用于查询用户代理或代理服务器的功能并发现其当前可用性。对请求的响应列出了用户代理或服务器的功能。代理永远不会生成 OPTIONS 请求。
扩展方法
订阅 (Subscribe)
SUBSCRIBE 用于用户代理建立订阅，以便获取有关特定事件的通知。
它包含一个**Expires**头字段，指示订阅的持续时间。
时间段结束后，订阅将自动终止。
订阅在用户代理之间建立对话。
您可以在过期时间之前，通过在对话中发送另一个 SUBSCRIBE 来再次重新订阅。
用户将收到来自用户的订阅的 200 OK。
用户可以通过发送另一个 Expires 值为 0（零）的 SUBSCRIBE 方法来取消订阅。
NOTIFY
NOTIFY 用于用户代理获取特定事件的发生情况。通常，当订阅者和通知者之间存在订阅时，NOTIFY 会在对话中触发。
如果通知者接收到每个 NOTIFY，则会收到 200 OK 响应。
NOTIFY 包含一个**Event**头字段，指示事件，以及一个**subscriptionstate**头字段，指示订阅的当前状态。
NOTIFY 始终在订阅开始和结束时发送。
PUBLISH
PUBLISH 用于用户代理将事件状态信息发送到服务器。
当有多个事件信息来源时，PUBLISH 最有用。
PUBLISH 请求类似于 NOTIFY，但它不是在对话中发送的。
PUBLISH 请求必须包含**Expires**头字段和**Min-Expires**头字段。
REFER
REFER 用于用户代理将另一个用户代理推荐给访问对话的 URI。
REFER 必须包含**Refer-To**头。这是 REFER 的必填头。
REFER 可以在对话内或对话外发送。
**202 Accepted** 将触发 REFER 请求，指示其他用户代理已接受引用。
INFO
INFO 用于用户代理向与其建立了媒体会话的另一个用户代理发送呼叫信令信息。
这是一个端到端请求。
代理将始终转发 INFO 请求。
UPDATE
如果会话未建立，则 UPDATE 用于修改会话的状态。用户可以使用 UPDATE 更改编解码器。
如果会话已建立，则使用重邀来更改/更新会话。
PRACK
PRACK 用于确认已收到临时响应 (1XX) 的可靠传输。
通常，当客户端收到包含**RSeq**可靠序列号和**supported:100rel**头的临时响应时，客户端会生成 PRACK。
PRACK 在**rack**头中包含 (RSeq + CSeq) 值。
PRACK 方法适用于所有临时响应，但 100 Trying 响应除外，100 Trying 响应永远不会可靠地传输。
PRACK 可以包含消息体；它可以用于提供/回答交换。
MESSAGE
它用于使用 SIP 发送即时消息。IM 通常由参与文本对话的参与者实时交换的简短消息组成。
MESSAGE 可以在对话内或对话外发送。
MESSAGE 的内容作为**MIME**附件包含在消息体中。
通常会收到**200 OK**响应以指示消息已传递到其目的地。
SIP - 响应代码
SIP 响应是由用户代理服务器 (UAS) 或 SIP 服务器生成的消息，用于回复客户端生成的请求。它可能是正式确认，以防止 UAC 重新传输请求。
响应可能包含 UAC 需要的一些其他信息头字段。
SIP 有六种响应。
1xx 到 5xx 是从 HTTP 借用的，而 6xx 是在 SIP 中引入的。
1xx 被认为是**临时**响应，其余的是**最终**响应。
| 序号 | 功能和描述 |
|---|---|
| 1 | 1xx：临时/信息响应
信息响应用于指示**呼叫进度**。通常，响应是端到端的（100 Trying 除外）。 |
| 2 | 2xx：成功响应
此类响应旨在指示请求已被接受。 |
| 3 | 3xx：重定向响应
通常，这些类响应由重定向服务器对 INVITE 的响应发送。它们也称为重定向类响应。 |
| 4 | 4xx：客户端故障响应
客户端错误响应指示请求无法满足，因为从 UAC 端识别出了一些错误。 |
| 5 | 5xx：服务器故障响应
此类响应用于指示请求由于服务器错误而无法处理。 |
| 6 | 6xx：全局故障响应
此响应类指示服务器知道请求在任何位置尝试都会失败。因此，不应将请求发送到其他位置。 |
SIP - 头部
头是 SIP 消息的一个组成部分，用于传达有关消息的信息。它被构造为一系列头字段。
在大多数情况下，SIP 头字段遵循与 HTTP 头字段相同的规则。头字段定义为**Header: field**，其中 Header 用于表示头字段名称，field 是包含信息的标记集。每个字段由一个字段名后跟一个冒号 (":") 和字段值组成（即**field-name: field-value**）。
SIP 头 - 简洁形式
许多常见的 SIP 头字段都有一个简洁形式，其中头字段名称用单个小写字符表示。以下是一些示例：
| 头 | 简洁形式 |
|---|---|
| To | T |
| Via | V |
| Call-ID | I |
| Contact | M |
| From | F |
| Subject | S |
| Content-Length | I |
SIP 头格式
下图显示了典型 SIP 头的结构。
根据头在 SIP 中的使用方式，将其分类如下：
SIP - 会话描述协议
SDP 代表会话描述协议。它用于以网络上参与者理解的格式描述多媒体会话。根据此描述，一方决定是否加入会议或何时或如何加入会议。
会议所有者通过发送包含会话描述的多播消息（例如所有者的名称、会话的名称、编码、时间等）在网络上发布它。根据这些信息，广告的接收者做出关于参与会话的决定。
SDP 通常包含在会话发起协议（通常称为 SIP）的主体部分中。
SDP 在 RFC 2327 中定义。SDP 消息由一系列称为字段的行组成，其名称由单个小写字母缩写，并且为了简化解析，这些字段的顺序是必需的。
SDP 的目的
SDP 的目的是传达多媒体会话中媒体流的信息，以帮助参与者加入或收集特定会话的信息。
SDP 是一个简短的结构化文本描述。
它传达会话的名称和目的、媒体、协议、编解码器格式、时间和传输信息。
尝试加入的参与者会检查这些信息，并决定是否加入会话，以及如果决定加入，则如何以及何时加入会话。
该格式的条目形式为 <type> = <value>，其中 <type> 定义唯一的会话参数，<value> 为该参数提供特定值。
SDP 消息的一般形式为 -
x = parameter1 parameter2 ... parameterN
该行以单个小写字母开头，例如 x。字母和 = 之间永远没有空格，每个参数之间正好有一个空格。每个字段都有定义数量的参数。
会话描述参数
会话描述（* 表示可选）
- v = (协议版本)
- o = (所有者/创建者和会话标识符)
- s = (会话名称)
- i =* (会话信息)
- u =* (描述的 URI)
- e =* (电子邮件地址)
- p =* (电话号码)
- c =* (连接信息 - 如果包含在所有媒体中则不需要)
- b =* (带宽信息)
- z =* (时区调整)
- k =* (加密密钥)
- a =* (零个或多个会话属性行)
协议版本
v= 字段包含 SDP 版本号。由于 SDP 的当前版本为 0，因此有效的 SDP 消息始终以 v = 0 开头。
来源
o= 字段包含有关会话发起者和会话标识符的信息。此字段用于唯一标识会话。
该字段包含 -
o=<username><session-id><version><network-type><address-type>
username 参数包含发起者的登录名或主机。
session-id 参数是网络时间协议 (NTP) 时间戳或用于确保唯一性的随机数。
version 是一个数值字段，每次会话更改时都会增加，也建议为 NTP 时间戳。
network-type 对于 Internet 始终为 IN。address-type 参数对于 IPv4 或 IPv6 地址，可以是 IP4 或 IP6，以点分十进制形式或完全限定的主机名表示。
会话名称和信息
s= 字段包含会话的名称。它可以包含任意数量的非零字符。可选的 i= 字段包含有关会话的信息。它可以包含任意数量的字符。
URI
可选的 u= 字段包含一个统一资源指示符 (URI)，其中包含有关会话的更多信息
电子邮件地址和电话号码
可选的 e= 字段包含会话主机的电子邮件地址。可选的 p= 字段包含电话号码。
连接数据
c= 字段包含有关媒体连接的信息。
该字段包含 -
c =<network-type><address-type><connection-address>
network-type 参数定义为 Internet 的 IN。
address-type 定义为 IPv4 地址的 IP4 和 IPv6 地址的 IP6。
connection-address 是将发送媒体数据包的 IP 地址或主机，可以是多播或单播。
如果是多播，则 connection-address 字段包含 -
connection-address=base-multicast-address/ttl/number-of-addresses
其中 ttl 是生存时间值，number-of-addresses 指示从基本多播地址开始包含多少个连续的多播地址。
带宽
可选的 b= 字段包含有关所需带宽的信息。其形式为 -
b=modifier:bandwidth − value
时间、重复次数和时区
t= 字段包含会话的开始时间和结束时间。
t=start-time stop-time
可选的 r= 字段包含有关重复次数的信息，可以以 NTP 或天数 (d)、小时 (h) 或分钟 (m) 表示。
可选的 z= 字段包含有关时区偏移的信息。如果会话跨越从夏令时到标准时间或反之亦然的更改，则使用此字段。
媒体公告
可选的 m= 字段包含有关媒体会话类型的信息。该字段包含 -
m= media port transport format-list
media 参数可以是音频、视频、文本、应用程序、消息、图像或控制。port 参数包含端口号。
transport 参数包含使用的传输协议或 RTP 配置文件。
format-list 包含有关媒体的更多信息。通常，它包含在 RTP 音频视频配置文件中定义的媒体有效负载类型。
Example: m = audio 49430 RTP/AVP 0 6 8 99
这三种编解码器之一可用于音频媒体会话。如果打算建立三个音频通道，则将使用三个单独的媒体字段。
属性
可选的 a= 字段包含前面媒体会话的属性。此字段可用于扩展 SDP 以提供有关媒体的更多信息。如果 SDP 用户无法完全理解，则可以忽略属性字段。对于媒体字段中列出的每个媒体有效负载类型，可以有一个或多个属性字段。
SDP 中的属性可以是
- 会话级，或
- 媒体级。
会话级意味着属性列在 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 = [email protected](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 - 提供/应答模型
SDP 与 SIP 的使用在 SDP 提供/应答 RFC 3264 中给出。SIP 中的默认消息正文类型为application/sdp。
呼叫方在 SDP 中列出他们愿意接收的媒体功能，通常在 INVITE 或 ACK 中。
被叫方在其对 INVITE 的 200 OK 响应中列出其媒体功能。
SDP 的典型 SIP 使用包括以下字段：版本、来源、主题、时间、连接和一个或多个媒体和属性。
SIP 不使用主题和时间字段，但为了兼容性而包含。
在 SDP 标准中，主题字段是必需字段，必须包含至少一个字符，建议如果没有任何主题则为 s=-。
时间字段通常设置为 t = 00。SIP 使用连接、媒体和属性字段在 UA 之间建立会话。
来源字段在 SIP 中的使用有限。
会话 ID 通常在整个 SIP 会话中保持不变。
每次更改 SDP 时，版本都会递增。如果发送的 SDP 与之前发送的 SDP 相同，则版本保持不变。
由于要使用的媒体会话和编解码器类型是连接协商的一部分，因此 SIP 可以使用 SDP 指定多种替代媒体类型并选择性地接受或拒绝这些媒体类型。
提供/应答规范 RFC 3264 建议为每个媒体字段使用包含 a = rtpmap: 的属性。通过将 SDP 响应中相应媒体字段的端口号设置为零来拒绝媒体流。
示例
在以下示例中，呼叫方 Tesla 希望使用初始 INVITE 中携带的 SDP 与 Marry 建立音频和视频通话，其中包含两个可能的音频编解码器和一个视频编解码器 -
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
编解码器由 RTP/AVP 配置文件编号 97、98 引用。
被叫方 Marry 接听电话，为第一个媒体字段选择第二个编解码器，并拒绝第二个媒体字段，只希望 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
如果此音频通话不可接受，则 Tom 将发送 ACK 然后发送 BYE 以取消通话。否则，将建立音频会话并交换 RTP 数据包。
如本示例所示，除非保持媒体字段的数量和顺序，否则呼叫方无法确定被叫方接受和拒绝了哪些媒体会话。
以下各节总结了提供/应答规则。
生成提供规则
SDP 提供必须包含所有必需的 SDP 字段（包括 v=、o=、s=、c= 和 t=）。这些是 SDP 中的必填字段。
它通常包含一个媒体字段 (m=)，但并非必须包含。媒体行包含按优先级顺序列出的所有编解码器。唯一的例外是，如果端点支持大量编解码器，则应列出最有可能被接受或最优选的编解码器。不同的媒体类型包括音频、视频、文本、MSRP、BFCP 等。
生成应答规则
对提供的 SDP 应答必须根据以下规则构建 -
应答必须具有与应答相同数量的 m= 行，并且顺序相同。
可以通过将端口号设置为 0 来拒绝单个媒体流。
通过发送非零端口号来接受流。
每个媒体类型列出的有效负载必须是提供中列出的有效负载的子集。
对于动态有效负载，每个方向不需要使用相同的动态有效负载编号。通常，只选择一个有效负载。
修改会话规则
任何一方都可以发起另一个提供/应答交换来修改会话。修改会话时，必须遵循以下规则 -
来源 (o=) 行版本号必须与上次发送的版本号相同，这表示此 SDP 与之前的交换相同，或者可以递增 1，这表示必须解析的新 SDP。
提供必须包含所有现有的媒体行，并且必须按相同的顺序发送。
可以将其他媒体流添加到 m= 行列表的末尾。
可以通过将端口号设置为 0 来删除现有媒体流。此媒体行必须保留在 SDP 中，以及此会话的所有未来提供/应答交换中。
呼叫保持
通话中的一方可以暂时将另一方置于保持状态。这可以通过发送一个与原始 INVITE 的 SDP 相同的 INVITE 来完成，但其中包含a = sendonly属性。
通过发送另一个包含a = sendrecv属性的 INVITE 使通话再次处于活动状态。下图显示了呼叫保持的呼叫流程。
SIP - 移动性
个人移动性是指能够在多个设备上拥有一个恒定标识符的能力。SIP 使用 REGISTER 方法支持基本的个人移动性，该方法允许移动设备更改其 IP 地址和连接到 Internet 的连接点，并且仍然能够接收来电。
SIP 还可以支持服务移动性 - 用户在移动时保持相同服务的能力
移交期间的 SIP 移动性（呼叫前）
设备通过简单的SIP注册将其联系URI与记录地址绑定。根据设备IP地址，注册会自动授权此信息在SIP网络中更新。
在切换过程中，用户代理在不同的运营商之间路由，它必须再次使用Contact作为AOR向另一个服务提供商注册。
例如，让我们以以下呼叫流程为例。UA临时收到了一个新的SIP URI和一个新的服务提供商。然后，UA执行双重注册 -
第一次注册是向新的服务运营商进行的，它将设备的Contact URI与新服务提供商的AOR URI绑定。
第二个REGISTER请求路由回原始服务提供商，并将新服务提供商的AOR作为Contact URI提供。
如呼叫流程后面所示，当请求进入原始服务提供商的网络时，INVITE将重定向到新服务提供商，然后该提供商将呼叫路由到用户。
对于第一次注册，包含设备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:[email protected]> From: Tom <sip:[email protected]>;tag = 72d65a24 Call-ID: [email protected] CSeq: 1 REGISTER Contact: <sip:[email protected]: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:[email protected]> From: Tom <sip:[email protected]>;tag = 45375 Call-ID:[email protected] CSeq: 6421 REGISTER Contact: <sip:[email protected]> Content-Length: 0
上图中显示的第一个INVITE将发送到sip:registrar2.in；第二个INVITE将发送到sip: sip:[email protected]，它将转发到sip:[email protected]。它到达Tom并允许建立会话。定期需要刷新这两个注册。
通话期间的移动性（重新邀请）
用户代理可能会在会话期间更改其IP地址，因为它从一个网络切换到另一个网络。基本SIP支持此场景，因为对话中的重新邀请可用于更新Contact URI和更改SDP中的媒体信息。
请查看下图中提到的呼叫流程。
这里，Tom检测到一个新网络，
使用DHCP获取新的IP地址，以及
执行重新邀请以允许信号和媒体流到新的IP地址。
如果UA可以从两个网络接收媒体，则中断可以忽略不计。如果不是这种情况，则可能会丢失一些媒体数据包，导致通话略微中断。
重新邀请将显示如下 -
INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a Max-Forwards: 70 To: <sip:[email protected]> From: sip:[email protected];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
重新邀请包含Bowditch的新IP地址（在Via和Contact头字段中）和SDP媒体信息。
通话中移动性（带替换头）
在通话中移动性中，必须更改实际路由集（SIP消息必须遍历的SIP代理集）。我们不能在通话中移动性中使用重新邀请
例如，如果代理对于NAT遍历是必需的，则必须更改Contact URI - 必须创建一个新的对话。因此，它必须发送一个带有Replaces头的新的INVITE，该头标识现有的会话。
注意 - 假设A和B都在通话中，如果A收到另一个INVITE（例如来自C）并带有替换头（应与现有对话匹配），则A必须接受INVITE并终止与B的会话并将所有资源转移到新形成的对话。
呼叫流程如下图所示。它类似于之前使用重新邀请的呼叫流程，除了当接受带有Replaces的INVITE时，会自动生成BYE以终止现有对话。
以下是此场景中需要注意的要点 -
Tom和Jerry之间现有的对话包括旧的已访问代理服务器。
使用新无线网络的新对话需要包含新的已访问代理服务器。
因此，Tom发送了一个带有Replaces的INVITE，它创建了一个新的对话，该对话包括新的已访问代理服务器，但不包括旧的已访问代理服务器。
当Jerry接受INVITE时，会自动发送BYE以终止通过旧的已访问代理服务器（现在不再参与会话）路由的旧对话。
生成的媒体会话是使用INVITE中SDP中的Tom的新IP地址建立的。
服务移动性
SIP中的服务可以在代理或UA中提供。除非用户的设备配置相同且具有相同的服务，否则提供服务移动性和个人移动性可能具有挑战性。
SIP可以轻松支持互联网上的服务移动性。当连接到互联网时，配置为使用印度一组代理的UA仍然可以在欧洲漫游时使用这些代理。它不会对媒体会话的质量产生任何影响，因为媒体始终在两个UA之间直接流动，并且不会遍历SIP代理服务器。
端点驻留服务仅在端点连接到互联网时可用。如果端点暂时丢失了其互联网连接，则在端点中实现的呼叫转发等终止服务将失败。因此，某些服务是在网络中使用SIP代理服务器实现的。
SIP - 分支
有时代理服务器将单个SIP呼叫转发到多个SIP端点。此过程称为分叉。这里，单个呼叫可以同时响铃多个端点。
使用SIP分叉，您可以同时让您的办公电话和您的软电话或手机上的SIP电话响铃，让您可以轻松地从任何设备接听电话。
通常，在办公室里，假设老板无法接听电话或不在，SIP分叉允许秘书接听他分机的电话。
如果存在有状态代理，则分叉将成为可能，因为它需要执行并响应它收到的许多响应。
我们有两种类型的分叉 -
- 并行分叉
- 顺序分叉
并行分叉
在这种情况下，代理服务器将同时将INVITE分叉到两个设备（UA2、UA3）。这两个设备都将生成180响铃，并且接收呼叫的设备将生成200 OK。首先到达发起者的响应（假设UA2）将与UA2建立会话。对于另一个响应，将触发CANCEL。
如果发起者同时收到两个响应，则根据q值，它将转发响应。
顺序分叉
在这种情况下，代理服务器将将INVITE分叉到一个设备（UA2）。如果UA2此时不可用或繁忙，则代理服务器将将其分叉到另一个设备（UA3）。
分支 ID 和标签
分支ID帮助代理将响应与分叉请求匹配。如果没有分支ID，代理服务器将无法理解分叉响应。分支ID将在Via头中可用。
标签由UAC用于区分来自不同UAS的多个最终响应。UAS无法解决请求是否已被分叉。因此，它需要添加一个标签。
如果代理生成最终响应，则代理也可以添加标签，它们永远不会将其插入到它们转发的请求或响应中。
可能单个请求也会被多个代理服务器分叉。因此，将进行分叉的代理应将其自己的唯一ID添加到它创建的分支中。
呼叫段和呼叫ID
呼叫段是指两个用户代理之间的一对一信令关系。呼叫ID是SIP消息中携带的唯一标识符，用于指代呼叫。呼叫是呼叫段的集合。
UAC通过发送INVITE开始。由于分叉，它可能会从不同的UA收到多个200 OK。每个对应于同一呼叫内的不同呼叫段。
因此，呼叫是一组呼叫段。呼叫段指的是UA之间的端到端连接。
呼叫段两个方向的CSeq空间是独立的。在一个方向内，每个事务的序列号都会递增。
语音邮件
语音邮件现在对于企业用户来说非常普遍。这是一个电话应用程序。当被叫方不可用或无法接听电话时，它就会出现，PBX将通知呼叫方留下语音留言。
如果被叫方的号码无法接通，用户代理将获得3xx响应或重定向到语音邮件服务器。但是，需要某种SIP扩展来指示语音邮件系统使用哪个邮箱——也就是说，播放哪个问候语以及将录制的消息存储在哪里。有两种方法可以实现这一点 -
使用SIP头字段扩展
使用Request-URI来表示此信息
假设用户sip:[email protected]在sip:voicemail.tutorialspoint.com处有一个提供语音邮件的语音邮件系统，当它转发到语音邮件服务器时，INVITE的Request-URI可能如下所示 -
sip:voicemail.tutorialspoint.com;target = sip:[email protected];cause = 486
下图显示了Request-URI如何携带邮箱标识符和原因（此处为486）。
SIP - 代理和路由
众所周知，代理服务器可以是无状态的或有状态的。在这里，在本章中，我们将更多地讨论代理服务器和SIP路由。
无状态代理服务器
无状态代理服务器只是转发它接收到的消息。这种服务器不存储任何呼叫或事务信息。
- 无状态代理在转发SIP请求后会忘记该请求。
- 通过无状态代理，事务将很快。
有状态代理服务器
有状态代理服务器会跟踪它接收到的每个请求和响应。如果需要，它可以在将来使用存储的信息。如果它没有从另一端收到响应，它可以重新传输请求。
有状态代理在转发请求后会记住该请求，因此它们可以将其用于高级路由。有状态代理维护事务状态。事务意味着事务状态，而不是呼叫状态。
与无状态代理相比，有状态代理的事务速度并不快。
有状态代理可以在需要时分叉和重新传输。（例如：呼叫转发忙，例如）。
Via 和 Record-route
Record-Route
Record-Route头由希望位于同一呼叫ID后续请求路径中的代理插入请求中。然后，用户代理使用它来路由后续请求。
Via
Via头由服务器插入请求中，以检测循环并帮助响应找到返回客户端的路径。这仅有助于响应到达其目的地。
UA本身在发送请求时生成并将其自己的地址添加到Via头字段中。
转发请求的代理会在Via头字段列表的顶部添加一个包含其自身地址的Via头字段。
生成对请求的响应的代理或UA会按顺序将请求中的所有Via头字段复制到响应中，然后将响应发送到顶部Via头字段中指定的地址。
接收响应的代理会检查顶部Via头字段并匹配其自身地址。如果不匹配，则会丢弃该响应。
然后删除顶部Via头字段，并将响应转发到下一个Via头字段中指定的地址。
Via头字段包含协议名称、版本号和传输（SIP/2.0/UDP、SIP/2.0/TCP等），并包含端口号和参数，如接收、rport、分支。
如果UA或代理从与顶部Via头字段中指定的地址不同的地址接收请求，则会将接收标签添加到Via头字段中。
UA和代理会向Via头字段添加分支参数，该参数计算为Request-URI、To、From、Call-ID和CSeq编号的哈希函数。
SIP 到 PSTN
SIP（软电话）和PSTN（旧电话）都是不同的网络，使用不同的语言。因此，我们需要一个翻译器（此处为网关）在这两个网络之间进行通信。
让我们举一个例子来说明SIP电话如何通过PSTN网关拨打PSTN电话。
在这个例子中，Tom (sip:[email protected])是SIP电话，Jerry使用全球电话号码+91401234567。
通过网关从SIP到PSTN
下图显示了从SIP到PSTN通过网关的呼叫流程。
以下是从SIP电话拨打PSTN电话时发生的所有过程的分步说明。
首先，(Tom)SIP电话拨打全球号码+91401234567以联系Jerry。SIP用户代理将其识别为全球号码，并使用DNS将其转换为请求URI并触发请求。
SIP电话直接向网关发送INVITE请求。
网关通过选择PSTN中下一个电话交换机的SS7 ISUP中继来发起PSTN呼叫。
来自INVITE的拨号数字被映射到ISUP IAM中。ISUP地址完成消息(ACM)由PSTN发送回来，指示中继已建立。
电话产生铃声并将其发送到电话交换机。网关将ACM映射到包含SDP的183会话进度响应，该SDP指示网关将用于桥接来自PSTN的音频的RTP端口。
在收到183后，主叫方的UAC开始接收来自网关发送的RTP数据包，并将音频呈现给主叫方，以便他们知道被叫方正在PSTN中进行呼叫。
当被叫方接听电话时，呼叫完成，这会导致电话交换机向网关发送应答消息(ANM)。
然后，网关双向切断PSTN音频连接，并向主叫方发送200 OK响应。由于RTP媒体路径已建立，网关在183中回复SDP，但不会对RTP连接造成任何更改。
UAC发送ACK以完成SIP信令交换。由于ISUP中没有等效的消息，网关会吸收ACK。
主叫方向网关发送BYE以终止呼叫。网关将BYE映射到ISUP释放消息(REL)。
网关向BYE发送200OK并从PSTN接收RLC。
SIP - 编解码器
编解码器（codec），是编码器-解码器的简称，执行两个基本操作：
首先，它将模拟语音信号转换为等效的数字形式，以便于传输。
然后，它将压缩后的数字信号转换回其原始的模拟形式，以便于播放。
市场上有很多编解码器可用——有些是免费的，而另一些则需要许可。编解码器的音质和带宽会有所不同。
诸如电话和网关之类的硬件设备支持几种不同的编解码器。在相互通信时，它们会协商将使用哪个编解码器。
在本章中，我们将讨论一些广泛使用的流行的SIP音频编解码器。
G.711
G.711是由ITU于1972年为数字电话应用而引入的编解码器。该编解码器有两个变体：A-Law用于欧洲和国际电话线路，uLaw用于美国和日本。
G.711使用对数压缩。它将每个16位样本压缩为8位，因此实现了1:2的压缩比。
一个方向的比特率为64 kbit/s，因此一个呼叫消耗128 kbit/s。
G.711是PSTN网络使用的相同编解码器，因此它提供了最佳的语音质量。但是，它比其他编解码器消耗更多的带宽。
它最适合于我们拥有大量可用带宽的局域网。
G.729
G.729是一种带宽要求低的编解码器，它提供了良好的音频质量。
该编解码器以10毫秒长的帧对音频进行编码。给定8 kHz的采样频率，一个10毫秒的帧包含80个音频样本。
编解码器算法将每个帧编码为10个字节，因此结果比特率为一个方向的8 kbit/s。
G.729是一种许可编解码器。想要使用此编解码器的最终用户应该购买实现它的硬件（无论是VoIP电话还是网关）。
G.729的一个常用变体是G.729a。它与原始编解码器兼容，但CPU要求更低。
G.723.1
G.723.1是ITU宣布的一场竞赛的结果，其目的是设计一种能够通过28.8和33 kbit/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
回传用户代理（B2BUA）是SIP应用程序中的一个逻辑网络元素。它是一种SIP UA，接收SIP请求，然后重新制定请求，并将其发送出去作为新的请求。
与代理服务器不同，它维护对话状态，并且必须参与在其建立的对话上发送的所有请求。B2BUA破坏了SIP的端到端特性。
B2BUA – 工作原理？
B2BUA代理在电话呼叫的两个端点之间运行，并将通信通道划分为两个呼叫支路。B2BUA是UAC和UAS的串联。它参与呼叫双方之间所有已建立的SIP信令。作为对话服务提供商提供的B2BUA可能会实现一些增值功能。
在发起呼叫的支路上，B2BUA充当用户代理服务器（UAS），并将请求作为用户代理客户端（UAC）处理到目标端，处理端点之间的背靠背信令。
B2BUA维护其处理的呼叫的完整状态。B2BUA的每一侧都作为RFC 3261中指定的标准SIP网络元素运行。
B2BUA的功能
B2BUA提供以下功能：
呼叫管理（计费、自动呼叫断开、呼叫转移等）
网络互通（可能需要协议适配）
隐藏网络内部结构（私有地址、网络拓扑等）
通常，B2BUA也实现在媒体网关中，以桥接媒体流，从而完全控制会话。
B2BUA示例
许多私有分支交换机（PBX）企业电话系统都集成了B2BUA逻辑。
一些防火墙内置了ALG（应用层网关）功能，允许防火墙授权SIP和媒体流量，同时仍保持高安全级别。
另一种常见的B2BUA类型称为会话边界控制器（SBC）。