05 sip字段说明

SIP协议的各字段分析和各种功能的应用一、SIP字段说明
1．Request-Line
Request-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．Responses
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase
应答命令是用来回应请求命令的，状态行包含协议版本、状态码和原因描述（用文本方式描述状态）；状态码有1XX、2XX、3XX、4XX、5XX和6XX等六种，分别描述不同的内容。

3．Header Fields
Via：用来标识应答消息的返回路径，包含SIP版本、通过的路径、branch；在应答包中会看到此包经过别的路径后加进去的路径参数，如果是经过了NA T，那么里面会加上received=ip,rport=port这类的参数
Max-Forwards：用来表示这个包最多可以被传送多少跳，当此值为0还没有到达目的地时，系统会回483（Too Many Hops）；一般在含有request的源包里面带有这个字段，默认值正常的都是设置为70
User-Agent：终端设备自己填写的关于设备方面的信息，没有具体用处
From：源的display name和源的URI；&前面带的是设备号或者是主叫号码，&后面带的是proxy的地址
To：目的地的绝对地址，包含被叫display name和被叫URI；&前面带的是设备号或者是被叫号码，&后面带的是proxy的地址
Call-ID：是一个唯一的标识符，在一通呼叫中请求和应答消息中的Call-ID是唯一的Contact：包含源的URI信息，用来给响应消息直接和源建立连接用
CSeq：用来标识命令和命令顺序，用32位无符号整数来表示，要小于2**31
Expires：在注册包和注册应答包中携带，用来协商URI的有效时间，当为0的时候表示注销设备，没有Expires的时候会被系统拒绝（现在做了修改，如果没有这个字段，系统会把此值当作是3600）
Allow：允许的命令
Supported：支持的操作，例如：replace等
Content-Type：指明消息体的类型
Content-Length：指明消息体的字节大小
4．Message body
SDP协议版本
会话名，例如：SIP CALL
Connection 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 Transfer
Message 1
REFER sip:b@ SIP/2.0
Via: SIP/2.0/UDP ;branch=z9hG4bK2293940223
To: <sip:b@>
From: <sip:a@>;tag=193402342
Call-ID: 898234234@
CSeq: 93809823 REFER
Max-Forwards: 70
Refer-To: (whatever URI)
Contact: sip:a@
Content-Length: 0
Message 2
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP ;branch=z9hG4bK2293940223
To: <sip:b@>;tag=4992881234
From: <sip:a@>;tag=193402342
Call-ID: 898234234@
CSeq: 93809823 REFER
Contact: sip:b@
Content-Length: 0
Message 3
NOTIFY sip:a@ SIP/2.0
Via: SIP/2.0/UDP ;branch=z9hG4bK9922ef992-25
To: <sip:a@>;tag=193402342
From: <sip:b@>;tag=4992881234
Call-ID: 898234234@
CSeq: 1993402 NOTIFY
Max-Forwards: 70
Event: refer
Subscription-State: active;expires=(depends on Refer-To URI)
Contact: sip:b@
Content-Type: message/sipfrag;version=2.0 普通呼叫的type为：application/sdp Content-Length: 20
2．Replace的使用
过程如下图所示：
3．Early Media Applications
在SIP的Early Media中使用的是183信令来实现，如下图：
4．SIP自动callback的应用
5．用Instant Message to Transfer a Call
6．SIP Message Waiting
7．SIP Call Control in Conferencing
三、新功能
1．SigComp
the Signaling Compression (SigComp) add-on module is a solution for compressing SIP
signaling. 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 IP
addresses, 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_TOS
determines the value of the Type of Service field in the IP header of all packets that are
sent over the outgoing connections. (Supported for IPv4 addresses only.)
4．Transmitter Object
the SIP Stack uses transmitter objects for message sending. Each transaction
object 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 3515
REFER is a SIP method defined by RFC 3515 (Session Initiation Protocol
Refer Method). The REFER method indicates that the recipient of the REFER request should contact
a 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 for
REFER implementation. It replaces the previous REFER implementation and is introduced due to standard modifications.
6．Client-side forking
in previous SIP Toolkit versions, if a request was forked, the SIP Stack on the
client 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 disabling
if 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 enhancements
two 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 can
dump buffer to file or discard the buffer, for example.
9．A-synchronous DNS
DNS functionality was enhanced and is now a-synchronous, improving performance especially for
multi-session applications such as gateways and servers.
10．DNS server runtime configuration
in 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 PRACK
the application can now control the sending of PRACK/200. This is an addition to the automatic functionality available in previous versions.
12．Primitives compilation flag
this 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 services
the 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 control
some 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 availability
the 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 copied
into a consecutive buffer. The application can then save this buffer and use it when restoring the backup object.
16．Authentication enhancement
the 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 security
18．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 TCP
19．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 and
H.323
20．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 individuals
21．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 ANAT
22．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 protocol
that 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 networks
23．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 mobility
24. 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 also
lists the already existing parameters to be used as initial values
for that registry
26．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 registry
27．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 generation
28．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 logically
join an existing SIP dialog with a new SIP dialog. This primitive
can 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-normative
29．Session Initiation Protocol (SIP) Extension for Event State Publication【rfc3903】
This document describes an extension to the Session Initiation
Protocol (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 purpose
30．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 by
recipients 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 present
32．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 a
variety of features, for example: "Attended Transfer" and "Call Pickup". Note that the definition of these example features is non- Normative
33．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/MIME
Online Resources for SIP
Henning Schulzrinne’s SIP Page
/sip
and supplementary SIP and SIPPING archives:
/sipwg/drafts/
/sipping/drafts/
IP Telephony Web Page
SIP Forum
SIP Center
SIP Products at 。