SIP协议中的HEADER应用
05 sip字段说明
SIP协议的各字段分析和各种功能的应用一、SIP字段说明1．Request-LineRequest-Line = Method SP Request-URI SP SIP-Version包含method名字、一个Request-URI和一个用空格隔开的协议版本号。
Method包含SIP协议的6种命令：Register、Invite、ACK、Cancel、BYE和Options；Request-URI：标注被叫的号码或者是名字以及服务器的地址或者是URI地址；SIP-Version：在请求消息和应答消息中都包含有SIP的协议版本号，一般是“SIP/2.0”。
2．ResponsesStatus-Line = SIP-Version SP Status-Code SP Reason-Phrase应答命令是用来回应请求命令的，状态行包含协议版本、状态码和原因描述（用文本方式描述状态）；状态码有1XX、2XX、3XX、4XX、5XX和6XX等六种，分别描述不同的内容。
3．Header FieldsVia：用来标识应答消息的返回路径，包含SIP版本、通过的路径、branch；在应答包中会看到此包经过别的路径后加进去的路径参数，如果是经过了NA T，那么里面会加上received=ip,rport=port这类的参数Max-Forwards：用来表示这个包最多可以被传送多少跳，当此值为0还没有到达目的地时，系统会回483（Too Many Hops）；一般在含有request的源包里面带有这个字段，默认值正常的都是设置为70User-Agent：终端设备自己填写的关于设备方面的信息，没有具体用处From：源的display name和源的URI；&前面带的是设备号或者是主叫号码，&后面带的是proxy的地址To：目的地的绝对地址，包含被叫display name和被叫URI；&前面带的是设备号或者是被叫号码，&后面带的是proxy的地址Call-ID：是一个唯一的标识符，在一通呼叫中请求和应答消息中的Call-ID是唯一的Contact：包含源的URI信息，用来给响应消息直接和源建立连接用CSeq：用来标识命令和命令顺序，用32位无符号整数来表示，要小于2**31Expires：在注册包和注册应答包中携带，用来协商URI的有效时间，当为0的时候表示注销设备，没有Expires的时候会被系统拒绝（现在做了修改，如果没有这个字段，系统会把此值当作是3600）Allow：允许的命令Supported：支持的操作，例如：replace等Content-Type：指明消息体的类型Content-Length：指明消息体的字节大小4．Message bodySDP协议版本会话名，例如：SIP CALLConnection Information：Connect Network Type现在只有IN（Internet）；Connection Address Type 现在只有IP4和IP6两种；Connection Address可以为单播地址或多播组地址，如果是多播组地址还必须有一个生存时间（TTL）值，如：c＝IN IP4 224.2.1.1/127，表示TTL＝127秒Time Description：标明会话的开始时间和终止时间Media Description：包含媒体类型、端口、传送层和格式列表4部分，传送层描述的是Media Protocol，例如：RTP/A VP表示IETF RTP协议，udp表示UDP协议；格式列表列举出支持的codec类型Media Attribute：有两种描述方式：a=<属性>或a=<属性>：<值>，第一种形式称为特殊属性，无须规定数值，如：a=recvonly表示该媒体信道是“只收”信道；第二种形式称为数值属性，例如：Media Attribute Value：18 G729/8000这种形式二、一些功能信令流程1．Refer（Transfer业务）命令的使用对于SIP信令的Transfer应用，主要用到的命令就是Refer，在B挂机后会向系统发出Refer命令，系统回应一个Accepted（202）命令，然后系统再会一个Notify命令，B回应200 OK后，过程结束，具体的信令流程和信令内容请查看SIP Transfer文档，下面列举如下：Attended Call TransferMessage 1REFER sip:b@ SIP/2.0Via: SIP/2.0/UDP ;branch=z9hG4bK2293940223To: <sip:b@>From: <sip:a@>;tag=193402342Call-ID: 898234234@CSeq: 93809823 REFERMax-Forwards: 70Refer-To: (whatever URI)Contact: sip:a@Content-Length: 0Message 2SIP/2.0 202 AcceptedVia: SIP/2.0/UDP ;branch=z9hG4bK2293940223To: <sip:b@>;tag=4992881234From: <sip:a@>;tag=193402342Call-ID: 898234234@CSeq: 93809823 REFERContact: sip:b@Content-Length: 0Message 3NOTIFY sip:a@ SIP/2.0Via: SIP/2.0/UDP ;branch=z9hG4bK9922ef992-25To: <sip:a@>;tag=193402342From: <sip:b@>;tag=4992881234Call-ID: 898234234@CSeq: 1993402 NOTIFYMax-Forwards: 70Event: referSubscription-State: active;expires=(depends on Refer-To URI)Contact: sip:b@Content-Type: message/sipfrag;version=2.0 普通呼叫的type为：application/sdp Content-Length: 202．Replace的使用过程如下图所示：3．Early Media Applications在SIP的Early Media中使用的是183信令来实现，如下图：4．SIP自动callback的应用5．用Instant Message to Transfer a Call6．SIP Message Waiting7．SIP Call Control in Conferencing三、新功能1．SigCompthe Signaling Compression (SigComp) add-on module is a solution for compressing SIPsignaling. Since SIP messages are text based, they are not optimized in terms of size. For example, typical SIP messages range from a few hundred bytes to two thousand bytes or more (RFC 3261). With the planned usage of these protocols in wireless and cellular handsets, and as part of the 3GPP (Third Generation Partnership Project) requirements for IMS (IP Multimedia Subsystem), the large message size is problematic and message compression is mandatory.2．DLA (Dynamic Local Address)enables the dynamic opening and closing of the local IPaddresses, which are used for request sending and reception, at any moment of the SIP Stack life cycle. This feature is typically used with multihomed host. DLA is used for broadband (DSL, cable), as well as wireless and cellular networks, to support handoffs and IP address changes by service providers.3．IP_TOSdetermines the value of the Type of Service field in the IP header of all packets that aresent over the outgoing connections. (Supported for IPv4 addresses only.)4．Transmitter Objectthe SIP Stack uses transmitter objects for message sending. Each transactionobject holds a single transmitter object and uses it to send SIP messages and message retransmissions. The application can use this new object for sending an out-of-scope request or response without using the Transaction layer.5．REFER RFC 3515REFER is a SIP method defined by RFC 3515 (Session Initiation ProtocolRefer Method). The REFER method indicates that the recipient of the REFER request should contacta third party using the contact information provided in the REFER request. RFC 3515 provides a mechanism allowing the party that is sending the REFER to be notified of the outcome of the referenced request with a NOTIFY request. This implementation uses subscription objects forREFER implementation. It replaces the previous REFER implementation and is introduced due to standard modifications.6．Client-side forkingin previous SIP Toolkit versions, if a request was forked, the SIP Stack on theclient side automatically connected the first established dialog, and did not allow the application to choose a different dialog or connect multiple dialogs. In the current version, the Call-leg and Subscription modules were enhanced to allow this flexibility.7．Merging disablingif a proxy forks a request and eventually the two requests are terminated at the same User Agent Server (UAS), the UAS needs to merge them into one request. There are cases where the UAS is a gateway and therefore will want to avoid the message merging. This flexibility is currently available.8．Transport Layer enhancementstwo functionalities were added. An application can now block incoming connections even before data was received on them .This lets the application implement a white/black IP address list and handle the denial of service attacks in a better way. Access to the incoming raw buffer so that the application candump buffer to file or discard the buffer, for example.9．A-synchronous DNSDNS functionality was enhanced and is now a-synchronous, improving performance especially formulti-session applications such as gateways and servers.10．DNS server runtime configurationin some cases, it is required to change the DNS server that is being used at runtime. This is now possible via the SIP Toolkit APIs.11．Manual PRACKthe application can now control the sending of PRACK/200. This is an addition to the automatic functionality available in previous versions.12．Primitives compilation flagthis new compilation flag replaces the EXTRA_LEAN compilation flag. It removes the dialog layer, allowing application to work directly above the Transaction layer. Additionally, it removes specific support of certain headers. The application can still use these headers by adding specific support in the application itself.13．Middle Layer for low-level servicesthe RADVISION operating system abstraction layer was wrapped and some of its APIs are now exposed so the application can use services such as timers and select.14．Via header controlsome implementations, such as when using a STUN/TURN server, require manual modification of the Via header after DNS was completed. This control and flexibility is now possible.15．Subscription high availabilitythe RADVISION SIP Stack provides a store and restore mechanism that enables the application to back up subscriptions in the ACTIVE state. Backing up subscriptions lets application developers implement redundancy capabilities in their systems, allowing back-up systems to “take over” when the primary system goes down. When storing an active subscription, all of the subscription parameters are copiedinto a consecutive buffer. The application can then save this buffer and use it when restoring the backup object.16．Authentication enhancementthe authentication mechanism enables a User Agent Client (UAC) to prove authenticity to servers or proxies which require authentication. The SIP Stack supports SIP authentication using the HTTP Digest Scheme as described in RFC 3261 and RFC 2617. In the current version, support of the “auth-int” quality of protection (qop) was added. For server-side authentication, only “auth” qop is supported.17．Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP) 【rfc4189】A Session Initiation Protocol (SIP) User Agent (UA) does not always trust all intermediaries in its request path to inspect its message bodies and/or headers contained in its message. The UA might want to protect the message bodies and/or headers from intermediaries, except those that provide services based on its content. This situation requires a mechanism called "end-to-middle security" to secure the information passed between the UA and intermediaries, which does not interfere with end-to-end security. This document defines a set of requirements for a mechanism to achieve end-to-middle security18．The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP) 【rfc4168】This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport mechanism between SIP (Session Initiation Protocol) entities. SCTP is a new protocol that provides several features that may prove beneficial for transport between SIP entities that exchange a large amount of messages, including gateways and proxies. As SIP is transport-independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP19．Session Initiation Protocol (SIP)-H.323 Interworking Requirements 【rfc4123】This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function (SIP-H.323 IWF) that will allow the interworking between SIP andH.32320．Transcoding Services Invocation in the Session Initiation Protocol (SIP)Using Third Party Call Control (3pcc)【rfc4117】This document describes how to invoke transcoding services using Session Initiation Protocol (SIP) and third party call control. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals21．Usage of the Session Description Protocol (SDP)Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)【rfc4092】This document describes how to use the Alternative Network Address Types (ANAT) semantics of the Session Description Protocol (SDP) grouping framework in SIP. In particular, we define the sdp-anat SIP option-tag. This SIP option-tag ensures that SDP session descriptions that use ANAT are only handled by SIP entities with ANAT support. To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT22．Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP) 【rfc4083】The 3rd-Generation Partnership Project (3GPP) has selected Session Initiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of Release 5 of the 3GPP specifications. Although SIP is a protocolthat fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this document, we express the requirements identified by 3GPP to support SIP for Release 5 of the 3GPP IMS in cellular networks23．Update to the Session Initiation Protocol (SIP)Preconditions Framework【rfc4032】This document updates RFC 3312, which defines the framework for preconditions in SIP. We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility24. Interworking SIP and Intelligent Network (IN) Applications【rfc3976】Public Switched Telephone Network (PSTN) services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network (IN). This document addresses means to support existing IN services from Session Initiation Protocol (SIP) endpoints for an IP-host-to-phone call.The call request is originated on a SIP endpoint, but the services to the call are provided by the data and procedures resident in the PSTN/IN. To provide IN services in a transparent manner to SIP endpoints, this document describes the mechanism for interworking SIP and Intelligent Network Application Part (INAP)25．The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP) 【rfc3969】This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) and SIPS Uniform Resource Identifier (URI) parameters, and their values. It alsolists the already existing parameters to be used as initial valuesfor that registry26．The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)【rfc3968】This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) header field parameters and parameter values. It also lists the already existing parameters and parameter values to be used as the initial entries for this registry27．Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP) 【rfc3960】This document describes how to manage early media in the Session Initiation Protocol (SIP) using two models: the gateway model and the application server model. It also describes the inputs one needs to consider in defining local policies for ringing tone generation28．The Session Initiation Protocol (SIP) "Join" Header 【rfc3911】This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logicallyjoin an existing SIP dialog with a new SIP dialog. This primitivecan be used to enable a variety of features, for example: "Barge-In", answering-machine-style "Message Screening" and "Call Center Monitoring".Note that definition of these example features is non-normative29．Session Initiation Protocol (SIP) Extension for Event State Publication【rfc3903】This document describes an extension to the Session InitiationProtocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is for the publication of presence information. The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose30．Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format【rfc3893】RFC 3261 introduces the concept of adding an S/MIME body to a Session Initiation Protocol (SIP) request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an ’authenticated identity body’, a digitally-signed SIP message, or message fragment. A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs byrecipients of SIP messages with such bodies are also given 31．The Session Initiation Protocol (SIP) Referred-By Mechanism【rfc3892】The Session Initiation Protocol (SIP) REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI,the referee will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present32．The Session Initiation Protocol (SIP) "Replaces" Header 【rfc3891】This document defines a new header for use with Session Initiation Protocol (SIP) multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable avariety of features, for example: "Attended Transfer" and "Call Pickup". Note that the definition of these example features is non- Normative33．S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)【rfc3853】RFC 3261 currently specifies 3DES as the mandatory-to-implement ciphersuite for implementations of S/MIME in the Session Initiation Protocol (SIP). This document updates the normative guidance of RFC 3261 to require the Advanced Encryption Standard (AES) for S/MIMEOnline Resources for SIPHenning Schulzrinne’s SIP Page/sip and supplementary SIP and SIPPING archives:/sipwg/drafts//sipping/drafts/IP Telephony Web PageSIP ForumSIP CenterSIP Products at 。
sip协议错误代码code大全
1)100 Trying说明caller正在呼叫，但还没联系上callee。
180 Ringing 说明callee已经被联系上,callee的铃正在响.收到这个信息后，等待200 OK2)181 Call is being forwarded说明call被重新路由到另外一个目的地3)182 Queued说明callee当前是不可获得的，但是对方不想直接拒绝呼叫，而是选择放在呼叫队列中4)183 Session progress用来警告caller频段(inband)错误。
当从PSTN收到一个ISDN消息，SIP gateway 产生183 Session progress 。
2xx successful Responses200 OK3xx Redirection Responses5)300 Multiple choices说明呼叫的地址被解析成多个地址，所有的地址都被提供出来，用户或用户代理可以从中选择联系哪个。
6)301 Moved permanently说明指定地址的用户已经永远不可用，在头中已经用另外一个地址替换了.7)302 Moved temporarily说明指定地址的用户临时不可用，在头中已经用另外一个地址代替了.8)305 Use proxy说明caller必须用一个proxy来联系callee.9)380 Alternative service说明call不成功，但是可选择其他的服务4xx Request Failure Responses10)400 Bad Request说明由于非法格式，请求不能被理解。
11)401 Unauthorized说明请求需要用户认证。
12)402 Payment required说明完成会话需要付费.13)403 Forbidden说明server已经收到并能理解请求但不提供服务。
14)404 Not Found说明server有明确的信息在指定的域中用户不存在.15)405 Method Not Allowed说明请求中指定的方法是不被允许的。
[rfc3261]sip-viaheader
![[rfc3261]sip-viaheader](https://img.taocdn.com/s3/m/3b06afac970590c69ec3d5bbfd0a79563c1ed46d.png)
[rfc3261]sip-viaheader
在很多情况下，sip并⾮直达⽬标主机的，⽽是要经过很多中间节点服务器。
在request消息中，via头域表⽰当前已⾛过的节点（每经过⼀个节点，添加⼀个via头）；在response消息中，via头域表⽰消息接下来还要经过的节点（相对于request消息原路返回，每经过⼀个节点删除⼀个via头）。
via的基本格式是：via头域标识（就是"via"）:头域值
当前节点加⼊的via头域值应包含当前节点⼀句的sip版本和⽹络传输协议；当前节点的域名或ip地址；端⼝号；以及若⼲可选的属性项。
属性项与之前项⽬及属性项之间以“;”隔开。
下⾯是⼀个典型via头域的例⼦：
via:SIP/2.0/UDP 192.0.2.1:506
via的可选属性项⼀般有这么⼏个："maddr", "ttl", "received", and "branc" 下⾯分别介绍它们的含义和⽤法。
The Via header maddr, ttl, and sent-by components will be set when
the request is processed by the transport layer (Section 18).。
SIP协议原理及应用
Sip:alice@10.1.2.3
Sip:alice@;method=REGISTER
一.4
描述会话信息的协议，包括会话的地址、时间、媒体和建立等信息
一.4.1
会话名和目的
会话激活的时间段
构成会话的媒体
接收这些媒体所需的信息（地址、端口、格式）
会话所用的带宽信息（任选）
会话负责人的联系信息（任选）
二.1.1
SIP协议是一个Client/Sever协议。SIP端系统包括用户代理客户机（UAC）和用户代理服务器（UAS），其中UAC的功能是向UAS发起SIP请求消息，UAS的功能是对UAC发来的SIP请求返回相应的应答。在SS（SoftSwitch）中,可以把控制中心SoftSwitch看成一个SIP端系统。
Application Server:运行和管理增值业务的平台，与SoftSwitch用SIP进行通信。
Media Server:提供媒体和语音资源的平台，同时与Media Gateway进行RTP流的传输。
使用SIP作为SoftSwitch和Application Server之间的接口，可以实现呼叫控制的所有功能。同时SIP已被SoftSwitch接受为通用的接口标准，从而可以实现SoftSwitch之间的互连。
sip中的subscribe和notify扩展应用技术
sip中的subscribe和notify扩展应用技术摘要：会话启动协议研究工作组提出3种协议功能扩展方式：方法扩展、头部扩展和消息体扩展。
文章深入探讨了包含这3种扩展方法的事件通告机制，给出了基于这一机制的自动回叫业务实例，并讨论了该机制的安全性。
关键词：会话启动协议；事件通告机制；IP通信网协议；增值业务Abstract:IETF SIPPING (Session Initiation Protocol Investigation) working group has proposed 3 approaches to extend the base functions of SIP: method extension, header extension and body extension. The article goes deeply into the SIP event notification mechanism involving these three approaches. An example is given to illustrate the automatic \"call-back\" service based on this mechanism. Considerations on the security of the mechanism are also included.Key words:SIP; event notification mechanism; IP communication network protocol; value-added service众所周知，会话启动协议(SIP)是建立、修改和终结多媒体会话或呼叫的应用层控制协议。
自1999年至今，会话启动协议基础协议已从最初的RFC 2543发展到了现在的RFC 3261，协议内容得到了很大的扩充，其描述的信令框架也更加完善。
[SIP01]SIPHeaderFields里面各字段用途
![[SIP01]SIPHeaderFields里面各字段用途](https://img.taocdn.com/s3/m/60b1af64ae1ffc4ffe4733687e21af45b307fec8.png)
[SIP01]SIPHeaderFields⾥⾯各字段⽤途INVITE sip:bob@ SIP/2.0Via: SIP/2.0/UDP ;branch=z9hG4bK776asdhdsMax-Forwards: 70To: Bob <sip:bob@>From: Alice <sip:alice@>;tag=1928301774Call-ID: a84b4c76e66710@CSeq: 314159 INVITEContact: <sip:alice@>Content-Type: application/sdpContent-Length: 142(Alice’s SDP not shown)1. ViaVia: SIP/2.0/UDP ;branch=z9hG4bK776asdhds1.1 ⽤来标识Responeses消息的返回路径（todo:各router的区别），包含SIP版本，通过的路径，branch;每个Request-Line（请求消息）路过代理Server时都会记录，然后原路返回;1.2 ⽤来检查路由环，因为每经过server都会把他放在via⾥⾯，每都⼀个Server⾥先检查via头⾥⾯有没有这个server如果有，出现了路由环Spiral：Alice calls , 把信息传给Bob的PC，返回时⼜转给了,这样⼜回到了 proxy上，所以这不是⼀个死循环【PS: 和loop不⼀样】;1.3 Branch是⼀个事务ID（Transaction ID），⽤于区分同⼀个Client所发起的不同Transaction，它不会对未来的request 或者是response造成影响，对于遵循RFC3261规范的实现，这个branch参数的值必须⽤magic cookie”z9hG4bK”打头. 其它部分是对“To, From, Call-ID头域和Request-URI”按⼀定的算法加密后得到;1.4 与CallID的区别：CallID是⽤来在session层，branch⽤在transation层Call-ID contains a globally unique identifier for this call,generated by the combination of a random string and the softphone's host name or IP address. The combination of the To tag, From tag,and Call-ID completely defines a peer-to-peer SIPrelationship between Alice and Bob and is referred to as a dialog.2.Max-ForwardsMax-Forwards: 70serves to limit the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop.2.1 ⽤于表⽰这个包最多可以传送多少跳，当Max-Forwards==0&&没到达⽬的地时，系统会返回483(Too many hops);⼀般会在有Request的包⾥⾯;2.2 默认为70;2.3 原理：每经过⼀跳时【Todo:⼀个代理？】都会减⼀向下⼀跳传去.3. ToTo: Bob <sip:bob@>3.1 ⽬的地的绝对地址，包含补叫的display name 和被叫URL,&前⾯带的是设备号或被叫号码，&后带的是Proxy地址;3.2 这个地址⽤于给Proxy们找路由的,⼀般会经过Proxy⼀步步定位到最精确的位置【改为其它精确地址】.4. FromFrom: Alice <sip:alice@>;tag=19283017744.1 格式与To⼀样，表⽰Caller的绝对地址，但是会加⼀个Tag标签；4.2 Tag 他是⼀个随机码【Todo:可不可变？】⽤于 identification purposes.5. Call-IDCall-ID:5.1 Call-ID由本地设备（Client)⽣成，全局唯⼀，每次呼叫这个值唯⼀不变,与其它的session是不同的;5.2 对于⽤户发出Invite消息，本地会⽣成From Tag 和Call-ID全局唯⼀码，被叫⽅代理⽣成 To tag全局唯⼀码，这三个随机码做为整个对话中对话标识（dialog indentifier).6. CseqCSeq: 314159 INVITE6.1 ⼜叫Command Seqence（命令队列）,每发⼀个新的请求，这个数就会+1，最⼤2*31；6.2 ⽤来标识命令和命令顺序,整数部⽤于同⼀session(CallID决定)中不同的请求排序，它会与将请求和应答想匹配：⽐如：Alice发1 Invite 没返回--->再发 2 Invite--->没返回--->再发3 Invite--->这时返回了2 Invite就知道是第2个请求得到了响应（这个数是⼀直递增1的）; 【因为在同⼀个transtation⾥⾯，所以invite其它消息都没有变化的，就⽤cseq来区别了】- Ack的CSeq:这个是与Invite⾥⾯的⼀样的，这使代理为⾮成功最终应答产⽣Ack时不⽤再建⽴新的CSeq,保证唯⼀性，只⽤client代理创建哦;- Cancel的CSeq:这个也是与Invite⾥⾯的⼀样的，这也是为什么CSeq⾥⾯要加Method的原因，如果不加，client就不知道这个是cancel还是invite的应答了;以上⼏个字段是所有 SIP 消息体所必须的，其它头字段有些是可选的，有些在特定请求也是必须7. ContactContact: <sip:alice@>Contact contains a SIP or SIPS URI that represents a direct route to contact Alice, usually composed of a username at a fully qualified domain name (FQDN). While an FQDN is preferred, many end systems do not have registered domain names, so IP addresses are permitted. While the Via header field tells other elements where to send the response, the Contact header field tells other elements where to send future requests.7.1 包含源的URI信息，⽤来给响应消息直接和源建⽴连接⽤;7.2 注意和From的差别：这个是可以让被叫⽅Bob直接找到呼叫⽅的绝对地址。
SIP消息头域的说明
SIP消息头域的说明(转)1 general-header类：为描述消息基本属性的通用头域，可用于请求消息或响应消息；通用头域的域名只有在协议版本改变时才可有效地扩展。
不过，通信中的所有方均认为是“通用头域”的新的头域也可认为是通用头域。
不被认可的头域作为实体头域。
1.1 Call-IDCall-ID通用头域唯一标识一个特定的请求或者一个特定客户的所有登记。
来自同一个客户的所有的登记应该使用同样的Call-ID头值，至少是在同一个重新启动的循环中。
注意到单个的多媒体会议会产生不同Call-ID的几个呼叫，例如，用户多次邀请一个单个的私人加入同一个会议。
对于一个INVITE请求。
主叫方用户代理服务器不应该警告用户，如果用户先前已经对INVITE请求中的Call-ID 作出了响应。
如果用户已经是会议的一个成员，同时包含在会话描述中的会议参数并未改变，那么主叫方用户代理服务器可以接受此呼叫，而不管Call-ID。
对于一个已存在的Call-ID或者会话的邀请可能改变会议的参数。
一个客户应用可以决定向用户简单地指示会议参数已经改变，可以自动接受邀请或者可能需要用户的确认。
使用几个不同的Call-ID可以邀请一个用户加入同一个会议或者呼叫。
如果需要的话，可以使用在会话描述中的标识来检测此副本。
例如，SDP的“o”域中包含了会话标识和版本号。
REGISTER和OPTIONS方式使用Call-ID值来精确匹配请求和响应。
一个单个的客户发布的所有的REGISTER请求应该使用同一个Call-ID，至少在同一个有效循环中。
Call-ID = (“Call-ID” | “i”)”:”local-id”@”hostLocal-id = 1*urici是Call-ID的缩写形式。
“host”应该是一个真正的域名或者是一个全球性的IP地址。
如此，”local-id”应该是一个由URI字符组成的标识，此标识在”host”中是唯一的。
sip协议报文类型
sip协议报文类型SIP（Session Initiation Protocol）是一种应用层协议，常用于建立、修改和结束实时多媒体会话，例如语音通话、视频通话和即时消息。
SIP定义了一系列的消息类型，用于在用户终端之间传递信息和控制会话的各个方面。
下面将介绍SIP协议中的一些常用的报文类型。
1.请求消息（Request）:SIP协议中的请求消息用于向服务器发送请求，以请求某种操作或服务。
常见的请求消息包括：- INVITE：用于建立一次会话或邀请其他终端参与会话。
- ACK：用于回复对INVITE请求的确认。
- BYE：用于结束会话。
- REGISTER：用于用户的注册和注销。
2.响应消息（Response）:SIP协议中的响应消息是服务器对请求消息的回应。
常见的响应消息包括：- 1xx：表示请求已被接收，需要进一步处理。
- 2xx：表示请求已成功完成。
- 3xx：表示请求被重定向到其他服务器或终端。
- 4xx：表示请求包含错误，无法完成。
- 5xx：表示服务器出现错误，无法完成请求。
- 6xx：表示服务器无法处理请求。
3.媒体描述消息（SDP）:SDP（Session Description Protocol）用于描述会话中的媒体流信息，如编解码器、传输协议、媒体格式等。
SIP协议中的媒体描述消息使用SDP来描述媒体流的相关信息。
4.信息消息（INFO）:INFO消息用于向会话中的参与者传递一些附加的信息，如DTMF信号、键盘输入等。
5.订阅/通知消息（SUBSCRIBE/NOTIFY）:SUBSCRIBE消息用于向服务器请求订阅某种事件，如其他用户的状态变化。
服务器在事件发生时，会使用NOTIFY消息通知订阅者。
6.选项消息（OPTIONS）:OPTIONS消息用于向服务器查询对某个请求支持的能力、状态或配置。
7.重定向消息（REDIRECT）:重定向消息用于向用户提供其他服务器或终端的地址，以便进一步处理请求。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
SIP协议中的HEADER应用
SIP（会话初始化协议）是一种用于控制、启动、修改和终止多媒体
会话的协议。
在SIP中，会话参与者之间进行通信和交流的方式是通过消
息交换。
在SIP消息中，头部（Header）扮演了非常重要的角色，包含了
关键信息以及用于控制和路由会话的参数。
在下面的文章中，我们将探讨SIP协议中头部的应用。
1.请求方法头部：SIP中的请求方法用于指示消息的目的和目的地。
请求方法头部包含了SIP消息的类型，例如INVITE（邀请）、ACK（确认）、BYE（结束会话）等，用于控制和路由会话的不同阶段。
2. 响应状态头部：SIP中的响应状态头部包含了响应消息的状态码
和原因短语。
状态码用于指示请求的执行结果，例如200 OK表示请求成功，404 Not Found表示请求资源不存在等。
响应状态头部用于在SIP会
话中传递执行结果和错误信息。
3.路由头部：SIP中的路由头部用于指示消息的路由路径。
路由头部
包含了一系列URI（统一资源标识符）地址，表示消息在会话过程中经过
的路由器和代理服务器。
路由头部的作用是确保消息能够在网络中正确地
传递和到达目的地。
5.会话描述头部：SIP中的会话描述头部用于指示会话的特性和参数。
会话描述头部包含了一系列SDP（会话描述协议）参数，用于描述会话的
音频、视频和其他多媒体参数。
会话描述头部的作用是确保会话能够正确
地被初始化和修改。
6.隐私和安全头部：SIP中的隐私和安全头部用于指示消息的隐私和
安全要求。
隐私头部包含了一系列指示消息的隐私级别和策略的参数，安
全头部包含了一系列指示消息的安全级别和策略的参数。
这两个头部用于
确保消息的隐私和安全性。
7.事件通知头部：SIP中的事件通知头部用于指示事件的发生和通知
的接收者。
事件通知头部包含了一系列指示事件类型和通知方式的参数。
事件通知头部的作用是确保事件能够正确地发生和被通知。
8.权限和控制头部：SIP中的权限和控制头部用于指示消息的权限和
控制要求。
权限头部包含了一系列指示消息的权限级别和策略的参数，控
制头部包含了一系列指示消息的控制方式和权限要求的参数。
这两个头部
用于确保消息的权限和控制性。
总结起来，SIP协议中的头部扮演着非常重要的角色，包含了关键信
息以及用于控制和路由会话的参数。
不同类型的头部用于传递不同的信息，例如请求方法头部用于指示消息的类型，响应状态头部用于传递执行结果
和错误信息等。
通过对头部的正确应用和解析，可以确保SIP会话能够正
确地初始化、控制和终止。