4. 操作概述 (Overview of Operation)
本节使用简单示例介绍SIP的基本操作。本节是教程性质的, 不包含任何规范性陈述。
第一个示例展示了SIP的基本功能: 定位端点、发出通信意愿信号、协商会话参数以建立会话以及一旦建立会话后拆除会话。
图1显示了两个用户Alice和Bob之间典型的SIP消息交换示例。(每条消息都用字母"F"和一个数字标记, 以供文本参考。) 在这个例子中, Alice在她的PC上使用SIP应用程序 (称为软电话, Softphone) 通过互联网呼叫Bob的SIP电话。还显示了两个代表Alice和Bob的SIP代理服务器 (Proxy Server), 以促进会话建立。这种典型的安排通常被称为"SIP梯形 (SIP Trapezoid)", 如图1中虚线的几何形状所示。
4.1 SIP地址 (SIP Addressing)
Alice使用Bob的SIP身份"呼叫"Bob, 这是一种称为SIP URI的统一资源标识符 (Uniform Resource Identifier, URI)。SIP URI在第19.1节中定义。它的形式类似于电子邮件地址, 通常包含用户名和主机名。在这种情况下, 它是 sip:[email protected], 其中 biloxi.com 是Bob的SIP服务提供商的域。Alice的SIP URI是 sip:[email protected]。Alice可能已经输入了Bob的URI, 或者可能点击了超链接或地址簿中的条目。SIP还提供了一个安全URI, 称为SIPS URI。例如 sips:[email protected]。对SIPS URI的呼叫保证使用安全的加密传输 (即TLS) 来承载从呼叫者到被叫者域的所有SIP消息。从那里, 请求被安全地发送到被叫者, 但使用的安全机制取决于被叫者域的策略。
4.2 SIP事务模型 (SIP Transaction Model)
SIP基于类似HTTP的请求/响应事务模型。每个事务由一个在服务器上调用特定方法或功能的请求和至少一个响应组成。在这个例子中, 事务从Alice的软电话发送一个地址为Bob的SIP URI的INVITE请求开始。INVITE是SIP方法的一个示例, 它指定请求者 (Alice) 希望服务器 (Bob) 采取的操作。INVITE请求包含许多头字段 (Header Field)。头字段是提供有关消息的附加信息的命名属性。INVITE中存在的头字段包括呼叫的唯一标识符、目标地址、Alice的地址以及关于Alice希望与Bob建立的会话类型的信息。
4.3 SIP消息示例 (SIP Message Example)
图1中的INVITE消息 (消息F1) 可能如下所示:
atlanta.com . . . biloxi.com
proxy proxy
. .
Alice's . . . . . . . . . . . . . . . . . . . . Bob's
softphone SIP Phone
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 Trying F3 |--------------->| INVITE F4 |
|<---------------| 100 Trying F5 |--------------->|
| |<-------------- | 180 Ringing F6 |
| | 180 Ringing F7 |<---------------|
| 180 Ringing F8 |<---------------| 200 OK F9 |
|<---------------| 200 OK F10 |<---------------|
| 200 OK F11 |<---------------| |
|<---------------| | |
| ACK F12 |
|------------------------------------------------->|
| Media Session |
|<================================================>|
| BYE F13 |
|<-------------------------------------------------|
| 200 OK F14 |
|------------------------------------------------->|
| |
图1: 使用SIP梯形的SIP会话建立示例
INVITE请求示例:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
4.4 头字段说明 (Header Fields Description)
文本编码消息的第一行包含方法名称 (INVITE)。后面的行是头字段列表。此示例包含最小必需集。头字段简要描述如下:
-
Via: 包含Alice期望接收此请求响应的地址 (
pc33.atlanta.com)。它还包含一个标识此事务的分支参数 (Branch Parameter)。 -
To: 包含显示名称 (Bob) 和最初定向请求的SIP或SIPS URI (
sip:[email protected])。显示名称在RFC 2822 [3] 中描述。 -
From: 还包含显示名称 (Alice) 和指示请求发起者的SIP或SIPS URI (
sip:[email protected])。此头字段还有一个标签参数 (Tag Parameter), 包含软电话添加到URI的随机字符串 (1928301774)。它用于识别目的。 -
Call-ID: 包含此呼叫的全局唯一标识符, 由随机字符串和软电话的主机名或IP地址组合生成。To标签、From标签和Call-ID的组合完全定义了Alice和Bob之间的对等SIP关系, 称为对话 (Dialog)。
-
CSeq (命令序列, Command Sequence): 包含整数和方法名称。CSeq号码在对话中的每个新请求中递增, 是传统序列号。
-
Contact: 包含表示直接路由以联系Alice的SIP或SIPS URI, 通常由完全限定域名 (FQDN) 上的用户名组成。虽然首选FQDN, 但许多终端系统没有注册域名, 因此允许使用IP地址。虽然Via头字段告诉其他元素将响应发送到哪里, 但Contact头字段告诉其他元素将未来的请求发送到哪里。
-
Max-Forwards: 用于限制请求在到达目的地的途中可以进行的跳数。它由一个整数组成, 每跳递减一。
-
Content-Type: 包含消息体 (未显示) 的描述。
-
Content-Length: 包含消息体的八位字节 (字节) 计数。
完整的SIP头字段集在第20节中定义。
4.5 会话描述 (Session Description)
会话的详细信息, 例如媒体类型、编解码器或采样率, 不是使用SIP描述的。相反, SIP消息的主体包含会话的描述, 以某种其他协议格式编码。一种这样的格式是会话描述协议 (Session Description Protocol, SDP) (RFC 2327 [1])。此SDP消息 (示例中未显示) 由SIP消息承载, 其方式类似于文档附件由电子邮件消息承载, 或网页由HTTP消息承载。
4.6 代理服务器操作 (Proxy Server Operation)
由于软电话不知道Bob的位置或biloxi.com域中SIP服务器的位置, 软电话将INVITE发送到为Alice的域atlanta.com提供服务的SIP服务器。atlanta.com SIP服务器的地址可能已在Alice的软电话中配置, 或者可能已通过DHCP发现, 例如。
atlanta.com SIP服务器是一种称为代理服务器 (Proxy Server) 的SIP服务器。代理服务器代表请求者接收SIP请求并转发它们。在这个例子中, 代理服务器接收INVITE请求并将100 (Trying) 响应发送回Alice的软电话。100 (Trying) 响应表明已收到INVITE, 并且代理正在代表她工作以将INVITE路由到目的地。SIP中的响应使用三位数代码后跟描述性短语。此响应包含与INVITE相同的To、From、Call-ID、CSeq和Via中的分支参数, 这允许Alice的软电话将此响应与发送的INVITE关联起来。
atlanta.com代理服务器定位biloxi.com的代理服务器, 可能通过执行特定类型的DNS (域名服务) 查找来查找为biloxi.com域提供服务的SIP服务器。这在 [4] 中描述。因此, 它获得biloxi.com代理服务器的IP地址并将INVITE请求转发或代理到那里。在转发请求之前, atlanta.com代理服务器添加一个包含其自己地址的额外Via头字段值 (INVITE已经在第一个Via中包含Alice的地址)。biloxi.com代理服务器接收INVITE并用100 (Trying) 响应回复atlanta.com代理服务器, 以表明它已收到INVITE并正在处理请求。代理服务器查询数据库 (通常称为位置服务, Location Service), 其中包含Bob的当前IP地址。(我们将在下一节中看到如何填充此数据库。) biloxi.com代理服务器向INVITE添加另一个包含其自己地址的Via头字段值, 并将其代理到Bob的SIP电话。
4.7 响应处理 (Response Processing)
Bob的SIP电话接收INVITE并提醒Bob Alice的来电, 以便Bob可以决定是否接听电话, 即Bob的电话振铃。Bob的SIP电话在180 (Ringing) 响应中指示这一点, 该响应通过两个代理以相反方向路由回去。每个代理使用Via头字段确定将响应发送到哪里, 并从顶部删除其自己的地址。因此, 尽管需要DNS和位置服务查找来路由初始INVITE, 但180 (Ringing) 响应可以返回给呼叫者, 而无需查找或无需在代理中维护状态。此响应码在每个代理中触发一些处理, 但代理不处于呼叫状态。
4.8 会话建立 (Session Establishment)
当Bob接听电话时, Bob的SIP电话发送200 (OK) 响应以指示呼叫已被接受。200 (OK) 包含描述Bob愿意在会话中接受的媒体的消息体。因此, 在交换INVITE请求和INVITE请求的200 (OK) 响应期间交换了两个会话描述。第一个是在INVITE中, 第二个是在200 (OK) 中。在检查200 (OK) 响应中的会话描述后, Alice的softphone发送确认消息ACK到Bob的SIP电话以确认收到最终响应 (200 (OK))。在这种情况下, ACK直接从Alice的softphone发送到Bob的SIP电话, 绕过两个代理。这是因为200 (OK) 响应中的Contact头字段包含Bob的SIP电话的URI, 因此Alice知道将ACK发送到哪里。还要注意, 200 (OK) 响应中的Via头字段包含Alice的地址, 因此200 (OK) 在路由回Alice时不会通过任何代理。代理仅参与路由请求, 而不参与路由响应。
4.9 媒体会话 (Media Session)
最后, 媒体会话已建立, Alice和Bob可以交谈。通常, 媒体会话是点对点的, 不涉及SIP代理。在某些情况下, 通过媒体服务器进行媒体会话可能是有用的或必要的。
4.10 会话终止 (Session Termination)
当Bob挂断时, 他的SIP电话发送BYE请求。此BYE直接路由到Alice的softphone, 再次绕过代理。Alice通过发送200 (OK) 响应确认收到BYE, 这结束了会话和BYE事务。除非在Call-ID中重用, 否则不会为此呼叫再交换消息。
注意: 本章提供了SIP操作的基本概述。更详细的规范和其他操作场景将在后续章节中描述。