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）:重定向消息用于向用户提供其他服务器或终端的地址，以便进一步处理请求。
sip协议的6种信令及功能
SIP协议的6种信令及功能1. 介绍SIP（Session Initiation Protocol，会话初始协议）是一种基于文本的应用层协议，用于建立、修改和终止IP电话会话，以及多媒体会话，如视频会议和实时消息传递等。
SIP协议基于客户端/服务器模型，使用请求/应答机制进行通信。
本文将介绍SIP协议的6种重要信令及其功能。
2. INVITEINVITE是SIP协议中最重要的信令之一，用于建立一个会话。
它向被呼叫方发出请求，邀请其参与会话。
INVITE信令的功能如下：•呼叫建立：INVITE信令将呼叫请求发送给被呼叫方。
被呼叫方可以根据请求确定是否接受呼叫，并选择合适的媒体类型和编解码器配置。
•会话描述：INVITE信令携带有关会话的描述信息，如媒体类型、编解码器选择等。
被呼叫方可以通过会话描述信息确定如何处理该会话。
•媒体协商：INVITE信令可以用于协商会话的媒体参数，如请求特定的音频编码或视频分辨率。
3. REGISTERREGISTER信令用于用户注册，将用户的地址信息注册到服务器。
REGISTER信令的功能如下：•用户注册：REGISTER信令向SIP服务器注册用户的地址信息。
这使得其他用户可以通过其地址信息找到该用户并向其发起呼叫。
•呼叫重定向：SIP服务器可以根据用户的注册信息将来电转发到用户的当前位置。
如果用户更改了IP地址或网络位置，服务器可以将呼叫重定向到新位置。
4. ACKACK（Acknowledgment）信令用于确认会话建立请求的成功接收。
ACK信令的功能如下：•确认请求：ACK信令用于确认对INVITE信令的接收。
被呼叫方应在接收到INVITE后发送ACK信令，以便通知呼叫发起方会话建立成功。
•可靠传输：ACK信令的发送确保会话建立请求的可靠传输，以防止请求丢失或重复发送。
5. BYEBYE信令用于终止会话，即结束通话或会议。
BYE信令的功能如下：•会话终止：BYE信令向对方发送终止请求，以结束当前的会话。
SIP协议介绍(RFC3261)
》由代理服务器并行分发的请求，其Cseq值相同。
20
主要头部字段
Via 》请求消息经过的路径，用于响应的发送。响应和请求必须走相同的路
径。Branch参数用于识别事务。
Max_Forward 》请求的最大转发次数 Contact 》后续请求发送的目的地 Record_Route 》用于标识prxoy，指定后续消息必须经过该proxy Route
17
SIP消息的格式
SIP 消 息＝ 起 始 行 *消 息 头 部（1 个 或 多 个 头 部） CRLF ( 空 行 ) 〖 消息体〗
18
SIP消息格式
请求的起始行 Request-Line = Method SP Request-URI SP SIP-Version CRLF 响应的起始行 Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
协收到的协求消息协行协和协理后协协协其他的服协用于存放sip协重定向服协器或proxy提供用协一或者11sip接收sip协求把协求中的原地址映射协零个重定向服协器不协起自己的呼叫不协送协3xx协协行重定向12sipsipproxyserverredirectserverregisterserverserver可共存于一协协也可以分布在不同的物理协sip服协器完全是协协件协协可以根据需要proxyserverredirectserver角色不是固定不协的一个ua叫中可以是uac也可以是uasserver是一个sip协公共协源协信息咨协所采用的协协不是sip而是其lightdirectoryaccessprotoco呼叫和媒控制信息同协协送15sip协送和接收sip消息匹配事协状proxy外每个sip16sip2xx成功3xx重定向6xx全局协协ack用于invite的register注册17sipsip事协包括一协求和其中协包括invite事协协包括invite协求的2xxsipsip协求的起始行requestlinemethodsprequesturispsipversioncrlfsipversionspstatuscodespreasonphrasecrlf20协求的协协接收者totagfromtagcallid特定邀协或注的唯一协协cseq相同的callid协但不同协求方法协部或消息cseq序号invite协求相同bye协求的cseq协协大于invitecseq协相同
SIP协议中的HEADER应用
GreenNET
2013-7-11
深圳市格林耐特通信技术有限公司
头域概要, P--Z
where enc. e-e ACK BYE CAN INV OPT REG _______________________________________________________________ Proxy-Authenticate 407 n h o o o o o o Proxy-Authorization R n h o o o o o o Proxy-Require R n h o o o o o o Priority R c e o Require R e o o o o o o Retry-After R c e o Retry-After 404,480,486 c e o o o o o o 503 c e o o o o o o 600,603 c e o o o o o o Response-Key R c e o o o o o Record-Route R h o o o o o o Record-Route 2xx h o o o o o o Route R h o o o o o o Server r c e o o o o o o Subject R c e - o Timestamp g e o o o o o o To gc(1) n e m m m m m m Unsupported 420 e o o o o o o User-Agent g c e o o o o o o Via gc(2) n e m m m m m m Warning r e o o o o o o WWW-Authenticate 401 c e o o o o o o
GreenNET
SIP 协议原理和应用
1 INVITE 2 100 Tring 3 INVITE 4 100 Tring 5 180 Ring 6 180 Ring 7 200 OK 8 200 OK 9 ACK 10 ACK Media Stream 11 BYE 12 200 OK 13 BYE 14 200 OK
培训大纲
• • • • •
SIP 概述 SIP 协议模型 SIP 基本消息及流程 SIP 应用模式 SIP vs H.323
Part 1: SIP 概述
Why SIP
• 众多的多媒体应用，众多通信协议，为何 SIP 越 来越流行？
实例：sip 被 IMS/NGN/3GPP/… 选为信令协议
• SIP ：是否一旦拥有，别无所求？
SIP 基本消息流程—注册
• 设备（用户）告知注册服务器其最新地址/SIP URI 等信息。 • 用于用户定位。
UA 1 REGISTER 2 401 Unauthorized 3 REGISTER 4 200 OK Registrar
SIP 基本消息流程—点对点呼叫
• 三次握手。保证会话双方都能确知 • 不经过Proxy 的情况如图所示
SIP 消息实例
• 见课件文档
SIP 消息扩展
• 消息类型可扩展：如 MESSAGE/INFO • 消息头可扩展：定义语法和语义
Part 4: SIP 应用模式
SIP 应用模式
1. 2. 3.
确定业务功能 确定各业务功能采用的 SIP 消息（标准或扩展） 确定业务功能的协议语法及语义
SIP 应用实例
SIP 概况
• SIP（Session Initiation Protocol，会话初始化 协议 ）, IETF 提出并主持研究的信令控制协议 • 按 OSI 七层协议模型，属于会话层 • 控制 IP 网络上多媒体应用会话过程，包括创建、 修改、终止等
SIP协议中的用户号码和认证名
SIP协议中的⽤户号码和认证名认证名⽤来认证（由特定的认证算法，如MD5），注册名⽤来注册（会体现在报⽂中）举个例⼦: "xzhbupt"<sip:xzh@>,xzh2002就是Display name,这个可以由⽤户⾃由更改,好⽐QQ呢称xzh就是username 注册时⽤的名字认证的⽤户名在这⾥体现不出来,他只出现在含有认证信息的请求报⽂中,⼀般是与username保持⼀致,也可以不⼀致.⽐如注册时返回401,那么你在进⾏重新注册时会在www_authxxxxx⾥⾯写上认证⽤户名关于Request-URI和To字段中的URIRequest URI和To可以不⼀样，AS以及Proxy可以加以限制。
应答消息的原则上是不改变from,to,recordRoute,Route等头域，还要加上toTag,contact,以及其它的扩展头域。
然后按照via 来返回。
Transaction与dialog有什么区别Transaction:维护hop to hop状态，包括⼀个请求和其触发的所有响应，包括若⼲暂时响应和⼀个最终响应。
⽣命周期从请求⽬前只有invite和subscribe请求会触发dialog。
其⽣命周期贯穿⼀产⽣到收到最终响应。
Dialog：维护peer to peer状态，⽬前只有个端到端会话的始终。
PUBLIC和NOTIFY有什么不⼀样Notify是服务器发送给客户端的，可能客户端在启动时并没有状态；Publish是客户端发送给服务器端的，是将⼀些状态报告给服务器端。
sip dialog和session之间的区别和联系session有两种含义，⼀种是传统意义上的RTP会话，⼀种是信令意义上的会话。
SIP中的会话指后⼀种，在层次上它在dialog 之上，也就是dialog可以看成session的组成单元。
⼆者的分别主要基于⽬前出现的subscription应⽤，对于session和subscription可以共享⼀个dialog，dialog由基本的会话标识组成，如Call-ID,From-Tag,To-Tag，以及⼀些⽬的target等共性单元组成。
SIP协议详解
SIP协议详解SIP 协议详解2013年参与过⼀个“视频通讯的App”项⽬，使⽤Sip协议通信。
当时通信协议这块不是⾃⼰负责，加上时间紧、任务重等⽅⾯的原因，⼀直未对Sip协议进⾏过深⼊的了解。
2020年春天疫情突发，宅在家⾥终于有了空余时间。
这⾥来详细了解⼀下Sip协议。
以下内容⼤致分为以下⼏个部分：协议简介两种Sip会话模式Session Model与Pager Model；Sip 消息体结构Sip 消息举例⼀、Sip协议简介：SIP（Session Initiation Protocol，会话初始协议）是由IETF（Internet Engineering Task Force，因特⽹⼯程任务组）制定的多媒体通信协议。
⼴泛应⽤于CS（Circuit Switched，电路交换）、NGN（Next Generation Network，下⼀代⽹络）以及IMS（IP Multimedia Subsystem，IP多媒体⼦系统）的⽹络中，可以⽀持并应⽤于语⾳、视频、数据等多媒体业务，同时也可以应⽤于Presence（呈现）、Instant Message（即时消息）等特⾊业务。
可以说，有IP⽹络的地⽅就有SIP协议的存在。
SIP是类似于HTTP，SIP可以减少应⽤特别是⾼级应⽤的开发时间。
由于基于IP协议的SIP利⽤了IP⽹络，固定⽹运营商也会逐渐认识到SIP技术对于他们的远意义。
⼆、Sip消息的两种会话模式在Sip IM通信应⽤过程中，⼀般存在着两种会话模式：Session ModelPager Model2.1、Session Model会话中，对于消息体内容⼤于1300字节时，⼀般采⽤Session Model。
其会话建⽴过程如下图所⽰：主叫⽅A呼叫被叫⽅B：步骤1：主叫⽅A发送INVITE请求到代理服务器；步骤2：代理服务器发送100 Trying 响应主叫⽅A；步骤3~6：代理服务器搜索被叫⽅B的地址，获取地址后转发INVITE请求；步骤7~9：被叫⽅B⽣成的180 振铃响应，返回给主叫⽅A；步骤10~12：被叫⽅B⽣成的200 OK响应，返回给主叫⽅A；步骤13~17：主叫⽅A收到被叫⽅B200 OK响应后，向被叫⽅B发送⼀个ACK，会话建⽴；步骤18~20：会话结束后，任何参与者（A或B）都可以发送⼀个BYE请求来终⽌会话；步骤21~23：主叫⽅A发送200 OK响应来确认BYE，会话终⽌。
sip协议中 认证域
sip协议中认证域SIP（Session Initiation Protocol）是一种用于建立、修改和终止会话的通信协议。
在SIP协议中，认证域是用于鉴别和验证用户身份的一种机制。
它允许SIP服务器在用户发起请求时进行认证，以确保只有合法用户才能访问网络服务。
认证域在SIP中起到了非常重要的作用，它提供了一个安全的身份验证机制。
通过认证域，用户可以凭借一定的身份凭证（如用户名和密码）来验证自己的身份。
这样一来，只有通过身份验证的用户才能进行会话，从而有效地保护了通信的安全性和隐私性。
SIP协议中的认证域具有以下特点和功能：1.安全性：认证域能够确保只有通过身份验证的用户才能进行通信。
通过用户名和密码的组合，认证域可以有效地验证用户的身份，并防止未经授权的用户进入系统。
2.隐私性：认证域可以保护用户的隐私数据，如密码等敏感信息。
通过使用加密算法对认证信息进行加密传输，可以防止信息被截获和恶意使用。
3.可扩展性：SIP协议中的认证域可以根据需求进行扩展和定制。
支持多种身份验证机制，如基于口令的认证、数字证书的认证等，以满足不同场景和需求的安全要求。
4.透明性：认证域对用户来说是透明的，用户并不需要了解具体的认证过程，只需要提供正确的用户名和密码即可。
这样可以简化用户的操作，并提高用户体验。
5.互操作性：认证域可以与其他安全机制结合使用，如TLS （Transport Layer Security）等，以实现更高层次的安全保护。
通过与其他协议的互操作，可以构建更安全、可靠的通信网络。
在SIP协议中，认证域主要包括以下几个组成部分：1.挑战应答流程（Challenge-Response Process）：服务器在接收到用户的请求后，会向用户发送一个挑战（Challenge），要求用户提供正确的身份凭证来进行认证。
用户接收到挑战后，根据服务器提供的算法，计算出正确的应答（Response）并发送给服务器。
SIP协议深入介绍
SIP协议深入介绍SIP协议深入介绍网络事业部软交换开发部王笑蓉1．SIP简介SIP（Session Initiation Protocol）是应用层控制协议，可以创建，修改，以及终止一个多媒体会话。
它具有以下几个主要功能：Userlocation：确定通信中的终端位置availability：确定被叫方是否愿意进行通信Usercapabilities：确定用于通信的媒体类型及参数Usersetup：建立会话各方的会话参数Sessionmanagement：终止会话，修改会话参数SessionSIP协议需要和其他IETF协议一起来构成一个完整的多媒体通信构架。
这些协议有：RTP(Real Time Transport)：传输实时数据，提供QoS反馈信息Streamingprotocol)：控制流媒体的传送TimeRTSP(RealMEGACO(Media Gateway Control Protocol)：控制媒体网关SDP（Session Description Protocol）：描述多媒体会话1．1SIP协议结构SIP协议的行为模型可以用几个分层的相对独立处理阶段来描述：1．语法及编码层2．传输层定义了客户端如何通过网络发送请求及接收响应，以及服务器端如何接收请求并发送响应。
所有SIP逻辑实体都包含此层。
3．事务层事务层处理应用层请求或响应消息的重发，响应与请求的匹配以及应用层的超时。
一个SIP事务由一个请求和对该请求的所有响应构成，这些响应分临时响应（provisional response）和最终响应(final response)。
对于INVITE事务，对应于非2xx响应的ACK确认消息也属于该事物，而对应于2xx响应的ACK确认消息则不属于该INVITE事物。
UA以及stateful proxy均包含事务层，而stateless proxy 不包含事务层一个事物根据逻辑功能分为客户事务(client transaction)和服务器事务（server transaction）。
简便的SIP消息--我们来看看SIP消息的格式
简便的SIP消息--我们来看看SIP消息的格式疫情期间，学校停课，北京的学校都在家上⽹络课堂，⼤家使⽤的不是腾讯视频会议便是钉钉视频会议。
疫情对⼤部分企业都造成了损失，然⽽视频会议市场却迎来⽣机。
今天咱们来谈谈视频会议中使⽤的SIP协议是什么样⼦的。
咱们⽴刻⽤SIP终端发起⼀个呼叫，然后抓取⽹络包如下，我们看到它包含很多A:B这种格式的数据，这些就叫SIP Header，和HTTP Header差不多。
下⾯是发起呼叫的invite SIP消息INVITE sip:6999 SIP/2.0From: <sip:112826@136.123.127.49>;tag=1b7ffa38-6800a8c0-13c4-60011-8ca1-5ce4ed6e-8ca1To: <sip:6999>Call-ID: 1b855600-6800a8c0-13c4-60011-8ca1-614dc2d0-8ca1CSeq: 1 INVITEVia: SIP/2.0/UDP 136.123.127.49:5060;rport;branch=z9hG4bK-8ca1-2255705-7fc7db28-1b7c8d00Max-Forwards: 70Supported: replaces,timer,100relAllow: INVITE, ACK, BYE, REFER, NOTIFY, INFO, CANCELUser-Agent: Sherlock 3.2.0.8Contact: <sip: 112826@136.123.127.49>Session-Expires: 1800;refresher=uac咱们再看看被邀请的⼀⽅返回的SIP消息SIP/2.0 200 OKFrom: <sip: 112826@136.123.127.49>;tag=1b7ffa38-6800a8c0-13c4-60011-8ca1-5ce4ed6e-8ca1To: <sip:6999>;tag=7f231e4ff028-e46b820a-13c4-55022-22b3fa-3ca0854f-22b3faCall-ID: 1b855600-6800a8c0-13c4-60011-8ca1-614dc2d0-8ca1CSeq: 1 INVITESIP消息包含了很多SIP Headers，它很容易看懂，咱们挑⼏个看⼀下1. 1. INVITE sip:6999 SIP/2.0它的意思是，这是⼀个invite消息，呼叫的对象是1. 2. From: <sip:112826@136.123.127.49>;tag=1b7ffa38-6800a8c0-13c4-60011-8ca1-5ce4ed6e-8ca1它的意思是这个invite消息来⾃谁，tag⽤来标识这个谁1. 3. To: <sip:6999>它的意思很明显，就是发送给谁1. 4. Call-ID: 1b855600-6800a8c0-13c4-60011-8ca1-614dc2d0-8ca1它的意思也很明显，就是呼叫的ID，⽤来标识这次呼叫1. 5. CSeq: 1 INVITE1 是个序列号，⼀个对话包含很多请求，⼀般情况下每次发起⼀个新的请求，这个序列号会+1INVITE 这个是请求的名字。
3GPP 对 SIP 的私有头(P-Header)扩展
Network Working Group M. Garcia-Martin Request for Comments: 3455 Ericsson Category: Informational E. HenriksonLucentD. MillsVodafoneJanuary 2003 3GPP 对SIP 的私有头(P-Header)扩展Status of this MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard of any kind. Distribution of thismemo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2003). All Rights Reserved.AbstractThis document describes a set of private Session Initiation Protocol(SIP) headers (P-headers) used by the 3rd-Generation PartnershipProject (3GPP), along with their applicability, which is limited toparticular environments. The P-headers are for a variety of purposeswithin the networks that the partners use, including charging andinformation about the networks a call traverses.目录1. 应用范围. . . . . . . . . . . . . .. . . . . . . . . . . . 32. 约定. . . . . . . . . . . . . . . . . . . . . . . . . . . 33. 概述. . . . . . . . . . . . . . . . . . . . . . . . . . 34. SIP 私有头. . . . . . . . . . . . . . . . . . . . . . . . . 34.1 P-Associated-URI 头. . . . . . . . . . . . . . . . . . . . 34.1.1 P-Associated-URI 头的适用声明. . . . . . . . . . . . 44.1.2 P-Associated-URI 头的用法. . . . . . . . . . . . . 44.2 P-Called-Party-ID 头. . . . . . . . . . . . . . . . . . 64.2.1 P-Called-Party-ID 头的适用声明. . . . . . . . . . . 94.2.2 P-Called-Party-ID 头的用法. . . . . . . . . . . . . 104.3 P-Visited-Network-ID 头. . . . . . . . . . . . . . . . . . 114.3.1 P-Visited-Network-ID 头的适用声明. . . . . . . . . . 11Garcia-Martin, et. al. Informational [页1] RFC 3455 3GPP SIP P-Header 扩展January 20034.3.2 P-Visited-Network-ID 头的用法. . . . . . . . . .. . 124.4 P-Access-Network-Info 头. . . . . . . . . . . . . . . . . 154.4.1 P-Access-Network-Info 头的适用声明. . . . . . . . . 164.4.2 P-Access-Network-Info 头的用法. . . . . . . . . . 174.5 P-Charging-Function-Addresses 头. . . . . . . . . . . . . 184.5.1 P-Charging-Function-Addresses 头的适用声明. . . . . 184.5.2 P-Charging-Function-Addresses 头的用法. . . . . . . 194.6 P-Charging-Vector 头. . . . . . . . . . . . . . . . . . . 214.6.1 P-Charging-Vector 头的适用声明. . . . . . . . . . . 224.6.2 P-Charging-Vector 头的用法. . . . . . . . . . . . . 235. 形式语法. . . . . . . . . . . . . . . . . . . . . . . . . . . 255.1 P-Associated-URI 头的语法. . . . . . . . . . . . . . . . . 255.2 P-Called-Party-ID 头的语法. . . . . . . . . . . . .. . . 255.3 P-Visited-Network-ID 头的语法. . . . . . . . . . . . . . . 255.4 P-Access-Network-Info 头的语法. . . . . . . . . . . . . . 255.5 P-Charging-Function-Addresses 头的语法. . . . . . . . . . 265.6 P-Charging-Vector 头的语法. . . . . . . . . . . . . . . . 265.7 新头列表. . . . . . . . . . . . . . . . . . . . . . . . . 276. 安全考虑. . . . . . . . . . . . . . . . . . . . . . . . . . . 286.1 P-Associated-URI . . . . . . . . . . . . . . . . . . . . . 286.2 P-Called-Party-ID. . . . . . . . . . . . . . . . . . . . . 286.3 P-Visited-Network-ID . . . . . . . . . . . . . . . . . . . 286.4 P-Access-Network-Info. . . . . . . . . . . . . . . . . . . 296.5 P-Charging-Function-Addresses. . . . . . . . . . . . . . . 306.6 P-Charging-Vector. . . . . . . . . . . . . . . . . . . . . 307. IANA 考虑. . . . . . . . . . . . . . . . . . . . . . . . . . 308. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 319. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 3210. Normative References . . . . . . . . . . . . . . . . . . . . 3211. Informative References . . . . . . . . . . . . . . . . . . . 32Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 34Garcia-Martin, et. al. Informational [页2]RFC 3455 3GPP SIP P-Header 扩展January 20031. 应用范围文中描述的SIP扩展对网络拓朴,SIP与底层的连接,以及信任的有效性作出了一定的假定.这些假定在Internet环境下一般不会全部适用. 这里所描述的机制是为了满足3GPP R5对SIP的需求而设计的, 它因为没有足够的运营经验或是不够成熟而没有考虑通用解决方案.参考每一项扩展的适用性可以了解更多关于扩展假定的描述2. 约定文中关键字"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和"OPTIONAL" 的描述参见BCP 14, RFC 2119 [2].3. 概述3GPP 已经选择SIP作为其在IMS环境中建立和解除会话的协议. (关于IMS 的更多描述可参见3GPP TS 23.228 [14] 和3GPP TS 24.229 [15]). 3GPP 告知IETF SIP和SIPPING 工作组除了一些额外的功能外现有的SIP协议几乎提供了IMS所需要的全部功能.这些需求[4]被制定为互联网草案提交给SIPPING Working 工作组. 其中的一些需求已通过协议扩展被满足,另外一些则因为不够通用而未被SIP工作组采纳.本文档描述了针对这些需求的私有扩展. 每一项扩展,以及与之相关的扩展在其相关章节进行描述.4. SIP 私有头4.1 P-Associated-URI 头这项扩展充许一次注册返回一组与已注册的AOR相关联的URI. 我们定义P-Associated-URI头字段并在REGISTER请求的200 OK 响应中使用该字段.P-Associated-URI关字段传送了一组与已注册的AOR相关联的URIs.Garcia-Martin, et. al. Informational [页3]RFC 3455 3GPP SIP P-Header 扩展January 2003服务供应商已经分配给一个用户专用的URI称为已关联的URI. registrar允许包含一个AOR关联0个或更多的URI的相关信息. 通常, 所有的这些URIs (AOR URI和关联URIS) 已为特定用户指定好用途. 这项针对SIP的扩展允许UAC在一次成功的授权注册后知道还有哪些服务供应商提供的URIs关联至AOR上.请注意, 一般来说, registrar不会为用户注册关联URIs. 只有出现在REGISTER方法中的To头段的AOR才能被注册和绑定到联系地址(contact address). 这里传达的唯一信息是registrar知道其他的URIs将被同一用户使用.一个应用服务器(甚至是registrar自身)有可能通过第三方注册为用户注册了一个关联URIs. 本文不讨论第三方注册. 一个UAC不能假定关联URIs已经注册.如果一个UAC想检测某个关联URIs是否被注册, 它可以通过文档外描述的一种机制进行, 例如, UA可以发送一个REGISTER请求并在To字段中填写期望的关联URI并不带Contact 字段.200 OK 响应将包含一个带有已注册的联系地址列表的Contact头. 如果关联URI没有注册, UA可以在使用之前注册.4.1.1 P-Associated-URI 头的适用声明P-Associated-URI 头适用于SIP供应商为用户提供一组在其UA产生请求可声明的标识符(在From头字段中)的SIP网络中. 更进一步, 它假定供应商知道用户可以合理声明整个标识集以及用户期望限制某些标识. 相对于这一点, 正常的SIP用法中From字段只是最终用户标明的字段.4.1.2 P-Associated-URI 头的用法registrar将P-Associated-URI头字段插入至REGISTER请求的200 OK 响应中.头字段的值用0个或更多的与AOR关联的URIs组成的列表填写.RFC 3455 3GPP SIP P-Header 扩展January 2003如果registrar支持P-Associated-URI头扩展, registrar必须总是将P-Associated-URI 插入到REGISTER请求的200 OK的响应中去,而不管REGESTER是初始注册,重注册,或是注销以及是否有0个或是更多的URIs.4.1.2.1 UA 的处理流程一个UAC可能在REGISTER的200 OK响应中收到P-Associated-URI 头字段. 该字段的出现意味着registrar支持该项扩展.头字段的值包含AOR的0个或多个关联URIs. UAC可以接下来的请求中可以使用任意一个来填写From头字段或为标识calling party提供信息的其他SIP头字段.UAC 可检测关联URIs是否注册. 示例如下, 将该URI填写到REGISTER消息中的To字段但不附加Contact字段. 200 OK响应中的Contact字段将包含已注册的联系地址列表.如同SIP[1]中描述的, 200 OK 响应中的Contact头字段可以包含0或多个值(0 意味着当前AOR未注册).4.1.2.2 registrar 的处理流程一个接受并认证REGISTER请求的registrar 可以将AOR与0个或多个URI关联.支持该项扩展的registrar必须在REGISTER请求的200 OK 的响应中包含P-Associated-URI 头字段. 并且必须填写与当前注册AOR相关联的SIP 或SIPS URIs的逗号分隔列表.如果当前注册的AOR没有相关联的SIP 或SIPS URIs, registrar 必须包含一个空的P-Associated-URI 字段值.4.1.2.3 proxy 的处理流程备忘录里没有定义关于proxy 的处理流程.RFC 3455 3GPP SIP P-Header 扩展January 20034.2 P-Called-Party-ID 头典型地proxy 服务器在路由INVITE请求到它的目标时插入P-Called-Party-ID 头.该头用porxy收到请求的Request-URI 填写.UAS 从几个已注册的AORs中标识出是会话邀请是发送给哪个AOR.(例如, 用户可以同时使用个人或业务SIP URI来接受会话邀请). UAS可以使用该信息根据接受会话的URI应用不同的有个性的音频提示音.3GPP IMS 的用户可以获得一个或多个标识用户的SIP URIs(AOR). 例如,一个用户可以获得一个业务SIP URI和一个个人SIP URI. 一个应用的案例是,用户可以让业务SIP URI只对工作伙伴有效而个人SIP URI只对家庭成员有效.在某一特定的时间点上, 业务SIP URI和个人SIP URI 都已注册到SIP registrar,因此两个URI都能接受新的会话邀请. 当该用户收到一个加入会话的邀请,他/她应该知道会话是发给已注册的几个SIP URI中的哪一个.这项需求在3GPP R5 中关于SIP[4]的需求中提及.当为UA服务的SIP proxy 获得INVITE, 然后对请求Request-URI字段进行重定位目标, 并且替换为用户在注册时REGISTER请求中Contact 头字段的所公布的SIP URI时, 这个问题就会在会话建立中的会话终结端产生.当UAS 收到SIP INVITE, 它不能判断请求发给哪个AOR.某些人可能觉得To头字段指明了语义上被叫用户,所以无需对SIP进行该扩展.虽然SIP的To头字段在大多数情况下意味着called party ID, 但在以下两个特殊情况下并不正确:1. 会话在到达为用户服务的代理服务器之前被前面的SIP代理前转(forwarded),重定向(redirected), 等.2. UAC 构造了一个To 头字段与Request-URI不相同INVITE 请求.RFC 3455 3GPP SIP P-Header 扩展January 2003To头字段的使用问题是它只能被UAC填写而不能路径上的代理修改.如果因为某种原因UAC没有用目标用户的AOR填写To头字段, 目标用户将不能区分会话期望的AOR.这个问题另一个可能的解决方案建立在注册时不同的AOR使用不用的Contact头字段值.UA能够能过分配不同的Contact头字段值来区分不同的AOR. 例如, 当UA注册AOR sip:id1,Contact头字段可以为sip:id1@ua; 而sip:id2 的注册可以绑定到Contact字段sip:id2@ua.上面描述的方案假定UA显式注册它的每一个AOR, 因此必须完全控制分配给每次注册的联系地址.然而, 在UA不能完全控制它注册的AOR的情况下, 比如第三方注册, 这个方案就行不通. 3GPP 可能这样一种注册情形: UA可以在SIP之外预先指示网络当UA注册特定的AOR时,一些其他的AOR URIs 可以被自动注册. 该需求被3GPP R5 需求SIP [4]涵盖.在下一段我们给出关于这个问题的一个例子, 它的情况是会话中已经存在有序的呼叫前转,因而UAC并不清楚当前INVITE的真实目标URI.我们假定用户代理(UA) 注册到代理服务器(P1).场景UA --- P1F1 Register UA -> P1REGISTER sip: SIP/2.0Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7To: sip:user1-business@From: sip:user1-business@;tag=456248Call-ID: 843817637684230998sdasdh09CSeq: 1826 REGISTERContact: <sip:user1@192.0.2.4>用户也注册其个人URI 到他/她的registrar.Garcia-Martin, et. al. Informational [页7]RFC 3455 3GPP SIP P-Header 扩展January 2003F2 Register UA -> P1REGISTER sip: SIP/2.0Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashdt8To: sip:user1-personal@From: sip:user1-personal@;tag=346249Call-ID: 2Q3817637684230998sdasdh10CSeq: 1827 REGISTERContact: <sip:user1@192.0.2.4>然后, 代理/registrar (P1) 从另外一个代理服务器(P2)收到一个目标为该用户业务SIP AOR的INVITE请求. 我们假定该SIP INVITE之前经历了一系列的前转, 因此它的To字段值填写并不是用户的AOR. 在这种情况下我们假定会话最初是发给sip:other-user@的. SIP 服务器 将会话前转到sip:user1-业务@场景UA --- P1 --- P2F3 Invite P2 -> P1INVITE sip:user1-business@ SIP/2.0Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1To: sip:other-user@From: sip:another-user@;tag=938s0Call-ID: 843817637684230998sdasdh09CSeq: 101 INVITE代理服务器P1 定位目标用户并用其注册时的Contact字段值替换Request-URI.F4 Invite P1 -> UAINVITE sip:user1@192.0.2.4 SIP/2.0Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1To: sip:other-user@From: sip:another-user@;tag=938s0Call-ID: 843817637684230998sdasdh09CSeq: 101 INVITE当UAS收到INVITE, 它不确判断是从业务URI还是从个人URI上收到会话邀请.无论UAS还有代理服务器以及应用服务器都不可能对提供会话目标AOR作出判断.Garcia-Martin, et. al. Informational [页8]RFC 3455 3GPP SIP P-Header 扩展January 2003我们解决这个问题方案是: 允许用户的归属域代理服务器(SIP中定义)插入一个标识会话目标的AOR的P-Called-Party-ID头.如果使用了这项SIP扩展的话, 被叫用户代理服务器将在获得消息F5后用F5中的Request-URI填写到F6中P-Called-Party-ID去.消息流F5和F6内容如下:F5 Invite P2 -> P1INVITE sip:user1-business@ SIP/2.0Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1To: sip:other-user@From: sip:another-user@;tag=938s0Call-ID: 843817637684230998sdasdh09CSeq: 101 INVITEF6 Invite P1 -> UAINVITE sip:user1@192.0.2.4 SIP/2.0Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1To: sip:other-user@From: sip:another-user@;tag=938s0Call-ID: 843817637684230998sdasdh09P-Called-Party-ID: sip:user1-business@CSeq: 101 INVITE当UA收到INVITE请求F6时,它能判断会话的目的AOR, 并能根据此AOR提供相应的服务.4.2.1 P-Called-Party-ID 头的适用声明P-Called-Party-ID 适用于UAS需要知道在代理将目标改写为Contact地址之前请求中Request-URI的目的AOR的情况. UAS 可针对请求目标按兴趣设定不同的语音提醒或使用其他过滤服务. 当UAS注册了几个AOR,并且,除非使用这项扩展,否则UAS并不清楚他的代理服务器/registrar给出的INVITE请求的AOR. 此时,扩展将显得更有价值.更通用的解决方案需求已在[12]中被提交但未被SIP采纳, 方案也尚未开发.RFC 3455 3GPP SIP P-Header 扩展January 20034.2.2 P-Called-Party-ID 头的用法P-Called-Party-ID 头字段将proxy目标重定位之前请求中Request-URI的AOR提供给代理服务器和UAS. 这些信息可以被到达UAS所经路径上的后续代理服务器使用.典型地, 一个SIP代理在目标重定位Request-URI 之前插入P-Called-Party-ID头.在Request-URI改写为Contact地址之前, 用Request-URI填写该字段.4.2.2.1 UA 的处理流程UAC 不能在任何SIP请求或响应消息中插入P-Called-Party-ID 头字段.UAS 可能收到包含P-Called-Party-ID头字段的SIP 请求. 该头填写的是在被前转到UAS之前代理服务器收到请求消息的Request-URI.UAS可以使用P-Called-Party-ID根据called party URI提供服务, 例如,按日期和时间过滤呼叫, 定制展现服务, 定制提示音, 等等.4.2.2.2 代理服务器的处理流程需要访问用户Contact信息的代理服务器可以向表1中列出的请求(Section 5.7)插入一个P-Called-Party-ID 头字段. 代理服务器必须用其接收到的SIP请求消息中的Request-URI 填写该字段.为了防止called party ID的错误发送, 插入P-Called-Party-ID的代理服务器拥有用户信息显得很重要.例如,这些信息可通过注册过程得到.代理服务器或应用服务器接收到包含P-Called-Party-ID头的请求后可以使用并根据其内容提供服务.SIP proxy 不能在注册请求中插入P-Called-Party-ID 头.RFC 3455 3GPP SIP P-Header 扩展January 20034.3 P-Visited-Network-ID 头3GPP 网络由归属网, 拜访网和subscribers的集合组成.一个特定的归属网会和一个或多个拜访网存在漫游协议. 当移动终端漫游时这些将会起作用, 它可以使终端透明地使用拜访网提供的资源.归属网能够接受漫游至特定的拜访网UA的注册的前提之一就是归属网和拜访网存在漫游协议. 在这里归属网需要知道是哪个拜访网正在为漫游的UA提供服务.3GPP UA总是注册到归属网络. REGISTER 请求被拜访网中的一个或多个代理服务器转发至归属网. 最简单的考虑,在拜访网包含一个归属网可以识别的标识符应该是比较明智的.这个标识符应该全局唯一, 格式采用引号括起的字符串或令牌. 归属网可以用该标识符检验拜访网的漫游协议是否存在, 并且通过拜访网授权注册.4.3.1 P-Visited-Network-ID 头的适用声明P-Visited-Network-ID 在以下情形下适用:1. 通过归属网与拜访网已建立的关系UA与归属网之间的中间服务器必须互相信任,并且通常支持标准安全机制如,IPsec, AKA, 或TLS 的使用.2. 终端使用一个或多个拜访网(用户与该网络没有直接的业务关系)提供的资源.3. 位于拜访网中的一个代理服务器希望在用户的归属网中能够标识出自己.4. 不是每个拜访网都需要在归属网标识出自已. 希望标识的可以按本文描述使用扩展, 不需要标识的则什么都不用做.RFC 3455 3GPP SIP P-Header 扩展January 20035. 归属网与拜访网协商一致的文本串或令牌标识符.6. UAC 向拜访网中的代理服务器发送一个REGISTER 或对话发起请求(如,INVITE) 或者一个单独的对话外请求(如OPTIONS).7. 请求在到达目标的途中, 第一个代理服务器在拜访网, 第二个代理服务器在归属网或者他的目标是归属网中的registrar.8. registrar或归属代理服务器校验并授权在拜访网中资源的使用(如, 代理服务器)4.3.2 P-Visited-Network-ID 头的用法P-Visited-Network-ID 用来向registrar或归属代理服务器传达拜访网标识符.该标识符是一个归属网的registrar或归属代理服务器以及拜访网中的代理服务器都能识别的文本字符串或令牌.典型地, 归属网授权UA漫游特定的拜访网. 该操作需要归属网与拜访网存在漫游协议.虽然归属网能够通过检查Via头字段中域名标识拜访网, 但该方法过分信赖DNS.例如代理服务器在via头字段中可选填写IP地址, 在缺少返向DNS入口的情况下,IP地址将不能转换出期望的信息.任何一个收到表1(Section 5.7)任何一个请求的SIP代理服务器当它前传请求时可以插入一个P-Visited-Network-ID 头. 在REGISTER 或其他请求穿过不同的管理区域(如不同的漫游网)的情况下, 如果请求中未包含P-Visited-Network-ID 头值自身标识符,(如,请求穿过不同的管理区域)则SIP proxy 可以插入一个新的P-Visited-Network-ID 头.还要注意的是, 代理服务器没有必要解读该字段. 因此, 第一个proxy可以插入一个只有registrar能够解密的加密头. 如果请求穿过位于与第一个proxy相同管理区域的第二个proxy, 第二个proxy将不能解读RFC 3455 3GPP SIP P-Header 扩展January 2003P-Visited-Network-ID 头的内容. 在这种情况下,第二个proxy 将认为它的拜访网络标识符并没有已经出现头的值中, 因此, 它将插入一个新的P-Visited-Network-ID 头字段值(虽然也许没有加密的话,插入了与第一个proxy相同的标识符). 当请求到达归属网的registrar 或proxy 时,因为两个代理服务器属于相同的管理区域所以解密后的值是相同的,它将注意到头字段值重复了(第一个和第二个proxy都插入了).虽然不期望这种情况发生, 但它也没有对归属网的registrar 或proxy 造成破坏.P-Visited-Network-ID 正常情况下在注册时使用. 然而本扩展没有排除其他的用法.例如, 位于拜访网中的一个没有保存注册状态的proxy可以插入一个P-Visited-Network-ID 头到任何一个单独的对话外请求或对话创建请求. 在撰写本文时, 创建对话的唯一需求是INVITE [1], SUBSCRIBE [6] 和REFER [11].为了避免标识符冲突, 特别是当网络间的漫游协议增加时,选择P-Visited-Network-ID 值时必须小心. 该标识符应该全局唯一以避免出现重复.虽然存在很多创建跨网络全局唯一标识符机制, 有一种机制已经在运作, 这就是DNS.P-Visited-Network-ID 与DNS之间没有任何连接, 但是头字段的值可以从自身DNS条目中选取用以代表网络域名.这将确保该值的唯一性.4.3.2.1 UA 的处理流程UAC 不应该向SIP消息中插入P-Visited-Network-ID 头.4.3.2.2 registrar 和proxy 的处理流程位于拜访网中SIP proxy 可以向表1 (Section 5.7)列出的任何请求插入一个P-Visited-Network-ID 头字段. 该头必须用填写为一个在用户归属网中标识该proxy网络管理区域的文本字符串或令牌.RFC 3455 3GPP SIP P-Header 扩展January 2003位于归属网的SIP proxy 或registrar 可以使用P-Visited-Network-ID 的内容作为请求穿越的一个或多个拜访网的标识符.归属网的proxy 或registrar 能否按本地策略进行动作取决于归属网与拜访网之间是否存在漫游协议. 这意味着, 例如,请求的授权取决于P-Visited-Network-ID 头的内容.为了保护用户隐私, 位于归属网的proxy在将消息前转到归属网以外的管理区域时必须该头删去.当归属代理服务器已经使用了头的内容或是请求已按基于called party路由, 即使请求并没有前转出归属网管理区域.位于归属网SIP proxy也应该删除该头.4.3.2.3 用法示例我们示例的场景环境如下面的网络图:场景UA --- P1 --- P2 --- REGISTRAR这个例子列出一个从UA1发起最后到达REGISTRAR的REGISTER 事务的消息序列.P1 是UA1的出口proxy. 在这个情况下P1 同时插入了P-Visited-Network-ID 头.P1 然后通过P2将REGISTER请求路由至Registrar.使用了P-Visited-Network-ID 头的REGISTER消息序列:F1 Register UA -> P1REGISTER sip: SIP/2.0Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7To: sip:user1-business@From: sip:user1-business@;tag=456248Call-ID: 843817637684230998sdasdh09CSeq: 1826 REGISTERContact: <sip:user1@192.0.2.4>在流程F2中, proxy P1 (???)将它自己的标识符加入到P-Visited-Network-ID 头.RFC 3455 3GPP SIP P-Header 扩展January 2003F2 Register P1 -> P2REGISTER sip: SIP/2.0Via: SIP/2.0/UDP ;branch=z9hG4bK203igldVia: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashdt8To: sip:user1-personal@From: sip:user1-personal@;tag=346249Call-ID: 2Q3817637684230998sdasdh10CSeq: 1826 REGISTERContact: <sip:user1@192.0.2.4>P-Visited-Network-ID: "Visited network number 1"最后, 在流程F3中, proxy P2 是否插入它自己的标识符取决于它的域名.F3 Register P2 -> REGISTRARREGISTER sip: SIP/2.0Via: SIP/2.0/UDP ;branch=z9hG4bK2bndnvkVia: SIP/2.0/UDP ;branch=z9hG4bK203igldVia: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashdt8To: sip:user1-personal@From: sip:user1-personal@;tag=346249Call-ID: 2Q3817637684230998sdasdh10CSeq: 1826 REGISTERContact: <sip:user1@192.0.2.4>P-Visited-Network-ID: , "Visited network number 1"4.4 P-Access-Network-Info 头本节描述P-Access-Network-Info 头. 该头在基于SIP的网络通过不同的接入技术与层2/层3互通时有用. SIP UA可以使用该头向提供服务的代理服务器传递有关接入技术的信息.服务proxy 可以使用这些信息为UA优化服务. 例如, 一个3GPP UA可以使用该头传递关于接入网的信息(如无线接入技术和无线小区标识等)给他的归属服务供应商.为了达到扩展的目的,我们将提供层2/层3 IP 连通性使得用户可以访问SIP功能以及提供的服务的网络定义为接入网络.在有些情况下, 给用户提供服务的SIP 服务器可能希望知道UA当前所使用的接入网类型信息.一些服务合适与否取决于接入类型,RFC 3455 3GPP SIP P-Header 扩展January 2003 如果为用户提供服务的SIP proxy知道接入网络的细节.一些服务将会对用户更有价值.在另外一些情况下, 向用户提供服务的SIP服务器为了向用户提供特定的服务可能只是简单地想知道用户的实际位置信息. 例如, 现在无线网络的许多有用的位置服务需要归属网知道用户正在使用的小区标识.一些规定的需求强制要求蜂窝无线系统在建立紧急呼叫时向紧急处理中心提供有效的小区标识.为用户提供服务的SIP服务器可能期望了解接入网. 这可以通过定义新的私有SIP 扩展头, P-Access-Network-Info. 该头在UAC及他的归属网服务proxy间携带关于接入网的信息.4.4.1 P-Access-Network-Info 头的适用声明该机制适合SIP 服务依赖SIP 网元知道UA连接到SIP网络的IP及底层技术细节的环境.更具体地说, 该扩展需要UA知道自己使用的接入技术, 并且proxy需要通过信息以提供服务. 通常SIP 是建立在"Everything over IP and IP over everything" 基础之上,接入技术与SIP操作无关. 因为SIP 系统通常不应该关注或者甚至是知道接入技术, 所以该SIP扩展不作为SIP的一般用法.P-Access-Network-Info 头暴露的信息有可能很敏感.这此信息的正确保护依赖于在观察含该头的SIP消息的代理服务器之间存在特定的业务和安全关系.它还依赖于UA明确地知道存在这样的关系.因此,该机制只适合存在适当合理的关系且UA明确知道这一点的环境.RFC 3455 3GPP SIP P-Header 扩展January 20034.4.2 P-Access-Network-Info 头的用法当UA产生一个将被安全发送到给它的提供服务SIP proxy SIP请求或响应时,UA 插入一个P-Access-Network-Info 头到SIP消息中.该头包含UA用以获得IP 连通性的接入网的信息.该头典型地被UA及提供服务的SIP proxy之间的中间代理服务器忽略.提供服务的proxy 可以检查该头并且根据该头提供适当的服务.在前转请求消息前, proxy 从消息中删除该头.4.4.2.1 UA 行为支持该扩展并且期望暴露相关参数的UA可以在任何SIP请求或响应中插入P-Access-Network-Info头.插入该信息的UA 必须确信为它提供服务的proxy为了保护它的隐私,在将消息前转出proxy所在区域删除该头. 该proxy典型地位于归属网.为了执行删除头的动作, 必须同样信任UA及提供服务的SIP proxy之间的中间代理服务器.该信任建立在归属网与接入网之间的业务协议之上, 并且一般使用标准安全机制, 如., IPsec, AKA, 和TLS.4.4.2.2 Proxy 行为proxy不能插入或修改P-Access-Network-Info 头的值.如果出现P-Access-Network-Info 头, 为UA提供服务的proxy的可以根据头上的信息, 针对UA 访问服务器所使用的网络或位置提供不同的服务. 例如, 对于蜂窝无线接入网,位于归属网的SIP proxy 可以使用小区标识提供基本定位服务.为用户提供服务的proxy一般位于归属网同时也是可信的,当SIP信令前转至位于非信任网络管理区域的一个SIP server时必须删除该头.RFC 3455 3GPP SIP P-Header 扩展January 2003为UA提供服务的服务器使用接入网信息并且不关心位于其他不同的管理区域代理服务器.4.5 P-Charging-Function-Addresses 头3GPP 定义了分布式架构导致多个网络实体被涉及提供接入和服务.这里就需要通知事务涉及到的每个相关公共计费功能实体的SIP proxy去接收产生的计费记录或计费事件.3GPP提供的方案定义了两类计费功能实体:计费采集(CCF)以及事件计费功能(ECF).CCF 用于离线计费(如后付费账务计费). ECF 用于在线计费(如预付费账务计费).为了实现冗余, 在网络上可能存在不止一个CCF 和ECF. 在存在多个CCF或ECF地址实例的情况下, 实现应该尝试向P-Charging-Function-Addresses 中地址序列的第一个ECF 或CCF地址发送计费数据. CCF 和ECF的地址可以在对话建立或单独事务中被传递.关于计费的更多信息参见3GPP TS 32.200 [16] and 3GPP TS 32.225 [17].我们定义了SIP 私有头P-Charging-Function-Addresses. 如果没有出现该头的话proxy不论是在初始对话请求或响应, 还是在对话外单独事务的请求和应答都可以包含该头.在特定的请求或响应中只能出现一个头.SIP proxy 收集值并填写P-Charging-Function-Addresses 头的机制不在本文描述.然而, 作为一个例子, 一个SIP proxy 可以预先配好这些地址, 或者也可以从订阅数据库中获取.4.5.1 P-Charging-Function-Addresses 头的适用声明P-Charging-Function-Addresses 头适用于需要协作计费的单个私有管理区域,例如, 参照3GPP TS 32.200 [16] 描述的架构.RFC 3455 3GPP SIP P-Header 扩展January 2003P-Charging-Function-Addresses 头不能包含在发送到外部管理区域SIP消息里.该头不适用于没有提供计费功能的管理区域.P-Charging-Function-Addresses 头的适用条件如下:1. UA 发送REGISTER 或对话发起请求(如, INVITE)或一个单独的对话外事务请求到位于私有网络管理区域的proxy.2. 位于私有网络管理区域的一个registrar, proxy 或UA 将产生计费记录.3. 位于私有网络一个registrar, proxy 或UA在网络中有访问计费功能实体地址的权限.4. 位于私有网络相同的管理区域的其他代理服务器会产生计费记录或计费事件.代理服务器想从SIP之外而不是第一个SIP proxy发送计费信息到相同的计费采集实体.4.5.2 P-Charging-Function-Addresses 头的用法SIP proxy 在收到一个SIP请求,如果该头没有出现在请求之中则可以在将消息前转之前插入一个P-Charging-Function-Addresses 头.该头的值包含一个或多个参数, 其中包含了期望收到计费信息节点的主机名称或IP地址.收到含P-Charging-Function-Addresses头SIP请求的SIP proxy可以使用其中主机名称或IP地址作为计费信息或计费事件的目标.发送计费信息或计费事件的方法不在本文中描述, 不过一般不使用SIP.4.5.2.1 UA 的处理流程本文没有指明任何关于UA针对P-Charging-Function-Addresses 头的处理流程,UA不需要理解该头.。
SIP协议中的HEADER应用
GreenNET
2013-7-11
深圳市格林耐特通信技术有限公司
头域概要, P--Z
where enc. e-e ACK BYE CAN INV OPT REG _______________________________________________________________ Proxy-Authenticate 407 n h o o o o o o Proxy-Authorization R n h o o o o o o Proxy-Require R n h o o o o o o Priority R c e o Require R e o o o o o o Retry-After R c e o Retry-After 404,480,486 c e o o o o o o 503 c e o o o o o o 600,603 c e o o o o o o Response-Key R c e o o o o o Record-Route R h o o o o o o Record-Route 2xx h o o o o o o Route R h o o o o o o Server r c e o o o o o o Subject R c e - o Timestamp g e o o o o o o To gc(1) n e m m m m m m Unsupported 420 e o o o o o o User-Agent g c e o o o o o o Via gc(2) n e m m m m m m Warning r e o o o o o o WWW-Authenticate 401 c e o o o o o o
Contact: <sip:alice@>;expires=3600
- 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会话能够正
确地初始化、控制和终止。