SIP（Session Initiation Protocol）会话启动协议

SIP（Session Initiation Protocol）会话启动协议是一个面向于网络电话和会议的的应用层的控制（信令）协议。主要是一个基于IP网络的多媒体通讯协议。它能实现的信令功能也都利用RTP作为媒体传输的协议。最初由IETF MMUSIC (Multiparty Multimedia Session Control) 工作组提出。
SIP能实现的功能主要有：1，网络办公；2，即时短消息；3，即时状态管理；4，网络的IP电话；5，网络会议。有以下几部分组成，
底层： UA Toolkit API(工具包）
接口层：呼叫控制(API)，用户状态管理(API)，即时消息(API)
应用层：
UAC(客户端)流程
呼叫控制-〉初始化（包括注册）-〉会话呼叫建立-〉媒体与数据通道的协商-〉SDP数据包的解析
用户状态-〉状态信息的订阅和通知-〉状态信息的设置-〉状态信息的查询
即时消息 发送即时消息：接收即时消息
UAS(服务器端)
会议管理：建立会议，加入会议，修改会议，离开会议，结束会议，会议相关信息的查询，公布会议状态；
用户管理：位置信息查询，用户认证，增加用户，删除用户；
媒体管理：初始化（协商媒体通道，指定端口和属性），发送媒体流，接收媒体流，用户增加或删除媒体流。
提供RTP/RTCP协议栈完成媒体流的发送/接收和传输。
在连接的地址上采用的是url的，比较方便，格式主要为：用户名＠主机地址、被叫号码＠PSTN网关地址和如Tel：010-62281234这样普通电话号码的描述等。SIP的最强大之处就是用户定位功能。消息和信令均采用文本编码。SIP用于发起一个会话，控制管理多个参与者参与的多媒体会话，并且动态调整会话的属性。SIP独立于低层协议，一般使用UDP等无连接的协议，而采用自己的应用层可靠性机制来保证消息的可靠传输。
重要概念：
UA：用户代理 描述一个普通的用户终端和用户代理，SIP中有客户机和服务器之分。客户机是指为了向服务器发送请求而与服务器建立连接的应用程序。用户代理（User Agent）和代理（Proxy）中含有客户机。服务器是用于向客户机发来的请求提供服务并回送应答的应用程序。共有4类基本服务器：
· 用户代理服务器：当接到SIP请求时联系用户，并代表用户返回响应。
· 代理服务器：代表其他客户机发起请求，既充当服务器又充当客户机的媒介程序。它在转发请求之前可能改写原请求消息中的内容。
· 重定向服务器：接收SIP请求，把请求中的原地址映射成零个或多个新地址，返回给客户机。
· 注册服务器：接收客户机的注册请求，完成用户地址的注册。
SIP对以文本形式表示的消息的词法和语法分析就比较简单。具有分布式的组播功能。
提供的功能： 1）名字翻译和用户定位： 2）特征协商： 3）呼叫参与者管理 4）呼叫特征改变
SIP中有两个要素：SIP用户代理和SIP网络服务器。
用户代理是呼叫的终端系统元素，而SIP服务器是处理与多个呼叫相关联信令的网络设备。用户代理本身具有一客户机元素（用户代理客户机UAC）和一服务器元素（用户代理服务器UAS）。客户机元素初始呼叫而服务器元素应答呼叫。这允许点到点的呼叫通过客户机-服务器协议来完成。
SIP服务器的主要功能是提供名字解析和用户定位。可以获得的是email形式的地址或与被呼叫方关联的电话号码。使用该信息，呼叫者的用户代理能够确定特定服务器来解析地址信息--这可能涉及网络中很多服务器。 SIP代理服务器接收请求，决定将这些请求传送到何处，并且将它们传送到下一服务器（使用下一跳路由原理）。在网络中可以有多跳。
SIP协议栈的结构：
SIP的最底层是语法和编码。
第二层是传输层：它定义了网络上一个客户机如何发送请求和接收响应以及一个服务器如何接收请求和发送响应。
第三层是事务层：事务层处理应用层重传，匹配响应到请求，以及应用层超时。
任何用户代理客户机（UAC）完成的任务使用一组事务产生。 SIP通过EMAIL形式的地址来标明用户地址。每一用户通过一等级化的URL来标识，它通过诸如用户电话号码或主机名等元素来构造（例如：SIP:user@company.com）。因为它与EMAIL地址的相似性，SIP URLs容易于用户的EMAIL地址关联。 呼叫者用INVITE请求初始呼叫当一用户希望呼叫另一用户，呼叫者用INVITE请求初始呼叫，请求包含足够的信息用以被呼叫方参与会话。如果客户机知道另一方的位置它能够直接将请求发送到另一方的IP地址。如果不知道，客户机将请求发送到本地配置的SIP网络服务器。如果服务器是代理服务器它将解析被呼叫用户的位置并且将请求发送给它们。有很多方法完成上步，例如搜索DNS或访问数据库。服务器也可以是重定向服务器，它可以返回被呼叫用户的位置到呼叫客户机用以它直接与用户联系。在定位用户的过程中，SIP网络服务器当然能够代理或重定向呼叫到其它的服务器，直到到达一个明确地知道被呼叫用户IP地址的服务器。一旦发现用户地址，请求就发送给该用户，此时将产生几种选择。在最简单的情况，用户电话客户机接收请求——也就是，用户的电话振铃。如果用户接受呼叫，客户机用客户机软件的指定能力响应请求并且建立连接。如果用户拒绝呼叫，会话将被重定向到语音邮箱服务器或另一用户。"指定能力"参照用户想启用的功能。例如，客户机软件可以支持视频会议，但用户只想使用音频会议，那则只会启用音频功能。
SIP还具有另外两个有重要意义的特征。第一个是有状态SIP代理服务器具有分割入呼叫或复制入呼叫的能力，从而可以同时运行几个扩展分支。第一个应答的分支接受呼叫。该特征在用户工作在两位置之间（例如实验室和办公室）或者同时对经理和其秘书振铃时是非常便利的。第二个特征是SIP独特的返回不同媒体类型的能力。举个用户联系公司的例子。当SIP服务器接收到客户机的连接请求，它能够通过WEB交互式语音响应页面来返回到顾客的客户机，该页面具有可获得的部门分支或提供在列表上的用户。点击适当的链接后将发送一请求到所点击选择的用户从而建立起呼叫。
有两种类型的SIP消息：
● 请求：从客户机发到服务器
● 响应：从服务器发到客户机
SIP请求消息包含三个元素：请求行、头、消息体。 SIP响应消息包含三个元素：状态行、头、消息体。 请求行和头域根据业务、地址和协议特征定义了呼叫的本质，消息体独立于SIP协议并且可包含任何内容。
SIP定义了下述方法：
INVITE——邀请用户加入呼叫。
BYE——终止一呼叫上的两个用户之间的呼叫。
OPTIONS——请求关于服务器能力的信息。
ACK——确认客户机已经接收到对INVITE的最终响应。
REGISTER——提供地址解析的映射，让服务器知道其它用户的位置。
INFO——用于会话中信令。
2.1 SIP消息的总体描述
SIP消息有两种：客户机到服务器的请求（Request）,服务器到客户机的响应（Response）。 SIP消息由一个起始行（start-line）、一个或多个字段（field）组成的消息头、一个标志消息头结束的空行（CRLF）以及作为可选项的消息体（message boby）组成，其中描述消息体（message body）的头称为实体头（entity header）。 generic-message = start-line *message-header CRLF [message-body] 起始行分请求行（Request-Line）和状态行（Status-Line）两种，其中请求行是请求消息的起始行，状态行是响应消息的起始行。消息头分通用头（general-header）,请求头(request-header),响应头（response-header）和实体头（entity-header）四种。
2.2 SIP请求消息请求消息的格式如下。
Request = Request-Line *(general-header | request-header | entity-header CRLF [message-body] 请求行（Request-Line）以方法（method）标记开始，后面是Request-URI和协议版本（SIP-Version）,最后以回车键结束，各个元素间用空格键字符间隔。 Request-Line = Method SP Request-URI SP SIP-Version CRLF SIP 用术语"method"来对说明部分作以描述，Method标识是区分大小写的。SIP定义了以下几种方法（methods）。 Method = "INVITE" | "ACK" | "OPTIONS" | "BYE" | "CANCEL" | "REGISTER" | "INFO" -INVITE INVITE方法用于邀请用户和服务参加一个会话。在INVITE请求的消息体中可对被叫方被邀请参加的会话作以描述。如主叫方能接收的媒体类型、发出的媒体类型及其一些参数：对INVITE请求的成功响应必须在响应的消息体中说明被叫方愿意接收那种媒体，或者说明被叫方发出的媒体。服务器可以自动地用200（OK）响应会议邀请。 -ACK ACK请求用于客户机向服务器证实它已经收到了对INVITE请求的最终响应。ACK只和INVITE请求一起使用。对2xx最终响应的证实由客户机用户代理发出，对其它最终响应的证实由收到响应的第一个代理或第一个客户机用户代理发出。ACK请求的To、From、Call-ID,Cseq字段的值由对应的INIVITE请求的相应字段的值复制而来。 -OPTIONS 用于向服务器查询其能力。如果服务器认为它能与用户联系，则可用一个能力集响应OPTIONS请求；对于代理和重定向服务器只要转发此请求，不用显示其能力。 OPTIONS的From、To分别包含主被叫的地址信息，对OPTIONS请求的响应中的From、To(可能加上tag参数)、Call-ID字段的值由OPTIONS请求中响应的字段值复制得到BYE. 用户代理客户机用BYE请求向服务器表明它想释放呼叫。 BYE请求可以象INVITE请求那样被转发，可由主叫方发出也可以由被叫方发出。呼叫的一方在释放（挂断）呼叫前必须发出BYE请求，收到BYE请求的这方必须停止发媒体流给发出BYE请求的这方。 -CANCEL CANCEL请求用于取消一个Call-ID,TO,From和Cseq(仅序列号)字段值相同的正在进行的请求，但取消不了已经完成的请求（如果服务器返回一个最终状态响应，则认为请求已完成）。 CANCEL请求中的Call-ID,To,Cseq的数字部分及From字段和原请求的对应字段值相同，从而使CANCEL请求与它要取消的请求匹配。 -REGISTER REGISTER 方法用于客户机向SIP服务器注册列在To字段中的地址信息。 REGISTER 请求消息头中各个字段的含义定义如下： To:含要创建或更新的注册的地址记录。 From:含提出注册的人的地址记录。 Request-URI:注册请求的目的地址，地址的域部分的值即为主管注册者所在的域，而主机部分必须为空。一般，Request-URI中的地址的域部分的值和To中的地址的域部分的值相同。 Call-ID:用于标识特定客户机的请求。来自同个客户机的注册请求至少在相同重启周期内Call-ID字段值应该相同；用户可用不同Call-ID值注册不同的地址，后面的注册请求将替换前面的所以请求。 Cseq:Call-ID字段值相同的注册请求的Cseq字段值必须是递增的，但次序无关系，服务器并不拒绝无序请求。 Contact:此字段是可选：用于把以后发送到TO字段中的URI的非-注册请求转到Contact字段给出的位置那里。如果请求中没有Contact 字段，那么注册保持不变。 Expires:表示注册的截止期。 -INFO INFO 方法是对SIP协议的扩展，用于传递会话中产生的与会话相关的控制信息，如：ISUP和ISDN信令消息，有关此方法的使用还有待标准化，详细内容参见IETF RFC 2976。
2.3 SIP响应信息响应信息的格式如下。
Response = Status-Line *(general-header | response-header | entity-header CRLF [message-body] 状态行（Status-Line）以协议版本开始，接下来是用数字表示的状态码（Status-Code）及相关的文本说明，最后以回车键结束，各个元素间用空格字符（SP）间隔，除了在最后的CRLF序列中，这一行别的地方不允许使用回车或换行字符。 Status-Line = SIP-version SP Status-Code SP Reason-Phrase CRLF SIP协议中用三位整数的状态码（Status Code）和原因值（Reason Code）来表示对请求的作出回答，状态码用于机器识别操作，原因短语（Reason-Phrase）是对状态码的简单文字描述，用于人工识别操作。 Status-Code = 1xx (Information) | 2xx (Success) | 3xx (Redirection) | 4xx (Client-Error) | 5xx (Service-Error) | 6xx (Global-Failure) | extension-code 状态码的第一个数字定义响应的类别，在SIP/2.0中第一个数字有6个值，定义如下： 1xx: informational － 请求已经收到、继续处理请求。 2xx: success － 行动已经成功地收到，理解和介绍。 3xx: Redirection － 为完成呼叫请求，还须采取进一步地动作。 4xx: Client Error － 请求有语法错误或不能被服务器执行。客户机需修改请求，然后再重发请求。 5xx: Server Error － 服务器出错，不能执行合法请求。 6xx: GLOBAL FAILURE － 任何服务器都不能执行请求。 其中 1xx 响应为暂时响应（Provisional response）,其它响应为最终响应（Final Response）。
2.4 SIP地消息头字段
SIP协议的消息定义与HTTP在语法规则和定义上很相似。每个头字段都遵循以下格式；首先是字段名（Field Name）,字段名不分大小写，后面是冒号，然后是字段值，字段值与冒号间可有多个前导空格（LWS）。 message-header = field-name ":" [field-value] CRLF field-name = token field-value = * (field-content | LWS) （1）通用消息头（General-header）通用头字段适用于请求消息和响应消息，包含的字段有： general-header = Accept | Accept-Encoding | Accept-Language | Call-ID | Contact | CSeq | Data | Encryption | Expires | From | Organization | Record-Route | Timestamp | To | User-Agent | Via 其中，Accept,Accept-Encoding,Accept-Language字段用于客户机在请求消息中给出可接受的响应的媒体类型，编码方式，以及描述语言：用于服务器在415响应中表明其可理解的请求消息的媒体类型，编码方式，以及描述语言。 Call-ID字段用于唯一标识特定邀请或某个客户机的注册请求，一个多媒体会议可产生多个Call-ID不同的呼叫。 Contact字段给出一个URL,用户可以与此URL建立进一步的通信。 Cseq 字段用于标识服务器发出的不同请求，若Call-ID值相同，那么Cseq值必须各不相同。 Date 字段反映首次发出请求或响应消息的时间，重发的消息与原先的消息有相同的Data字段值。 Encryption字段表明内容经过了加密处理，这种加密为端到端的加密。 Expire字段给出消息内容截止的日期和时间。 所有消息中都必须有From字段，此字段给出请求的发起者。 Organization字段给出发出请求或响应消息的实体所属的组织名称。 Record-Route字段给出一个全局可到达的Request-URI,用于标识代理服务器。 Time-Stamp字段给出客户机向服务器发出请求的时间。 所有消息中都必须有To字段，此字段给出请求的目的收方。 User-Agent 字段含有与发起请求的用户代理客户机有关的信息。 Via字段给出请求消息迄今为止经过的路径。（2）Entity-header 实体头字段用于定义与消息体相关的信息。 Entity-header = Content-Encoding | Content-Length | Content-Type Content-Encoding字段表明消息体上添加应用的内容编码方式。 Content-Length 字段表明消息体的大小。 Content-Type字段表明消息体的媒体类型。 （3）Request-header 请求头字段用于客户机上传附加信息到服务器，其中包括有关请求和客户机本身的信息。 request-header = Authorization | Contact ; | Hide ; | Max-Forwards ; | Priority ; | Proxy-Authorization ; | Proxy-Require ; | Route ; | Require ; | Response-Key ; | Subject ; Authorization字段用于用户代理向服务器鉴定自身身份。 Hide 字段用于客户机表明其希望向后面的代理服务器或用户代理隐藏由Via字段构成的路径。 Max-Forwords字段表明请求消息允许被转发的次数。 Priority字段用于客户机表明请求的紧急程度。 Priority-Authorization字段用于客户机向要求省份认证的代理服务器表明自身身份。 Proxy-Require 字段用于标识出代理必须支持的代理敏感特征。 Route 字段决定请求消息的路由。 Require字段用于客户机告诉代理服务器为了正确让服务器处理请求，客户机希望服务器支持的选项。 Require-Key 字段用于给出被叫方用户代理加密响应消息所采用的密钥需满足的要求。 Subject 字段提供对呼叫的概述或表明呼叫的性质，可用于呼叫过滤。（4）Response-header 响应头字段用于服务器向Request-URI指定的地址传送有关响应的附加信息。 response-header = Allow | Proxy-Authenticate | Retry-After | Server | Unsupported | Warning | WWW-Authenticate Proxy-Authenticate 字段必须为407响应的一部分，字段中的值给出适用于Request-URI的代理的认证体制和参数。 Retry-After字段可用于503响应中，向发出请求的客户机表明服务预计多久以后可以启用，用于404，600，603响应中表明被叫何时再有空。 Server 字段含有用户代理服务器处理请求所使用的软件信息。 Unsupported字段列出服务器不支持的特征。 Warning字段用于传递与响应状态有关的附加信息。 www-Authenticate字段含于401响应中，指出适用于Request-URI的认证体制和参数。