通信人家园

 找回密码
 注册

只需一步,快速开始

短信验证,便捷登录

搜索

军衔等级:

  新兵

注册:2011-12-20
跳转到指定楼层
1#
发表于 2013-12-2 14:14:20 |只看该作者 |倒序浏览
一、SIP概述
SIP(Session Initiation Protocol)称为会话发起协议,是由IETF组织于1999提出的一个在基于IP网络中,特别是在Internet这样一种结构的网络环境中,实现实时通信应用的一种下一代网络信令协议.它是个基于文本的应用层协议。在基于SIP协议的应用中,每一个会话可以是各种不同的数据,可以是普通的文本数据,也可以是经过数字化处理的音频、视频数据,还可以是诸如游戏等应用的数据。正如其名称的含意那样,SIP负责会话信令如语音、视频或多媒体信息初始化数据的交换。为保证性能和简单易于扩展性,SIP需要使用用户数据报协议(UDP),而TCP则是可选协议。由于UDP传输不能得到百分之百的保证,所以SIP中包含数据重新传输机制,其中还包括建立三方会话的交换机制。
二、基本组成
SIP协议虽然主要为IP网络设计的,但它并不关心承载网络,也可以在ATM、帧中继等承载网中工作,可以运行于TCP、UDP、SMTP等各种传输层协议之上。SIP用户通过类似于e-mail地址的URL标识,例如sip:myname@example.com,通过这种方式可以用一个统一名字标识不同的终端和通信方式。
SIP主要由于4种元素组成:用户代理、代理服务器、重定向服务器以及注册服务器。
1.用户代理(User Agent)
用户代理是一个用于用户与用户之间交互的SIP实体,它通常有一个与用户连接的接口。可分两个部分:用户客户端(UAC),负责发起呼叫;用户服务端(UAS),负责接受呼叫并做出响应。两者并不是绝对的。举个例子:Bob想要在他的计算机上通过Internet打电话给Jack,他运行了一个包含SIP用户代理的应用程序,Bob通过接口和UA交互。一旦Bob按了呼叫Jack的接口按钮,UA就触发相应的SIP消息建立呼叫请求。Bob的UA此时扮演的就是UAC。
Jack的计算机上也有一个SIP用户代理,当这个代理收到Bob用户代理发来的请求时,可能给出两个按钮给Jack选择:接受请求和拒绝请求。当Jack作出如接受请求时按下接受请求按钮,Jack的用户代理根据作出的选择给Bob的用户代理回送消息。Jack的UA此时扮演的就是UAS。用户和SIP之间的所有交互都是通过UA作为中介来完成的。
2.代理服务器(Proxy Server)
代理服务器负责接收用户代理发来的请求,根据网络策略将请求发给相应的服务器,并根据收到的应答对用户代理做出响应。可分为保留呼叫状态代理、保留状态代理和不保留状态代理。
上例中Bob只发出一个呼叫请求,但是可能会有很多Proxy为他建立呼叫请求,设Jack是Hust电信系ITEC的一名研究生,Hust有一个代理服务器,电信系也有一个代理服务器,当Bob的请求:Jack@hust.com,到达Hust时,Hust的代理服务器将代表Bob的UA自动向Jack@ei.hust.com发出请求,当请求到达电信系服务器时,电信第代理服务器将自动向ITEC发出Jack@itec.ei.hust.com请求。
3.重定向服务器(Redirect Server)
重定向服务器用于在需要时将用户新的位置返回给呼叫方。呼叫方可根据得到新位置重新呼叫。如上例设Hust有一个重定向服务器,
它知道Jack工作时在Jack@202.114.5.36,休息时在Jack@222.20.74.219
它就将这两个地址返回给Bob的UA,UA根据返回的地址同时向这两个地址发送请求。当然重定向服务器也可以返回知道Jack更多地址的的服务器。
4.注册服务器(Register)
注册服务器用于接收和处理用户端的注册请求,完成用户地址的注册。SIP提供了一个搜索机制,如果一个用户期望建立和其它用户会话,SIP必须查找能够找到对方用户正在使用的当前主机。如Jack想要别人能够找到他就必须向服务注册可以找到他的一个或几个地址。
三、消息格式
SIP消息采用的是文本格式编码,虽然在传输时占用的带宽比二进制更宽,但是采用文本更容易让人阅读,所以便于调试,而且采用文本协议更灵活更易于以后新功能的扩展。
3.1   SIP消息有两种:请求消息和响应消息。
一个SIP消息由一个起始行、一个或几个字段组成的消息头、一个空行以及可选的消息体组成。起始行分为请求行和状态行两种,分别对应请求消息和响应消息的起始行。
3.2  常用标题头
标题头提供了有关于请求或应答的信息和关于这些消息所包含的消息体的信息。
呼叫标识(Call-ID):代表了一种在两个或多个用户之间共享SIP信令的关系,它标识了一个特定的邀请和这个邀请相关的所有后续事务。一个多媒体会议可产生多个Call-ID不同的呼叫。
From:表示了请求的来源地。这个可能和对话的来源不同,被叫方到呼叫方的请求会在From头域中使用被叫方的地址。
To:定义了逻辑上的请求的接受者。它通常还包含目的方的公用地址,在整个会话过程中,To头域不能被更改。
联系(Contact):提供了一个URI,这个URI的含义取决玩是在请求还是在应答中。根据Contact标题头可以直接找到用户的URL,它们在路由第一个INVITE请求后就不再需要存放在信令中,这个特性非常重要。如Bob知道了Jack在222.20.74.219工作,他在ACK中就不需要再经过@hust.com了。
命令序列标题头(Cseq):包含一个数字序列号和请求的方法。数字部分用于在同一会话中对不同的请求进行排序。如Bob发送一个INVITE消息给Jack:
Cseq: 1 INVIITE
如果他想重新发一个,可以写成如下:Cseq: 2   INVITE。
在ACK和CANCEL请求中应该有与对应的INVITE同样的Cseq。
Max-Forwards: 必须在任何一个SIP请求中使用,来限制中间转发请求到下一个节点的proxy or gateway的个数。每当服务器转发一次这个数字就减一。
路由(Route):用于强制一个请求经过一个proxy路由列表。
Via:用来描述请求当前经历的路径的,并且标志了应答所应当经过的路径。
3.3对SDP的要求

1.协议版本
v = 0
2.会话源
o =<用户名><会话标识><版本><网络类><地址类型><地址>
3 连接数据
c = <网络类型><地址类型><地址>
4.时间描述
t =<起始时间><终止时间>
5.媒体级描述
m = <媒体><端口><传送层><格式列表>
6.属性
a = <属性>:<值>

四、请求应答
4.1  请求
SIP核心规范了6种请求方法,分别是:INVITE、 ACK 、BYE、 CANCEL、 REGISTER 、OPTIONS。
1.请求(INVITE):用于邀请用户或服务参加一个会话。在INVITE请求的消息体中可对被叫方被邀请参加的会话加以描述,如主叫方能媒体类型、发出的媒体及其一些参数;对INVITE请求的成功响应必须有在响应的消息体中说明被叫方愿意接收哪种媒体或者说明被叫方发出的媒体。假如Bob的用户代理用SDP描述会话如下:
v = 0
o = Bob 12345678 84571644 IN IPv4 222.20.45.123
s = I miss you I want to talk to you
c = IN  IPv4  222.20.45.123
t = 0  0
m = audio 12345 RTP/AVP  0
Jack的用户代理收到Bob 的INVITE邀请加入会话.根据会话描述,UA知道这是由Bob发起的,他想要在IP是222.20.45.123 ,UDP端口12345接受Jack声音的实时传输协议(RTP)的数据包,并且知道它可以接收PCM编码声音。UA通知Jack并发出“180振铃”给Bob的UA。当Jack决定接听时,UA发送个最终应答“200OK” 给Bob。
2.确认(ACK):ACK请求用于客户机向服务器证实它已经收到了对INVITE请求的最终响应。ACK只能和INVITE请求一起使用。完成三次握手:INVITE—最终应答---ACK。当Bob的UA没有收到临时应答和最终应答时就不断重发INVITE请求(或者放弃),因为他不能确定Jack是否收到请求或者消息在途中丢失了。只有请求客户端才有权利发送ACK。
3.再见(BYE):用户代理客户机用BYE请求向服务器表明它想释放呼叫。可以由主叫方发出也可以由被叫方发出。呼叫的一方在释放呼叫前必须发出BYE请求,收到BYE请求的这方必须停止发送媒体流给发出BYE请求的一方。
4.    取消(CANCEL):用于取消一个Call-ID,To,From,和Cseq字段相同的下在进行的请求,但是取消不了已经完成的请求。如果电话很长时间没有人接听,Bob决定取消请求,他就会发一个Cancel请求。Jack 的UA收到请求后停止振铃,会话没有建立成功,发送一个ACK请求给Bob的UA。同样也要三次握手:请求----取消事务---ACK。
5.注册(REGISTER):用于客户机向SIP服务器注册列在To字段中的地址信息。
用户发送一个REGISTER请求给服务器通知他们当前所在地。如Jack可以向Hust服务器的注册员指示所有进入到Hust的请求都可以在Sip:jack@itec.ei.hust.com,或者重定为jack@dom.hust.com。这样所有找Jack的请方便到一些可能的地方找到他。
6.选项(OPTIONS):用于向服务器查询其能力。如果服务器认为它能与用户联系,则可用一个能力集响应OPTIONS请求;对于代理和重定向服务器只要转发此请求,不用显示其能力。
4.2应答
当服务器收到请求时就会作出一个应答,每个应答都有一个代表事务状态的编码。其中1XX是临时应答,其余都是最终应答。

1XX(Informational)
请求已经收到、继续处理请求
2XX(Uccess)
行动已经成功地收到,理解和接受
3XX(Redirection)
为完成呼叫请求,还须采取进一步的动作
4XX(Client Error)
请求有语法错误或不能被服务器执行,客户机需修改请求
5XX(Server Error)
服务器出错,不能执行合法请求
6XX(Global Failure)
任务服务器都不能执行请求

五、事务
5.1 INVITE事务
INVITE请求包含了一个三方的握手:客户端事务发送一个INVITE,服务端事务返回一个应答,客户端事务发送一个ACK。采用逐跳的机制,保证每一个信令被成功向下一跳传送。当然不保存状态机不能完成此任务。在传输中可以采用的不是同一个协议,服务器与服务器之间可能有点是UDP有的是TCP。在用户端和Proxy中都要设立定时器,以备重发。
1.发送一个INVITE请求
发送一个请求必须保证TU是用INVITE请求来初始化一个新的客户端事务。客户端事务必须把请求发送到通讯层来进行发送。SIP采用一种机制保证每一个INVITE请求成功的发往下一跳,路径上Proxy有义务把INVITE向下一个Proxy或终端UA发送。在可靠的传输协议上Proxy不需要做其它的事了;如果在不可靠的协议中,Proxy在收不到应答时将每隔T重发请求,重发的时间间隔加倍。在无状态的Proxy中不能完成此任务。当Proxy收到请求时,总会产生一个“100trying”应答,防止请求端不断重发请求。而请求的用户代理可能产生任何的临时响应,如“ 180ringing”。
2. 应答INVITE请求
SIP不能保证临时应答都能够到达呼叫者的UA,即使丢失了也不重传。但对于最终应答,不论是成功还是非成功应答,SIP都是采用逐跳传送,在不可靠的传输UDP上传输时,要不断重传请求,直到收到ACK。当然在可靠的传输协议中也需要ACK应答,因为SIP是三次握手协议。
5.2非INVITE请求
非INVITE事务并不使用ACK。他们只是简单的请求—应答的交互。对于非可靠的传输来说,请求是间隔T1倍增地传输。如果只收到了一个临时应答,到达到T2时如果没有收到最终应答,重传继续。这与INVITE事务不同,这样做的目的是确保收到一个最终应答。

举报本楼

您需要登录后才可以回帖 登录 | 注册 |

版规|手机版|C114 ( 沪ICP备12002291号-1 )|联系我们 |网站地图  

GMT+8, 2025-8-13 04:04 , Processed in 0.210003 second(s), 17 queries , Gzip On.

Copyright © 1999-2025 C114 All Rights Reserved

Discuz Licensed

回顶部