阅读(2384) (0)

SIP快速指南

2016-12-27 10:01:23 更新

会话发起协议 - 简介

会话发起协议(SIP)是在VoIP技术中使用的最常见的协议之一。 它是一种应用层协议,与其他应用层协议协同工作,以控制Internet上的多媒体通信会话。

VoIP技术

在进一步讨论之前,让我们首先了解有关VoIP的几点。

  • VOIP是一种允许您通过互联网提供语音和多媒体(视频,图片)内容的技术。 它是任何时间,任何地方与互联网的可用性最便宜的沟通方式之一。

  • VOIP的一些优势包括 -

    • 低成本

    • 可移植性

    • 无额外电缆

    • 灵活性

    • 视频会议

  • 对于VOIP呼叫,您需要的是一台带有互联网连接的电脑/笔记本电脑/手机。 下图描述了VoIP呼叫如何发生。

VoIP

有了这个基础,让我们回到SIP。

SIP - 概述

以下是关于SIP的几点注意事项 -

  • SIP是用于通过因特网协议创建,修改和终止多媒体会话的信令协议。 会话不过是两个端点之间的简单调用。 端点可以是智能电话,膝上型计算机或可以通过因特网接收和发送多媒体内容的任何设备。

  • SIP是由IETF(因特网工程任务组)标准定义的应用层协议。 它在 RFC 3261 中定义。

  • SIP体现了客户端 - 服务器体系结构以及来自 HTTP 的URL和URI以及来自 SMTP 的文本编码方案和标题样式的使用。

  • SIP利用SDP(会话描述协议)的帮助,SDP描述了用于通过IP网络传递语音和视频的会话和RTP(实时传输协议)。

  • SIP可用于双方(单播)或多方(多播)会话。

  • 其他SIP应用包括文件传输,即时消息,视频会议,在线游戏和蒸汽多媒体分发。

SIP适合在哪里?

基本上SIP是一种应用层协议。 它是用于创建和终止与一个或多个参与者的会话的简单网络信令协议。 SIP协议被设计为独立于底层传输协议,因此SIP应用可以在TCP,UDP或其他低层网络协议上运行。

下图说明了SIP在事物的一般方案中的位置 -

SIP Layers

通常,SIP协议用于两个或更多个端点之间的互联网电话和多媒体分发。 例如,一个人可以使用SIP发起到另一个人的电话呼叫,或者某人可以与许多参与者创建电话会议。

SIP协议被设计为非常简单,具有有限的命令集。 它也是基于文本的,因此任何人都可以读取在SIP会话中的端点之间传递的SIP消息。

SIP - 网络元素

有一些实体帮助SIP创建其网络。 在SIP中,每个网络元件由类似地址的 SIP URI (统一资源标识符)标识。 以下是网络元素 -

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

用户代理

它是端点和SIP网络的最重要的网络元件之一。 端点可以启动,修改或终止会话。 用户代理是SIP网络中最智能的设备或网络元件。 它可以是软电话,移动电话或笔记本电脑。

用户代理在逻辑上分为两个部分 -

  • 用户代理客户端(UAC) - 发送请求并接收响应的实体。

  • 用户代理服务器(UAS) - 接收请求并发送响应的实体。

SIP基于客户端 - 服务器架构,其中呼叫者的电话充当发起呼叫的客户端,并且被叫者的电话充当响应呼叫的服务器。

代理服务器

它是从用户代理接收请求并将其转发给另一个用户的网络元素。

  • 基本上代理服务器的作用就像一个路由器。

  • 它具有一些智能来理解SIP请求并且在URI的帮助下向前发送它。

  • 代理服务器位于两个用户代理之间。

  • 源和目标之间最多可以有70个代理服务器。

有两种类型的代理服务器 -

  • 无状态代理服务器 - 它仅转发接收的消息。 这种类型的服务器不存储呼叫或事务的任何信息。

  • 状态代理服务器 - 此类型的代理服务器会跟踪收到的每个请求和响应,如果需要,将来可以使用它。 如果没有来自另一方的响应,它可以重传请求。

注册服务器

注册服务器接受来自用户代理的注册请求。 它帮助用户在网络中验证自己。 它将URI和用户的位置存储在数据库中,以帮助同一域中的其他SIP服务器。

请看下面的示例,显示SIP注册的过程。

SIP Registration Example

这里呼叫者想要注册到TMC域。 因此它向TMC的注册服务器发送注册请求,并且服务器在授权客户端时返回200 OK响应。

重定向服务器

重定向服务器接收请求并在由注册器创建的位置数据库中查找请求的预期接收者。

重定向服务器使用数据库获取位置信息,并以3xx(重定向响应)向用户作出响应。 我们将在本教程的后面讨论响应代码。

位置服务器

位置服务器向重定向和代理服务器提供关于呼叫者可能的位置的信息。

只有代理服务器或重定向服务器可以联系位置服务器。

下图描述了每个网络元素在建立会话时所扮演的角色。

Location Server

SIP - 系统架构

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

System Architecture
  • SIP的最低层是其语法和编码 其编码使用扩充的背景 - 诺尔表单语法(BNF)指定。

  • 第二层是传输层 它定义了客户端如何发送请求和接收响应,以及服务器如何通过网络接收请求和发送响应。 所有SIP元素都包含传输层。

  • 接下来是交易层 事务是由客户机事务(使用传输层)发送到服务器事务的请求,以及从服务器事务发送回客户机的对该请求的所有响应。 用户代理客户端(UAC)完成的任何任务都使用一系列事务进行。 无状态代理不包含事务层。

  • 交易层上方的图层称为交易使用者。 除了无状态代理,每个SIP实体都是事务用户。

SIP - 基本呼叫流

下图显示了SIP会话的基本呼叫流程。

SIP Call Flow

下面给出了上述调用流程的逐步解释 -

  • 发送到代理服务器的INVITE请求负责启动会话。

  • 代理服务器立即向呼叫者(Alice)发送 100 Trying 响应以停止INVITE请求的重传。

  • 代理服务器在位置服务器中搜索Bob的地址。 在获得地址之后,它进一步转发INVITE请求。

  • 此后,由Bob产生的 180响铃(临时响应)被返回给Alice。

  • Bob在接听电话后立即生成 200 OK 响应。

  • Bob收到 200 OK 时,Bob会收到来自Alice的 ACK

  • 同时,会话建立并且RTP分组(对话)开始从两端流动。

  • 在对话之后,任何参与者(Alice或Bob)可以发送 BYE 请求以终止会话。

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

  • 最后,Bob发送 200 OK 响应以确认BYE并且会话终止。

  • 在上述基本呼叫流程中,三个事务(标记为1,2,3)可用。

完整的呼叫(从INVITE到200 OK)称为 Dialog

SIP梯形

代理如何帮助将一个用户与另一个用户连接? 让我们在下面的图的帮助下找出。

SIP Trapezoid

图中所示的拓扑称为SIP梯形。 该过程如下进行 -

  • 当呼叫者发起呼叫时,向代理服务器发送INVITE消息。 在接收到INVITE时,代理服务器尝试在DNS服务器的帮助下解析被调用者的地址。

  • 在获得下一个路由之后,呼叫者的代理服务器(代理1,也称为出站代理服务器)将INVITE请求转发到被叫者的代理服务器,该代理服务器充当被叫者的入站代理服务器(代理2)。

  • 入站代理服务器与位置服务器联系以获取有关用户注册的被叫方地址的信息。

  • 在从位置服务器获取信息之后,它将呼叫转发到其目的地。

  • 一旦用户代理知道他们的地址,他们可以绕过呼叫,即对话直接传递。

SIP - 消息传递

SIP消息有两种类型 - 请求响应

  • 请求的开始行包含定义请求的方法,以及定义请求发送位置的Request-URI。

  • 类似地,响应的开始行包含响应代码。

请求方法

SIP请求是用于建立通信的代码。 为了补充它们,存在 SIP响应,其通常指示请求是成功还是失败。

这些称为方法的SIP请求使得SIP消息可行。

  • 方法可以被认为是SIP请求,因为它们请求由另一个用户代理或服务器采取的特定动作。

  • 方法分为两种类型 -

    • 核心方法

    • 扩展方法

核心方法

下面讨论六种核心方法。

邀请

INVITE用于发起与用户代理的会话。 换句话说,INVITE方法用于在用户代理之间建立媒体会话。

  • INVITE可以在消息正文中包含呼叫者的媒体信息。

  • 如果INVITE已经接收到成功响应(2xx)或者已经发送了ACK,则认为会话被建立。

  • Invite
  • 成功的INVITE请求在两个用户代理之间建立对话,其继续,直到发送BYE以终止会话。

  • 在已建立的对话中发送的INVITE被称为 re-INVITE

  • Re-INVITE用于更改会话特征或刷新对话框的状态。

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是用于终止已建立的会话的方法。 这是一个SIP请求,可以由主叫方或被叫方发送以结束会话。

  • 它不能由代理服务器发送。

  • BYE请求通常绕过代理服务器端到端路由。

  • BYE不能发送到挂起的INVITE或未建立的会话。

寄存器

REGISTER请求执行用户代理的注册。 此请求由用户代理发送到注册服务器。

  • REGISTER请求可以被转发或代理,直到它到达指定域的权威注册器。

  • 它在正在注册的用户的 To 头中携带AOR(记录地址)。

  • REGISTER请求包含时间段(3600秒)。

  • 一个用户代理可以代表另一个用户代理发送REGISTER请求。 这称为第三方注册 这里, From 标签包含代表 To 标头中标识的一方提交注册的一方的URI。

取消

CANCEL用于终止未建立的会话。 用户代理使用此请求取消之前发起的待处理呼叫尝试。

  • 它可以由用户代理或代理服务器发送。

  • CANCEL是逐跳请求,即,它通过用户代理之间的元素并接收由下一个有状态元素产生的响应。

Hop By Hop

ACK

ACK用于确认对INVITE方法的最终响应。 ACK总是向着INVITE的方向。如果在INVITE中不可用,ACK可以包含SDP主体(媒体特性)。

SDP Ack
  • ACK可以不被用于修改已经在初始INVITE中发送的媒体描述。

SDP Acknowledgement
  • 接收ACK的状态代理必须确定ACK是否应当向下游转发到另一个代理或用户代理。

  • 对于2xx响应,ACK是端到端的,但是对于所有其他最终响应,当涉及状态代理时,其工作在逐跳基础上。

选项

OPTIONS方法用于向用户代理或代理服务器查询其功能,并发现其当前可用性。 对请求的响应列出了用户代理或服务器的功能。 代理永远不会生成OPTIONS请求。

扩展方法

订阅

用户代理使用SUBSCRIBE来建立订阅,以获得关于特定事件的通知。

  • 它包含一个 Expires 头字段,用于指示订阅的持续时间。

  • 在该时间段过去之后,订阅将自动终止。

  • 订阅在用户代理之间建立对话。

  • 您可以在到期时间之前在对话框中发送另一个SUBSCRIBE再次重新订阅。

  • 将收到来自用户的订阅的200 OK。

  • 用户可以通过发送另一个SUBSCRIBE方法取消订阅,Expires值为0(零)。

Example Subscribe

通知

NOTIFY用于由用户代理获取特定事件的发生。 通常,当订阅者和通知者之间存在订阅时,NOTIFY将在对话框中触发。

  • 每个NOTIFY将得到200 OK响应,如果它被通知器接收。

  • NOTIFY包含指示事件的 Event 头字段和指示订阅当前状态的 subscriptionstate 头字段。

  • NOTIFY总是在订阅的开始和终止时发送。

发布

PUBLISH由用户代理用于向服务器发送事件状态信息。

Publish
  • 当有多个事件信息来源时,PUBLISH是最有用的。

  • PUBLISH请求类似于NOTIFY,除了它不是在对话框中发送。

  • PUBLISH请求必须包含 Expires 头字段和 Min-Expires 头字段。

参考

REFER由用户代理使用来引用另一个用户代理来访问对话框的URI。

  • REFER必须包含 Refer-To 标题。 这是REFER的必需标题。

  • REFER可以在对话框内部或外部发送。

  • A 202 Accepted 将触发REFER请求,指示其他用户代理已接受引用。

信息

INFO由用户代理用来向与其建立媒体会话的另一用户代理发送呼叫信令信息。

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

  • 代理将始终转发INFO请求。

更新

如果会话未建立,UPDATE用于修改会话的状态。 用户可以使用UPDATE更改编解码器。

Update

如果建立了会话,则使用重新邀请来改变/更新会话。

PRACK

PRACK用于确认接收到临时响应(1XX)的可靠传输。

  • 通常,当客户端接收到包含 RSeq 可靠序列号和支持的:100rel 头部的临时响应时,PRACK就会生成。

  • PRACK在 rack 标题中包含(RSeq&amp; plus; CSeq)值。

  • PRACK方法适用于所有临时响应,除了100 Trying响应,其从未可靠地传送。

  • PRACK可以包含消息体; 它可以用于提供/应答交换。

信息

它用于使用SIP发送即时消息。 IM通常包括从事文本会话的参与者实时交换的短消息。

Message
  • MESSAGE可以在对话框内或对话框外发送。

  • MESSAGE的内容作为 MIME 附件在邮件正文中传送。

  • 通常接收到 200 OK 响应以指示消息已在其目的地传送。

SIP - 响应代码

SIP响应是由用户代理服务器(UAS)或SIP服务器生成的用于回复由客户端生成的请求的消息。 它可以是防止UAC重传请求的正式确认。

  • 响应可以包含UAC所需的信息的一些附加报头字段。

  • SIP有六个响应。

  • 1xx到5xx已从HTTP借用,6xx已在SIP中引入。

  • 1xx被认为是临时响应,其余的是最终响应。

S.No。 功能&amp; 描述
1 1xx: Provisional/Informational Responses

信息响应用于指示呼叫进度 通常响应是端到端的(除了100 Trying)。

2 2xx: Success Responses

这类响应用于指示请求已被接受。

3 3xx: Redirect Responses

通常这些类响应由重定向服务器响应INVITE发送。 它们也称为重定向类响应。

4 4xx: Client Failure Responses

客户端错误响应指示无法满足请求,因为从UAC侧识别出一些错误。

5 5xx: Server Failure Response

此类响应用于指示由于服务器错误而无法处理请求。

6 6xx: Global Failure Response

此响应类指示服务器知道请求在尝试的任何地方都将失败。 因此,请求不应发送到其他位置。

SIP - 报头

报头是传达关于消息的信息的SIP消息的组件。 它被构造为头字段序列。

SIP头字段在大多数情况下遵循与HTTP头字段相同的规则。 标题字段定义为 Header:字段,其中Header用于表示标题字段名称,字段是包含信息的标记集合。 每个字段包含一个字段名称,后跟冒号(“:")和字段值(即字段名称:字段值)。

SIP头 - 紧凑型

许多常见的SIP报头字段具有紧凑形式,其中报头字段名称由单个小写字符表示。 一些例子如下 -

标题 紧凑型
To T
Via V
Call-ID I
Contact M
From F
Subject S
Content-Length I

SIP头格式

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

SIP Header Format

根据其在SIP中的用法,标题被分类如下:

SIP - 会话描述协议

SDP代表会话描述协议。 它用于描述参与者通过网络理解的格式的多媒体会话。 根据该描述,一方决定是否加入会议或者何时或如何加入会议。

  • 会议的所有者通过发送包含会话描述的多播消息在网络上广告它。 所有者的名称,会话的名称,编码,时间等。根据这些信息,广告的接收者做出关于参与会话的决定。

  • SDP通常包含在通常称为SIP的会话发起协议的主体部分中。

  • SDP在RFC 2327中定义。SDP消息由一系列称为字段的行组成,其名称由单个小写字母缩写,并且以所需顺序来简化解析。

SDP的目的

SDP的目的是在多媒体会话中传达关于媒体流的信息,以帮助参与者加入或收集特定会话的信息。

  • SDP是一个短结构化文本描述。

  • 它传达会话的名称和目的,媒体,协议,编解码格式,定时和传输信息。

  • 临时参与者检查这些信息并决定是否加入会话,以及如果它决定如何以及何时加入会话。

  • 格式具有< type>形式的条目。 =< value>,其中< type> 定义唯一会话参数,并且< value> 提供该参数的特定值。

  • SDP消息的一般形式是 -

    SDP消息的一般形式是 - ...

  • 行以单个小写字母开头,例如x。 字母和=之间从不存在任何空格,每个参数之间只有一个空格。 每个字段都有一定数量的参数。

会话描述参数

会话描述(*表示可选)

  • v = (protocol version)
  • o = (owner/creator and session identifier)
  • s = (session name)
  • i =* (session information)
  • u =* (URI of description)
  • e =* (email address)
  • p =* (phone number)
  • c =* (connection information - not required if included in all media)
  • b =* (bandwidth information)
  • z =* (time zone adjustments)
  • k =* (encryption key)
  • a =* (zero or more session attribute lines)

协议版本

v =字段包含SDP版本号。 因为SDP的当前版本是0,所以有效的SDP消息将始终以v = 0开始。

起源

o =字段包含有关会话发起者和会话标识符的信息。 此字段用于唯一标识会话。

  • 该字段包含 -

    o =< username>< session-id>< version>< network-type>< address-type>

  • 用户名参数包含发起方的登录名或主机。

  • session-id 参数是用于确保唯一性的网络时间协议(NTP)时间戳或随机数。

  • 版本是一个数字字段,对于会话的每个更改都会增加,也建议为NTP时间戳。

  • 对于Internet,网络类型始终为IN。 address-type参数为IPv4或IPv6地址的IP4或IP6(点分十进制形式或完全限定的主机名)。

会话名称和信息

s =字段包含会话的名称。 它可以包含任何非零数字的字符。 可选的i =字段包含有关会话的信息。 它可以包含任意数量的字符。

URI

可选的u =字段包含具有关于会话的更多信息的统一资源指示符(URI)

电子邮件地址和电话号码

可选的e =字段包含会话主机的电子邮件地址。 可选的p =字段包含电话号码。

连接数据

c =字段包含有关介质连接的信息。

  • 该字段包含 -

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

  • 对于Internet, network-type 参数定义为IN。

  • 地址类型定义为IPv4地址的IP4和IPv6地址的IP6。

  • connection-address 是将发送媒体数据包的IP地址或主机,可以是多播或单播。

  • 如果组播,则connection-address字段包含 -

    connection-address = base-multicast-address / ttl / number-of-addresses

  • 其中 ttl 是生存时间值,并且地址数量指示从基本多播地址开始包括多少个连续的多播地址。

带宽

可选b =字段包含有关所需带宽的信息。 它的形式 -

b = modifier:bandwidth - value

时间,重复次数和时区

t =字段包含会话的开始时间和停止时间。

t =开始时间停止时间

可选的r =字段包含有关可以在NTP或天( d 小>),小时( h 小>)或分钟( > m )。

可选的 z =字段包含有关时区偏移的信息。 如果发生的会话跨越从夏令时到标准时间的更改,则使用此字段,反之亦然。

媒体公告

可选的 m =字段包含有关媒体会话类型的信息。 该字段包含 -

m =媒体端口传输格式列表

  • 媒体参数是音频,视频,文本,应用程序,消息,图像或控件。 port参数包含端口号。

  • 传输参数包含使用的传输协议或RTP配置文件。

  • 格式列表包含有关介质的更多信息。 通常,它包含在RTP音频视频简档中定义的媒体有效载荷类型。

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

这三个编解码器之一可以用于音频媒体会话。 如果意图是建立三个音频通道,则将使用三个单独的媒体字段。

属性

可选的a =字段包含前面的媒体会话的属性。 此字段可用于扩展SDP以提供有关介质的更多信息 如果SDP用户没有完全理解,则可以忽略属性字段。 媒体字段中列出的每个媒体有效内容类型可以有一个或多个属性字段。

SDP中的属性可以是

  • session level, or
  • media level.

会话级别意味着该属性在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 - 提供/回答模型

SDP与SIP的使用在SDP提议回答RFC 3264中给出。SIP中的默认消息体类型是 application / sdp

  • 主叫方列出他们愿意在SDP中接收的媒体能力,通常在INVITE或ACK中。

  • 被叫方在对INVITE的200 OK响应中列出它们的媒体能力。

SDP的典型SIP使用包括以下字段:版本,起源,主题,时间,连接以及一个或多个媒体和属性。

  • 主题和时间字段不由SIP使用,但包括为了兼容性。

  • 主题和时间字段不由SIP使用,但包括为了兼容性。

  • 时间字段通常设置为t = 00.SIP使用连接,媒体和属性字段在UA之间建立会话。

  • 原始字段对SIP的使用有限。

  • session-id通常在整个SIP会话中保持不变。

  • 每次更改SDP时,版本都会增加。 如果发送的SDP与之前发送的SDP没有变化,则版本保持不变。

  • 由于要使用的媒体会话和编解码器的类型是连接协商的一部分,SIP可以使用SDP来指定多个替代媒体类型并且选择性地接受或拒绝那些媒体类型。

offer / answer规范RFC 3264建议对每个媒体字段使用包含a = rtpmap:的属性。 通过将SDP响应中相应的媒体字段的端口号设置为零来拒绝媒体流。

例子

在以下示例中,呼叫者Tesla想要使用两个可能的音频编解码器和在初始INVITE中携带的SDP中的视频编解码器来建立音频和视频呼叫 -

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与前一个交换相同,或者可以递增一,表示新 必须解析的SDP。

  • 优惠必须包含所有现有媒体行,并且必须按相同的顺序发送。

  • 附加的媒体流可以添加到 m = 行列表的末尾。

  • 可以通过将端口号设置为0来删除现有媒体流。此媒体行必须保留在SDP中以及此会话的所有将来的提供/应答交换。

呼叫保持

呼叫中的一方可以暂时将另一方暂停。 这通过发送具有与原始INVITE的SDP相同的SDP但具有 a = sendonly 属性的INVITE来完成。

通过发送具有 a = sendrecv 属性的另一个INVITE,该调用再次激活。 下图显示了呼叫保持的呼叫流程。

Call Hold

SIP - 移动性

个人移动性是在多个设备上拥有常量标识符的功能。 SIP使用REGISTER方法支持基本的个人移动性,其允许移动设备改变其到因特网的IP地址和连接点,并且仍然能够接收呼入呼叫。

SIP还可以支持服务移动性 - 移动时用户保持相同服务的能力

切换期间的SIP移动性(呼叫前)

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

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

例如,让我们以下面的调用流程为例。 UA已经临时接收到具有新服务提供商的新SIP URI。 UA然后执行双重注册 -

  • 第一次注册是使用新的服务运营商,它将设备的Contact 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并允许建立会话。 定期两个注册都需要刷新。

通话期间的移动(重新邀请)

用户代理可以在会话期间更改其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

re-INVITE在Via和Contact报头字段和SDP媒体信息中包含Bowditch的新IP地址。

移动性在Midcall(与替换标题)

在中间移动性中,实际路由集(SIP消息必须穿越的SIP代理集)必须改变。 我们不能在midcall移动中使用re-INVITE

例如,如果NAT穿越需要代理,则必须更改联系URI - 必须创建一个新对话框。 因此,它必须发送一个带有Replaces标头的新INVITE,它标识现有会话。

注意 - 假设A&amp; B都在一个调用中,如果A得到另一个INVITE(我们说从C)替换头(应该匹配现有的对话框),则A必须接受INVITE并终止与B的会话,并将所有资源转移到新形成的对话框。

呼叫流程如下图所示。 它类似于使用re-INVITE的先前呼叫流程,除了当接受具有Replaces的INVITE时自动生成BYE以终止现有对话。

Mobility In Midcall

下面是在这种情况下要注意的要点 -

  • Tom和Jerry之间的现有对话包括旧的访问代理服务器。

  • 使用新无线网络的新对话框需要包括新的访问代理服务器。

  • 结果,由Tom发送具有Replaces的INVITE,其创建包括新访问的代理服务器但不包括旧的访问的代理服务器的新对话。

  • 当Jerry接受INVITE时,会自动发送一个BYE,以终止通过现在不再包含在会话中的旧访问代理服务器路由的旧对话。

  • 使用来自INVITE中的SDP的Tom的新IP地址来建立所得到的媒体会话。

服务移动性

SIP中的服务可以在代理中或在UA中提供。 除非用户的设备被相同地配置有相同的服务,否则提供服务移动性以及个人移动性可能是有挑战性的。

SIP可以轻松地支持Internet上的服务移动性。 当连接到Internet时,配置为在印度使用一组代理的UA仍然可以在欧洲漫游时使用这些代理。 它对媒体会话的质量没有任何影响,因为媒体总是直接在两个UA之间流动,并且不穿过SIP代理服务器。

端点驻留服务仅在端点连接到Internet时可用。 如果端点已临时丢失其Internet连接,则端点中实现的端点服务(例如呼叫转发服务)将失败。 因此,使用SIP代理服务器在网络中实现一些服务。

SIP - 分岔

有时,代理服务器将单个SIP呼叫转发到多个SIP端点。 这个过程被称为分叉。 这里单个呼叫可以同时响铃多个端点。

使用SIP分叉,您可以让您的桌面电话与手机上的软件电话或SIP电话同时响铃,从而可以轻松地从任一设备接听电话。

一般来说,在办公室里,假设老板无法接听电话或离开,SIP分机允许秘书接听电话他的分机。

如果有一个有状态的代理可用,因为它需要执行和响应从它收到的许多,分叉将是可能的。

我们有两种类型的分叉 -

  • Parallel Forking
  • Sequential Forking

平行分叉

在这种情况下,代理服务器将把INVITE分叉到例如两个设备(UA2,UA3)。 两个设备将产生180响铃,并且接收呼叫的任何人将产生200 OK。 首先到达发起者的响应(假设UA2)将与UA2建立会话。 对于其他响应,将触发CANCEL。

Parallel Forking

如果发起者同时接收到这两个响应,则基于q值,它将转发响应。

顺序分岔

在这种情况下,代理服务器将INVITE分叉到一个设备(UA2)。 如果UA2在那时不可用或忙,则代理将它分配到另一个设备(UA3)。

Sequential Forking

分支 - ID和标签

分支标识帮助代理匹配对分叉请求的响应。 没有分支ID,代理服务器将无法了解分叉响应。 分支标识将在Via标头中可用。

标签由UAC使用以区分来自不同UAS的多个最终响应。 UAS无法解析请求是否已分叉。 因此,它需要添加一个标签。

代理还可以添加标签,如果它生成最终响应,他们从来不插入标签到请求或响应他们转发。

也有可能单个请求也可以由多个代理服务器分叉。 因此,fork的代理将向它创建的分支添加自己的唯一ID。

呼叫支路和呼叫ID

呼叫支路是指两个用户代理之间的一对一信令关系。 呼叫ID是参考呼叫的SIP消息中携带的唯一标识符。 呼叫是呼叫线路的集合。

UAC通过发送INVITE开始。 由于分叉,它可以从不同的UA接收多个200OK。 每个对应于相同呼叫中的不同呼叫支路。

UAC通过发送INVITE开始。 由于分叉,它可以从不同的UA接收多个200OK。 每个对应于相同呼叫中的不同呼叫支路。...

呼叫支路的两个方向上的CSeq空间是独立的。 在单个方向上,序列号对于每个事务递增。

Call Leg Id

语音邮件

对于企业用户来说,语音邮件是非常普遍的。 这是一个电话应用程序。 谈到图片,当被叫方不可用或无法接收呼叫时,PBX将通知主叫方留下语音消息。

如果被叫方的号码不可达,用户代理将获得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路由。

无状态代理服务器

无状态代理服务器简单地转发它接收的消息。 这种服务器不存储任何呼叫或交易的信息。

  • Stateless proxies forget about the SIP request once it has been forwarded.
  • Transaction will be fast via stateless proxies.

状态代理服务器

状态代理服务器跟踪它接收的每个请求和响应。 如果需要,它可以使用未来存储的信息。 如果它没有从另一方接收到响应,它可以重传请求。

  • 状态代理在转发请求之后记住请求,因此它们可以使用它来提前路由。 状态代理维护事务状态。 交易意味着交易状态,不是呼叫状态

  • 事务不像无状态的状态代理那么快。

  • 如果需要,状态代理可以分叉和重传(例如,例如呼叫前转忙)。

通过和记录路由

记录路由

记录 - 路由报头被想要在相同呼叫id的后续请求的路径中的代理插入到请求中。 然后由用户代理使用它来路由后续请求。

通过

通过头由服务器插入请求以检测循环并帮助响应找到他们的方式回到客户端。 这有助于只有响应到达其目的地。

  • UA自己在发送请求时在Via报头字段中生成并添加其自己的地址。

  • 转发请求的代理将Via头字段包含其自己的地址添加到Via头字段列表的顶部。

  • 生成对请求的响应的代理或UA将请求中的所有Via报头字段按顺序复制到响应中,然后将响应发送到在顶部Via报头字段中指定的地址。

  • 接收响应的代理检查顶部Via头字段并匹配其自身的地址。 如果不匹配,则响应已被丢弃。

  • 然后删除顶部Via头字段,并将响应转发到在下一个Via头字段中指定的地址。

Via头字段包含协议名,版本号和传输(SIP / 2.0 / UDP,SIP / 2.0 / TCP等),并包含端口号和参数,如received,rport,branch。

  • 如果UA或代理从与在顶部Via头字段中指定的地址不同的地址接收到请求,则将所接收的标签添加到Via报头字段。

  • 分支参数通过UA和代理被添加到Via报头字段,其被计算为Request-URI的哈希函数,以及To,From,Call-ID和CSeq数。

SIP到PSTN

SIP(软电话)和PSTN(旧电话)都是不同的网络,并使用不同的语言。 因此,我们需要一个翻译器(网关在这里)在这两个网络之间通信。

让我们举一个例子来说明SIP电话如何通过PSTN网关向PSTN发出电话呼叫。

在此示例中,Tom (sip:tom@tutorialspoint.com)是sip电话,Jerry使用全球电话号码+91401234567。

SIP到PSTN通过网关

下图显示了通过网关从SIP到PSTN的呼叫流。

SIP to PSTN

下面给出了从SIP电话到PSTN的呼叫时所进行的所有过程的逐步解释。

  • 首先,(Tom)SIP电话拨打全球号码+91401234567到达Jerry。 SIP用户代理将其理解为全局编号,并使用DNS将其转换为请求uri并触发请求。

  • SIP电话直接向网关发送INVITE。

  • 网关通过选择SS7 ISUP中继线到PSTN中的下一个电话交换机来发起进入PSTN的呼叫。

  • 来自INVITE的拨号数字被映射到ISUP IAM。 ISUP地址完成消息(ACM)由PSTN发回以指示中继已经创建。

  • 电话产生铃声,并进入电话交换机。 网关将ACM映射到183会话进度响应,其包含指示网关将用于桥接来自PSTN的音频的RTP端口的SDP。

  • 在接收到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 - 编解码器

编解码器,编码器 - 解码器的简称,做两个基本操作 -

  • 首先,它将模拟语音信号转换为其等效数字形式,以便可以容易地发送。

  • 此后,它将压缩的数字信号转换回其原始模拟形式,以便可以重放。

市场上有许多编解码器 - 有些是免费的,有些则需要许可。 编解码器在声音质量上不同,并且带宽相应地变化。

硬件设备如电话和网关支持几种不同的编解码器。 当彼此交谈时,他们谈判使用哪个编解码器。

在这里,在本章中,我们将讨论一些流行的SIP音频编解码器,被广泛使用。

G.711

G.711是国际电联在1972年引入的用于数字电话的编解码器。 编解码器有两种变体: A-Law 正在欧洲和国际电话链接中使用, uLaw 用于美国和日本。

  • G.711使用对数压缩。 它将每个16位样本压缩为8位,从而实现1:2的压缩比。

  • 一个方向的比特率为64 kbit / s,因此一个呼叫消耗128 kbit / s。

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

  • 它在我们有很多带宽的局域网中工作的最好。

G.729

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

  • 编解码器以10毫秒长的帧编码音频。 给定8kHz的采样频率,10ms帧包含80个音频样本。

  • 编解码算法将每个帧编码为10个字节,因此在一个方向上产生的比特率为8 kbit / s。

  • G.729是许可编解码器。 想要使用此编解码器的最终用户应购买实现它的硬件(无论是VoIP电话还是网关)。

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

G.723.1

G.723.1是国际电联宣布的竞争的结果,目的是设计一个编解码器,允许呼叫超过28.8和33 kbit / s调制解调器链路。

  • 我们有两个G.723.1的变体。 它们都在30ms的音频帧(即240个采样)上操作,但算法不同。

  • 第一变体的比特率是6.4kbit / s,而对于第二变体,它是5.3kbit / s。

  • 两个变体的编码帧分别为24和20字节长。

GSM 06.10

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

  • 这种GSM编解码器的变体可以自由使用,所以你经常会在开源VoIP应用中找到它。

  • 编解码器对20ms长(即160个样本)的音频帧进行操作,并且将每个帧压缩为33字节,因此所得的比特率为13kbit /。

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)。