一、SIP系统基本组成
SIP协议虽然主要为IP网络设计的，但它并不关心承载网络，也可以在ATM、帧中继等承载网中工作，它是应用层协议，可以运行于TCP,UDP,SCTP等各种传输层协议之上。 SIP用户是通过类似于e-mail地址的URL标识，例如：sip:myname@mycompany.com,通过这种方式可以用一个统一名字标识不同的终端和通信方式，为网络服务和用户使用提供充分的灵活性。
我公司提各类SIP系统方案应用与产品销售，欢迎咨询我司。感谢您的观注
按逻辑功能区分，SIP系统由4种元素组成：用户代理、代理服务器、重定向服务器以及注册服务器。
1.用户代理
用户代理(UserAgent)分为两个部分：客户端(UserAgentClient),负责发起呼叫；用户代理服务器(UserAgentServer),负责接受呼叫并做出响应。二者组成用户代理存在于用户终端中。用户代理按照是否保存状态可分为有状态代理、有部分状态用户代理和无状态用户代理。
2.代理服务器
代理服务器(ProxyServer),负责接收用户代理发来的请求，根据网络策略将请求发给相应的服务器，并根据收到的应答对用户做出响应。它可以根据需要对收到的消息改写后再发出。
3.重定向服务器
重定向服务器(RedirectServer),用于在需要时将用户新的位置返回给呼叫方。呼叫方可根据得到的新位置重新呼叫。
4.注册服务器
注册服务器(Registrar),用于接收和处理用户端的注册请求，完成用户地址的注册。
以上几种服务器可共存于一个设备，也可以分布在不同的物理实体中。SIP服务器完全是纯软件实现，可以根据需要运行于各种工作站或专用设备中。
UAC,UAS,ProxyServer,RedirectServer是在一个具体呼叫事件中扮演的不同角色，而这样的角色不是固定不变的。一个用户终端在会话建立时扮演UAS,而在主动发起拆除连接时,则扮演UAC。一个服务器在正常呼叫时作为ProxyServer,而如果其所管理的用户移动到了别处，或者网络对被呼叫地址有特别策略，则它将扮演RedirectServer,告知呼叫发起者该用户新的位置。
除了以上部件，网络还需要提供位置目录服务，以便在呼叫接续过程中定位被叫方(服务器或用户端)的具体位置。这部分协议不是SIP协议的范畴，可选用LDAP(轻量目录访问协议)等。
理论上，SIP呼叫可以只有双方的用户代理参与，而不需要网络服务器。设置服务器，主要是服务提供者运营的需要。运营商通过服务器可以实现用户认证、管理和计费等功能，并根据策略对用户呼叫进行有效的控制。同时可以引入一系列应用服务器，提供丰富的智能业务。
SIP的组网很灵活，可根据情况定制。在网络服务器的分工方面：位于网络核心的服务器，处理大量请求，负责重定向等工作，是无状态的，它个别地处理每个消息，而不必跟踪纪录一个会话的全过程；网络边缘的服务器，处理局部有限数量的用户呼叫，是有状态的，负责对每个会话进行管理和计费，需要跟踪一个会话的全过程。这样的协调工作，既保证了对用户和会话的可管理性，又使网络核心负担大大减轻，实现可伸缩性，基本可以接入无限量用户。SIP网络具有很强的重路由选择能力，具有很好的弹性和健壮性。
SIP的消息格式
SIP是IETF提出的在IP网络上进行多媒体通信的应用层控制协议，可用于建立、修改、终结多媒体会话和呼叫，号称通信技术中的"TCP/IP”。SIP协议采用基于文本格式的客户一服务器方式，以文本的形式表示消息的语法、语义和编码，客户机发起请求，服务器进行响应。SIP独立于底层协议——TCP、UDP或SCTP,采用自己的应用层可靠性机制来保证消息的可靠传送。有关SIP协议的详细内容可参见IETFRFC326E
二、SIP消息总体描述
SIP消息有两种：客户机到服务器的请求(Request),服务器到客户机的响应(Response)。
SIP消息由一个起始行(start—line)、一个或多个字段(field)组成的消息头、一个标志消息头结束的空行(CRLF)以及作为可选项的消息体(message body)组成。其中，描述消息体(message body)的头称为实体头(entity header),其格式如下：
generic-message=start-line
*message-header
CRLF
CRLF
[message-body]
起始行分请求行(Request-Line)和状态行(Status-Line)两种，其中请求行是请求消息的起始行，状态行是响应消息的起始行。
消息头分通用头(general-header)、请求头(request-header)、响应头(response-header)和实体头(entity-header)4种。
1.SIP请求消息
请求消息的格式如下：
Request=Request-Line
*(general-header
I request-header
I 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标识是区分大小写的。
Method="INVITE"I"ACK"I"OPTIONS"I"BYE"
I"CANCEL"I"REGISTER'T'INFO"
SIP定义了以下几种方法(methods)。
SIP定义了以下几种方法(methods)。
INVITE
INVITE方法用于邀请用户或服务参加一个会话。在INVITE请求的消息体中可对被叫方被邀请参加的会话加以描述，如主叫方能接收的媒体类型、发出的媒体类型及其一些参数；对INVITE请求的成功响应必须在响应的消息体中说明被叫方愿意接收哪种媒体，或者说明被叫方发出的媒体。
服务器可以自动地用200(OK)响应响应会议邀请。
ACK
ACK请求用于客户机向服务器证实它已经收到了对INVITE请求的最终响应。ACK只和INVITE请求一起使用。对2xx最终响应的证实由客户机用户代理发出，对其他最终响应的证实由收到响应的第一个代理或第一个客户机用户代理发出。ACK请求的To,From,CaU-ID,CSeq字段的值由对应的INVITE请求的相应字段的值复制而来。
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信令消息，有关此方法的使用还有待标准化，详细内容参见IETFRFC2976。
其他扩展
其他扩展的含义如下：
• re-INVITE:用来改变参数；
•PRACK:与ACK作用相同，但是用于临时响应；
•SUBSCRIBE:该方法用来向远端端点预定其状态变化的通知；
•NOTIFY:该方法发送消息以通知预定者它所预定的状态的变化；
•UPDATE:允许客户更新一个会话的参数而不影响该会话的当前状态；
•MESSAGE:通过在其请求体中承载即时消息内容实现即时消息；
•REFER:其功能是指示接受方通过使用在请求中提供的联系鬼址信息联系第三方。
2.SIP响应消息
响应消息格式如下：
Response=Status-Line
*（general-header
I response-header
I entity-header)
CRLF
[message-body]
状态行(Status-Line)以协议版本开始，接下来是用数字表示的状态码(Status-Code)及相关的文本说明，最后以回车键结束，各个元素间用空格字符(SP)间隔，除了在最后的CRLF序列中，这一行别的地方不许使用回车或换行字符。
Status-Line=SIP-version SP Status-Code SP Reason-Phrase CRLF
SIP协议中用三位整数的状态码(StatusCode)和原因码(Reason Code)来表示对请求做出的回答。状态码用于机器识别操作，原因短语(Reason-Phrase)是对状态码的简单文字描述,用于人工识别操作。其格式如下：
Status-Code=Ixx(Informational)
I 2xx (Success)
I 3xx (Redirection)
I 4xx (Client-Error)
I 5xx (Server-Error)
I 6xx (Global-Failure)
I extension-code
状态码的第一个数字定义响应的类别，在SIP/2.0中第一个数字有6个值，定义如下：
• 1xx(Informational):请求已经收到、继续处理请求。
• 2xx(Uccess):行动已经成功地收到，理解和接受。
• 3xx(Redirection):为完成呼叫请求，还须采取进一步的动作。
• 4xx(ClientError):请求有语法错误或不能被服务器执行。客户机需修改请求，然后再重发请求。
• 5xx(ServerError):服务器出错，不能执行合法请求。
• 6xx(GlobalFailure):任何服务器都不能执行请求。
其中，Ixx响应为暂时响应(Provisionalresponse),其他响应为最终响应(FinalResponse)o
3.SIP消息头字段
SIP协议的消息头定义与HTTP在语法规则和定义上很相似。每个头字段都遵循以下格式:首先是字段名(Field Name),字段名不分大小写，后面是冒号；然后是字段值，字段值与冒号间可有多个前导空格(LWS)。其格式如下：
message-header = field-name":"[field-value]CRLF
field-name = token
field-name = token
field-value = *(field-contentILWS)
通用消息头(General–headeT)
通用头字段适用于请求消息和响应消息，包含的字段有：
general-header=Accept
I Accept-Encoding
I Accept-Language
I Call-ID
I Contact
I CSeq
I Date
I Encryption
I Expires
I From
I Organization
I Record-Route
I Timestamp
I To
I User-Agent
I Via
接下来，介绍通用头字段中各字段的含义：
• Accept,Accept-Encoding和Accept-Language字段用于客户机在请求消息中给出其可接受的响应的媒体类型、编码方式以及描述语言。用于服务器在415响应(请确认)中表明其可理解的请求消息的媒体类型、编码方式以及描述语言。
• Call-ID字段：用于惟一标识特定邀请或某个客户机的注册请求，一个多媒体会议可产生多个Call-ID不同的呼叫。
• Contact字段：给出一个URL,用户可以与此URL建立进一步的通信。
• Cseq字段：用于标识服务器发出的不同请求，若Call-ID值相同，那么Cseq值必须各不相同。
• Date字段：反映首次发出请求或响应消息的时间，重发的消息与原先的消息有相同的Data字段值。
• Encryption字段：表明内容经过了加密处理，这种加密为端到端的加密。
• Expire字段：它给出消息内容截止的日期和时间。
• From字段：所有消息中都必须有From字段，此字段给出请求的发起者。
• Organization字段：它给出发出请求或响应消息的实体所属的组织的名称。
• Record-Route字段：它给出一个全局可到达的Request-URI,用于标识代理服务器。
• Time-Stamp字段：给出客户机向服务器发出请求的时间。
• To字段：所有消息中都必须有To字段，此字段给出请求的目的收方。
• User-Agent字段：含有与发起请求的用户代理客户机有关的信息。
• Via字段：它给出请求消息迄今为止经过的路径。
实体头(Entity-header)
实体头字段用于定义与消息体相关的信息。包含的字段有：
entity-header=Content-Encoding
I Content-Length
I Content-Type
接下来，介绍实体头字段中各个字段的含义：
• Content-Encoding字段：表明消息体上添加应用的内容编码方式。
• Content-Length字段：表明消息体的大小。
• Content-Type字段：表明消息体的媒体类型。
请求头(Request・header)
请求头字段用于客户机上传附加信息到服务器，其中包括有关请求和客户机本身的信息。包含的字段有：
request-header = Authorization
I Contact
I Hide
I Max-Forwards
I Priority
I Proxy-Authorization
I Proxy-Require
I Route
I Require
I Response-Key
I Subject
接下来，介绍请求头字段中各个字段的含义：
• Authorization字段：用于用户代理向服务器鉴定自身身份。
• Hide字段：用于客户机表明其希望向后面的代理服务器或用户代理隐藏由Via字段构成的路径。
• Max-Forwards字段：表明请求消息允许被转发的次数。
• Priority字段：用于客户机表明请求的紧急程度。
• Priority-Authorization字段：用于客户机向要求身份认证的代理服务器表明自身身份。
• Proxy-Require字段：用于标识出代理必须支持的代理敏感特征。
• Route字段：决定请求消息的路由。
• Require字段：用于客户机告诉代理服务器为了让服务器正确处理请求，客户机希望服务器支持的选项。
• Response-Key 用于给出被叫方用户代理加密响应消息所采用的密钥需满足的要求。
• Subject字段：提供对呼叫的概述或表明呼叫的性质，可用于呼叫过滤。
响应头(Response-header)
响应头字段用于服务器向Request-URI指定的地址传送有关响应的附加信息。包含的字段有：
response-header=Allow
I Proxy-Authenticate
I Retry-After
I Server
I Unsupported
I Warning
I WWW-Authenticate
接下来，介绍响应头字段中各个字段的含义：
• Proxy-Authenticate字段：必须为407响应的一部分，字段中的值给出适用于Request-URI的代理的认证体制和参数。
• Retry-After字段：可用于503响应中，向发出请求的客户机表明服务预计多久以后可以启用，用于404、600、603响应中表明被叫方何时才有空。
• Server字段：含用户代理服务器处理请求所使用的软件信息。
• Unsuppoted字段：列出服务器不支持的特征。
• Warning字段：用于传递与响应状态有关的附加信息。
• -Authenticate字段：含于401响应中，指出适用于Request-URI的认证体制和参数。
各种头使用场合
各种头使用场合
每一种头都有相应的使用场合，具体如表所示。
表 头使用范围
其中，Where栏表示头可使用的地方，当为R时，表示仅可用在请求中；为r时，表示仅可用在响应中；为c时，表示将头从请求复制到响应中。
Proxy栏描述代理对头釆取的操作，当为a时，表示如果没有头，代理可以增加头；为m时，表示代理可以修改头；为d表示代理可以删除头；为I•表示代理必须能读此头，所以此头不能加密。
接下来六栏中的c表示根据具体消息来决定是否需要头，m表示必须要头；m*表示应该发送头，但是在没有头的情况下，仍应能接收消息；。表示头可选；t表示应该发送头，但是在没有头的情况下，仍应能接收消息，如果使用基于流的协议(如TCP)作为传输协议，则必须发送头；*表示如果消息体非空，需要此头；–表示头不可用。
