rfc4662.A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists

header fields should not begin with the leading characters "P-"
(unless the "P-" would preserve compatibility with an pre-existing
unregistered usage of the header field, at the discretion of the
Error-Info [RFC3261]
Event o [RFC3265]
Expires [RFC3261]
Flow-Timer [RFC5626]
P-DCS-Trace-Party-ID [RFC5503]
P-DCS-OSPS [RFC5503]
P-DCS-Billing-Info [RFC5503]
P-DCS-LAES [RFC5503]
Content-Disposition [RFC3261]
Content-Encoding e [RFC3261]
Content-Language [RFC3261]
Content-Length l [RFC3261]
P-Associated-URI [RFC3455]
P-Called-Party-ID [RFC3455]
P-Charging-Function-Addresses [RFC3455]
P-Charging-Vector [RFC3455]
Authorization [RFC3261]
Call-ID i [RFC3261]
Call-Info [RFC3261]
Contact m [RFC3261]

Internet Message Access Protocol (IMAP) is an email retrieval protocol. It stores email messages on a mail server and enables the recipient to view and manipulate them as though they were stored locally on their device. IMAP was developed in the late 1980s and has since become one of the most widely used email retrieval protocols.The IMAP standard is defined in RFC 3501, which was published in 2003. This document provides a detailed description of the protocol's functionality, including its data formats, commands, and responses. The standard specifies how IMAP clients and servers should communicate with each other to enable the retrieval and manipulation of email messages.One of the key features of IMAP is its support for multiple clients accessing the same mailbox simultaneously. This is achieved through the use of a "shared" storage model, where all clients see the same set of messages and folders stored on the server. This allows users to access their email from different devices without having to worry about synchronizing their messages manually.Another important aspect of IMAP is its support for message organization and management. Clients can create, delete, and rename folders, as well as move messages between folders. They can also search for specific messages based on various criteria, such as sender, subject, or date.IMAP also provides a range of features for managing individual messages. Clients can mark messages as read or unread, flag them for follow-up, and even move them to a specific folder. They can also reply to messages, forward them to others, and generate replies or forwards with attachments.Overall, the IMAP standard provides a powerful and flexible framework for managing email messages. Its support for shared storage, message organization, and advanced message management features make it a popular choice for both personal and business email users.。

sip authorization 原理SIP（Session Initiation Protocol）是一种用于建立、修改和终止多媒体会话的协议。

在SIP中，SIP授权（SIP Authorization）是一种用于验证用户身份的机制，它通过SIP消息头中的Authorization字段来实现。

SIP授权的原理是基于HTTP Digest认证协议的。

在SIP授权中，客户端向服务器发送一个请求，服务器返回一个401 Unauthorized响应，要求客户端提供用户名和密码。

客户端将用户名和密码使用MD5算法进行加密，并将结果放入Authorization字段中，然后再次向服务器发送请求。

服务器收到请求后，使用相同的算法对用户名和密码进行加密，并将结果与客户端提供的结果进行比较。

如果两者相同，则认为客户端是合法的，否则认为客户端是非法的。

SIP授权的过程如下：1. 客户端向服务器发送一个请求。

2. 服务器返回一个401 Unauthorized响应，要求客户端提供用户名和密码。

3. 客户端将用户名和密码使用MD5算法进行加密，并将结果放入Authorization字段中。

4. 客户端再次向服务器发送请求，并在请求头中包含Authorization字段。

5. 服务器收到请求后，使用相同的算法对用户名和密码进行加密，并将结果与客户端提供的结果进行比较。

6. 如果两者相同，则认为客户端是合法的，否则认为客户端是非法的。

SIP授权的优点是可以保护SIP网络免受未经授权的访问和攻击。

它可以防止未经授权的用户访问SIP网络，并保护SIP网络中的用户信息和通信内容。

此外，SIP授权还可以提高SIP网络的可靠性和安全性，确保SIP网络的正常运行。

总之，SIP授权是一种用于验证用户身份的机制，它通过SIP消息头中的Authorization字段来实现。

它的原理是基于HTTP Digest认证协议的，可以保护SIP网络免受未经授权的访问和攻击，提高SIP网络的可靠性和安全性。

Network Working Group S. Blake-Wilson Request for Comments: 4492 SafeNet Category: Informational N. Bolyard Sun Microsystems V. Gupta Sun Labs C. Hawk Corriente B. Moeller Ruhr-Uni Bochum May 2006 Elliptic Curve Cryptography (ECC) Cipher Suitesfor Transport Layer Security (TLS)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 (2006).AbstractThis document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS)protocol. In particular, it specifies the use of Elliptic CurveDiffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a newauthentication mechanism.Blake-Wilson, et al. Informational [Page 1]Table of Contents1. Introduction (3)2. Key Exchange Algorithms (4)2.1. ECDH_ECDSA (6)2.2. ECDHE_ECDSA (6)2.3. ECDH_RSA (7)2.4. ECDHE_RSA (7)2.5. ECDH_anon (7)3. Client Authentication (8)3.1. ECDSA_sign (8)3.2. ECDSA_fixed_ECDH (9)3.3. RSA_fixed_ECDH (9)4. TLS Extensions for ECC (9)5. Data Structures and Computations (10)5.1. Client Hello Extensions (10)5.1.1. Supported Elliptic Curves Extension (12)5.1.2. Supported Point Formats Extension (13)5.2. Server Hello Extension (14)5.3. Server Certificate (15)5.4. Server Key Exchange (17)5.5. Certificate Request (21)5.6. Client Certificate (22)5.7. Client Key Exchange (23)5.8. Certificate Verify (25)5.9. Elliptic Curve Certificates (26)5.10. ECDH, ECDSA, and RSA Computations (26)6. Cipher Suites (27)7. Security Considerations (28)8. IANA Considerations (29)9. Acknowledgements (29)10. References (30)10.1. Normative References (30)10.2. Informative References (31)Appendix A. Equivalent Curves (Informative) (32)Blake-Wilson, et al. Informational [Page 2]1. IntroductionElliptic Curve Cryptography (ECC) is emerging as an attractivepublic-key cryptosystem, in particular for mobile (i.e., wireless)environments. Compared to currently prevalent cryptosystems such as RSA, ECC offers equivalent security with smaller key sizes. This is illustrated in the following table, based on [18], which givesapproximate comparable key sizes for symmetric- and asymmetric-keycryptosystems based on the best-known algorithms for attacking them. Symmetric | ECC | DH/DSA/RSA------------+---------+-------------80 | 163 | 1024112 | 233 | 2048128 | 283 | 3072192 | 409 | 7680256 | 571 | 15360Table 1: Comparable Key Sizes (in bits)Smaller key sizes result in savings for power, memory, bandwidth, and computational cost that make ECC especially attractive forconstrained environments.This document describes additions to TLS to support ECC, applicableboth to TLS Version 1.0 [2] and to TLS Version 1.1 [3]. Inparticular, it defineso the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme with long-term or ephemeral keys to establish the TLSpremaster secret, ando the use of fixed-ECDH certificates and ECDSA for authentication of TLS peers.The remainder of this document is organized as follows. Section 2provides an overview of ECC-based key exchange algorithms for TLS.Section 3 describes the use of ECC certificates for clientauthentication. TLS extensions that allow a client to negotiate the use of specific curves and point formats are presented in Section 4. Section 5 specifies various data structures needed for an ECC-basedhandshake, their encoding in TLS messages, and the processing ofthose messages. Section 6 defines new ECC-based cipher suites andidentifies a small subset of these as recommended for allimplementations of this specification. Section 7 discusses security considerations. Section 8 describes IANA considerations for the name spaces created by this document. Section 9 gives acknowledgements. Blake-Wilson, et al. Informational [Page 3]This is followed by the lists of normative and informative references cited in this document, the authors’ contact information, andstatements on intellectual property rights and copyrights.Implementation of this specification requires familiarity with TLS[2][3], TLS extensions [4], and ECC [5][6][7][11][17].The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].2. Key Exchange AlgorithmsThis document introduces five new ECC-based key exchange algorithmsfor TLS. All of them use ECDH to compute the TLS premaster secret,and they differ only in the lifetime of ECDH keys (long-term orephemeral) and the mechanism (if any) used to authenticate them. The derivation of the TLS master secret from the premaster secret and the subsequent generation of bulk encryption/MAC keys and initialization vectors is independent of the key exchange algorithm and not impacted by the introduction of ECC.The table below summarizes the new key exchange algorithms, whichmimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2] and[3]), respectively.KeyExchangeAlgorithm Description--------- -----------ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates. ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures.ECDH_RSA Fixed ECDH with RSA-signed certificates.ECDHE_RSA Ephemeral ECDH with RSA signatures.ECDH_anon Anonymous ECDH, no signatures.Table 2: ECC Key Exchange AlgorithmsThe ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward secrecy. With ECDHE_RSA, a server can reuse its existing RSAcertificate and easily comply with a constrained client’s ellipticcurve preferences (see Section 4). However, the computational cost Blake-Wilson, et al. Informational [Page 4]incurred by a server is higher for ECDHE_RSA than for the traditional RSA key exchange, which does not provide forward secrecy.The ECDH_RSA mechanism requires a server to acquire an ECCcertificate, but the certificate issuer can still use an existing RSA key for signing. This eliminates the need to update the keys oftrusted certification authorities accepted by TLS clients. TheECDH_ECDSA mechanism requires ECC keys for the server as well as the certification authority and is best suited for constrained devicesunable to support RSA.The anonymous key exchange algorithm does not provide authentication of the server or the client. Like other anonymous TLS key exchanges, it is subject to man-in-the-middle attacks. Implementations of this algorithm SHOULD provide authentication by other means.Note that there is no structural difference between ECDH and ECDSAkeys. A certificate issuer may use X.509 v3 keyUsage andextendedKeyUsage extensions to restrict the use of an ECC public key to certain computations [15]. This document refers to an ECC key as ECDH-capable if its use in ECDH is permitted. ECDSA-capable isdefined similarly.Client Server------ ------ClientHello -------->ServerHelloCertificate*ServerKeyExchange*CertificateRequest*+<-------- ServerHelloDoneCertificate*+ClientKeyExchangeCertificateVerify*+[ChangeCipherSpec]Finished -------->[ChangeCipherSpec]<-------- FinishedApplication Data <-------> Application Data* message is not sent under some conditions+ message is not sent unless client authenticationis desiredFigure 1: Message flow in a full TLS handshakeBlake-Wilson, et al. Informational [Page 5]Figure 1 shows all messages involved in the TLS key establishmentprotocol (aka full handshake). The addition of ECC has direct impact only on the ClientHello, the ServerHello, the server’s Certificatemessage, the ServerKeyExchange, the ClientKeyExchange, theCertificateRequest, the client’s Certificate message, and theCertificateVerify. Next, we describe each ECC key exchange algorithm in greater detail in terms of the content and processing of thesemessages. For ease of exposition, we defer discussion of clientauthentication and associated messages (identified with a + inFigure 1) until Section 3 and of the optional ECC-specific extensions (which impact the Hello messages) until Section 4.2.1. ECDH_ECDSAIn ECDH_ECDSA, the server’s certificate MUST contain an ECDH-capable public key and be signed with ECDSA.A ServerKeyExchange MUST NOT be sent (the server’s certificatecontains all the necessary keying information required by the client to arrive at the premaster secret).The client generates an ECDH key pair on the same curve as theserver’s long-term public key and sends its public key in theClientKeyExchange message (except when using client authenticationalgorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case themodifications from Section 3.2 or Section 3.3 apply).Both client and server perform an ECDH operation and use theresultant shared secret as the premaster secret. All ECDHcalculations are performed as specified in Section 5.10.2.2. ECDHE_ECDSAIn ECDHE_ECDSA, the server’s certificate MUST contain an ECDSA-capable public key and be signed with ECDSA.The server sends its ephemeral ECDH public key and a specification of the corresponding curve in the ServerKeyExchange message. Theseparameters MUST be signed with ECDSA using the private keycorresponding to the public key in the server’s Certificate.The client generates an ECDH key pair on the same curve as theserver’s ephemeral ECDH key and sends its public key in theClientKeyExchange message.Both client and server perform an ECDH operation (Section 5.10) anduse the resultant shared secret as the premaster secret.Blake-Wilson, et al. Informational [Page 6]2.3. ECDH_RSAThis key exchange algorithm is the same as ECDH_ECDSA except that the server’s certificate MUST be signed with RSA rather than ECDSA.2.4. ECDHE_RSAThis key exchange algorithm is the same as ECDHE_ECDSA except thatthe server’s certificate MUST contain an RSA public key authorizedfor signing, and that the signature in the ServerKeyExchange message must be computed with the corresponding RSA private key. The server certificate MUST be signed with RSA.2.5. ECDH_anonIn ECDH_anon, the server’s Certificate, the CertificateRequest, theclient’s Certificate, and the CertificateVerify messages MUST NOT be sent.The server MUST send an ephemeral ECDH public key and a specification of the corresponding curve in the ServerKeyExchange message. Theseparameters MUST NOT be signed.The client generates an ECDH key pair on the same curve as theserver’s ephemeral ECDH key and sends its public key in theClientKeyExchange message.Both client and server perform an ECDH operation and use theresultant shared secret as the premaster secret. All ECDHcalculations are performed as specified in Section 5.10.Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA key exchange algorithms require the server’s certificate to be signed with a particular signature scheme, this specification (following the similar cases of DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2] and [3]) does not impose restrictions on signature schemes used elsewhere inthe certificate chain. (Often such restrictions will be useful, and it is expected that this will be taken into account in certification authorities’ signing practices. However, such restrictions are notstrictly required in general: Even if it is beyond the capabilitiesof a client to completely validate a given chain, the client may beable to validate the server’s certificate by relying on a trustedcertification authority whose certificate appears as one of theintermediate certificates in the chain.)Blake-Wilson, et al. Informational [Page 7]3. Client AuthenticationThis document defines three new client authentication mechanisms,each named after the type of client certificate involved: ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH. The ECDSA_sign mechanism isusable with any of the non-anonymous ECC key exchange algorithmsdescribed in Section 2 as well as other non-anonymous (non-ECC) keyexchange algorithms defined in TLS [2][3]. The ECDSA_fixed_ECDH and RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA.Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because theuse of a long-term ECDH client key would jeopardize the forwardsecrecy property of these algorithms.The server can request ECC-based client authentication by includingone or more of these certificate types in its CertificateRequestmessage. The server must not include any certificate types that are prohibited for the negotiated key exchange algorithm. The clientmust check if it possesses a certificate appropriate for any of themethods suggested by the server and is willing to use it forauthentication.If these conditions are not met, the client should send a clientCertificate message containing no certificates. In this case, theClientKeyExchange should be sent as described in Section 2, and theCertificateVerify should not be sent. If the server requires client authentication, it may respond with a fatal handshake failure alert. If the client has an appropriate certificate and is willing to use it for authentication, it must send that certificate in the client’sCertificate message (as per Section 5.6) and prove possession of the private key corresponding to the certified key. The process ofdetermining an appropriate certificate and proving possession isdifferent for each authentication mechanism and described below.NOTE: It is permissible for a server to request (and the client tosend) a client certificate of a different type than the servercertificate.3.1. ECDSA_signTo use this authentication mechanism, the client MUST possess acertificate containing an ECDSA-capable public key and signed withECDSA.The client proves possession of the private key corresponding to the certified key by including a signature in the CertificateVerifymessage as described in Section 5.8.Blake-Wilson, et al. Informational [Page 8]3.2. ECDSA_fixed_ECDHTo use this authentication mechanism, the client MUST possess acertificate containing an ECDH-capable public key, and thatcertificate MUST be signed with ECDSA. Furthermore, the client’sECDH key MUST be on the same elliptic curve as the server’s long-term (certified) ECDH key. This might limit use of this mechanism toclosed environments. In situations where the client has an ECC keyon a different curve, it would have to authenticate using eitherECDSA_sign or a non-ECC mechanism (e.g., RSA). Using fixed ECDH for both servers and clients is computationally more efficient thanmechanisms providing forward secrecy.When using this authentication mechanism, the client MUST send anempty ClientKeyExchange as described in Section 5.7 and MUST NOT send the CertificateVerify message. The ClientKeyExchange is empty since the client’s ECDH public key required by the server to compute thepremaster secret is available inside the client’s certificate. Theclient’s ability to arrive at the same premaster secret as the server (demonstrated by a successful exchange of Finished messages) provespossession of the private key corresponding to the certified publickey, and the CertificateVerify message is unnecessary.3.3. RSA_fixed_ECDHThis authentication mechanism is identical to ECDSA_fixed_ECDH except that the client’s certificate MUST be signed with RSA.Note that while the ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH client authentication mechanisms require the client’s certificate to be signed with a particular signature scheme, this specification does not impose restrictions on signature schemes used elsewhere in thecertificate chain. (Often such restrictions will be useful, and itis expected that this will be taken into account in certificationauthorities’ signing practices. However, such restrictions are notstrictly required in general: Even if it is beyond the capabilitiesof a server to completely validate a given chain, the server may beable to validate the clients certificate by relying on a trust anchor that appears as one of the intermediate certificates in the chain.) 4. TLS Extensions for ECCTwo new TLS extensions are defined in this specification: (i) theSupported Elliptic Curves Extension, and (ii) the Supported PointFormats Extension. These allow negotiating the use of specificcurves and point formats (e.g., compressed vs. uncompressed,respectively) during a handshake starting a new session. Theseextensions are especially relevant for constrained clients that may Blake-Wilson, et al. Informational [Page 9]only support a limited number of curves or point formats. Theyfollow the general approach outlined in [4]; message details arespecified in Section 5. The client enumerates the curves it supports and the point formats it can parse by including the appropriateextensions in its ClientHello message. The server similarlyenumerates the point formats it can parse by including an extensionin its ServerHello message.A TLS client that proposes ECC cipher suites in its ClientHellomessage SHOULD include these extensions. Servers implementing ECCcipher suites MUST support these extensions, and when a client usesthese extensions, servers MUST NOT negotiate the use of an ECC cipher suite unless they can complete the handshake while respecting thechoice of curves and compression techniques specified by the client. This eliminates the possibility that a negotiated ECC handshake will be subsequently aborted due to a client’s inability to deal with the server’s EC key.The client MUST NOT include these extensions in the ClientHellomessage if it does not propose any ECC cipher suites. A client that proposes ECC cipher suites may choose not to include theseextensions. In this case, the server is free to choose any one ofthe elliptic curves or point formats listed in Section 5. Thatsection also describes the structure and processing of theseextensions in greater detail.In the case of session resumption, the server simply ignores theSupported Elliptic Curves Extension and the Supported Point FormatsExtension appearing in the current ClientHello message. Theseextensions only play a role during handshakes negotiating a newsession.5. Data Structures and ComputationsThis section specifies the data structures and computations used byECC-based key mechanisms specified in Sections 2, 3, and 4. Thepresentation language used here is the same as that used in TLS[2][3]. Since this specification extends TLS, these descriptionsshould be merged with those in the TLS specification and any othersthat extend TLS. This means that enum types may not specify allpossible values, and structures with multiple formats chosen with aselect() clause may not indicate all possible cases.5.1. Client Hello ExtensionsThis section specifies two TLS extensions that can be included withthe ClientHello message as described in [4], the Supported EllipticCurves Extension and the Supported Point Formats Extension.Blake-Wilson, et al. Informational [Page 10]When these extensions are sent:The extensions SHOULD be sent along with any ClientHello message that proposes ECC cipher suites.Meaning of these extensions:These extensions allow a client to enumerate the elliptic curves itsupports and/or the point formats it can parse.Structure of these extensions:The general structure of TLS extensions is described in [4], and this specification adds two new types to ExtensionType.enum { elliptic_curves(10), ec_point_formats(11) } ExtensionType; elliptic_curves (Supported Elliptic Curves Extension): Indicatesthe set of elliptic curves supported by the client. For thisextension, the opaque extension_data field containsEllipticCurveList. See Section 5.1.1 for details.ec_point_formats (Supported Point Formats Extension): Indicates the set of point formats that the client can parse. For thisextension, the opaque extension_data field containsECPointFormatList. See Section 5.1.2 for details.Actions of the sender:A client that proposes ECC cipher suites in its ClientHello messageappends these extensions (along with any others), enumerating thecurves it supports and the point formats it can parse. ClientsSHOULD send both the Supported Elliptic Curves Extension and theSupported Point Formats Extension. If the Supported Point FormatsExtension is indeed sent, it MUST contain the value 0 (uncompressed) as one of the items in the list of point formats.Actions of the receiver:A server that receives a ClientHello containing one or both of these extensions MUST use the client’s enumerated capabilities to guide its selection of an appropriate cipher suite. One of the proposed ECCcipher suites must be negotiated only if the server can successfully complete the handshake while using the curves and point formatssupported by the client (cf. Sections 5.3 and 5.4).Blake-Wilson, et al. Informational [Page 11]NOTE: A server participating in an ECDHE-ECDSA key exchange may usedifferent curves for (i) the ECDSA key in its certificate, and (ii)the ephemeral ECDH key in the ServerKeyExchange message. The server must consider the extensions in both cases.If a server does not understand the Supported Elliptic CurvesExtension, does not understand the Supported Point Formats Extension, or is unable to complete the ECC handshake while restricting itselfto the enumerated curves and point formats, it MUST NOT negotiate the use of an ECC cipher suite. Depending on what other cipher suitesare proposed by the client and supported by the server, this mayresult in a fatal handshake failure alert due to the lack of commoncipher suites.5.1.1. Supported Elliptic Curves Extensionenum {sect163k1 (1), sect163r1 (2), sect163r2 (3),sect193r1 (4), sect193r2 (5), sect233k1 (6),sect233r1 (7), sect239k1 (8), sect283k1 (9),sect283r1 (10), sect409k1 (11), sect409r1 (12),sect571k1 (13), sect571r1 (14), secp160k1 (15),secp160r1 (16), secp160r2 (17), secp192k1 (18),secp192r1 (19), secp224k1 (20), secp224r1 (21),secp256k1 (22), secp256r1 (23), secp384r1 (24),secp521r1 (25),reserved (0xFE00..0xFEFF),arbitrary_explicit_prime_curves(0xFF01),arbitrary_explicit_char2_curves(0xFF02),(0xFFFF)} NamedCurve;sect163k1, etc: Indicates support of the corresponding named curve or class of explicitly defined curves. The named curves definedhere are those specified in SEC 2 [13]. Note that many of thesecurves are also recommended in ANSI X9.62 [7] and FIPS 186-2 [11]. Values 0xFE00 through 0xFEFF are reserved for private use. Values 0xFF01 and 0xFF02 indicate that the client supports arbitraryprime and characteristic-2 curves, respectively (the curveparameters must be encoded explicitly in ECParameters).The NamedCurve name space is maintained by IANA. See Section 8 forinformation on how new value assignments are added.struct {NamedCurve elliptic_curve_list<1..2^16-1>} EllipticCurveList;Blake-Wilson, et al. Informational [Page 12]Items in elliptic_curve_list are ordered according to the client’spreferences (favorite choice first).As an example, a client that only supports secp192r1 (aka NIST P-192; value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015) and prefers to use secp192r1 would include a TLS extension consisting of the following octets. Note that the first two octets indicate the extension type (Supported Elliptic Curves Extension):00 0A 00 06 00 04 00 13 00 15A client that supports arbitrary explicit characteristic-2 curves(value 0xFF02) would include an extension consisting of the following octets:00 0A 00 04 00 02 FF 025.1.2. Supported Point Formats Extensionenum { uncompressed (0), ansiX962_compressed_prime (1),ansiX962_compressed_char2 (2), reserved (248..255)} ECPointFormat;struct {ECPointFormat ec_point_format_list<1..2^8-1>} ECPointFormatList;Three point formats are included in the definition of ECPointFormatabove. The uncompressed point format is the default format in thatimplementations of this document MUST support it for all of theirsupported curves. Compressed point formats reduce bandwidth byincluding only the x-coordinate and a single bit of the y-coordinate of the point. Implementations of this document MAY support theansiX962_compressed_prime and ansiX962_compressed_char2 formats,where the former applies only to prime curves and the latter applies only to characteristic-2 curves. (These formats are specified in[7].) Values 248 through 255 are reserved for private use.The ECPointFormat name space is maintained by IANA. See Section 8for information on how new value assignments are added.Items in ec_point_format_list are ordered according to the client’spreferences (favorite choice first).Blake-Wilson, et al. Informational [Page 13]A client that can parse only the uncompressed point format (value 0) includes an extension consisting of the following octets; note thatthe first two octets indicate the extension type (Supported PointFormats Extension):00 0B 00 02 01 00A client that in the case of prime fields prefers the compressedformat (ansiX962_compressed_prime, value 1) over the uncompressedformat (value 0), but in the case of characteristic-2 fields prefers the uncompressed format (value 0) over the compressed format(ansiX962_compressed_char2, value 2), may indicate these preferences by including an extension consisting of the following octets:00 0B 00 04 03 01 00 025.2. Server Hello ExtensionThis section specifies a TLS extension that can be included with the ServerHello message as described in [4], the Supported Point Formats Extension.When this extension is sent:The Supported Point Formats Extension is included in a ServerHellomessage in response to a ClientHello message containing the Supported Point Formats Extension when negotiating an ECC cipher suite.Meaning of this extension:This extension allows a server to enumerate the point formats it can parse (for the curve that will appear in its ServerKeyExchangemessage when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon keyexchange algorithm, or for the curve that is used in the server’spublic key that will appear in its Certificate message when using the ECDH_ECDSA or ECDH_RSA key exchange algorithm).Structure of this extension:The server’s Supported Point Formats Extension has the same structure as the client’s Supported Point Formats Extension (seeSection 5.1.2). Items in elliptic_curve_list here are orderedaccording to the server’s preference (favorite choice first). Notethat the server may include items that were not found in the client’s list (e.g., the server may prefer to receive points in compressedformat even when a client cannot parse this format: the same clientmay nevertheless be capable of outputting points in compressedformat).Blake-Wilson, et al. Informational [Page 14]。

中国移动通信企业标准QB-╳╳-╳╳╳-╳╳╳╳家庭网关终端技术规范T e c h n i c a l S p e c i f i c a t i o n f o r H o m e G a t e w a y版本号：3.0.0╳╳╳╳-╳╳-╳╳发布╳╳╳╳-╳╳-╳╳实施中国移动通信集团公司发布目录1. 范围 ................................................................................................................................................2. 规范性引用文件 .............................................................................................................................3. 术语、定义和缩略语 .....................................................................................................................4. 设备总体定义.................................................................................................................................4.1.设备在网络中的位置 ..................................................................................................................4.2.接口定义 ......................................................................................................................................4.3.设备类型 ......................................................................................................................................5. 接入型家庭网关 .............................................................................................................................5.1.接口要求 ......................................................................................................................................网络侧接口......................................................................................................................................网络侧接口描述..........................................................................................................................................网络侧以太网接口要求..............................................................................................................................接口要求 .......................................................................................................................................................接口要求 .......................................................................................................................................................接口要求 .......................................................................................................................................................用户侧接口......................................................................................................................................用户侧以太网接口要求..............................................................................................................................接口 ...............................................................................................................................................................接口（可选）................................................................................................................................................5.2.功能要求 ......................................................................................................................................数据通信要求..................................................................................................................................协议要求 .......................................................................................................................................................数据转发功能要求......................................................................................................................................功能要求 .......................................................................................................................................................地址管理及拨号管理功能要求....................................................................................................................地址管理及拨号管理功能要求....................................................................................................................要求 ...............................................................................................................................................................要求 ...............................................................................................................................................................组播要求 .....................................................................................................................................................其他功能要求..............................................................................................................................................安全要求..........................................................................................................................................防火墙 .........................................................................................................................................................登陆WEB页面的安全要求..........................................................................................................................设备安全性 .................................................................................................................................................要求....................................................................................................................................................功能要求............................................................................................................................................扩展及管理（可选）........................................................................................................................设备发现要求.........................................................................................................................................................................................................................................................................................................（可选） .......................................................................................................................................................支持WLAN的开启和禁用............................................................................................................................基本要求 .....................................................................................................................................................多SSID要求................................................................................................................................................安全要求 .......................................................................................................................................................5要求 ............................................................................................................................................................要求 ...............................................................................................................................................................基本应用要求................................................................................................................................... WLAN共享 ..................................................................................................................................................家庭存储（可选）......................................................................................................................................5.3.性能要求 ......................................................................................................................................路由转发性能要求..........................................................................................................................吞吐量 .........................................................................................................................................................地址学习 .....................................................................................................................................................缓存大小 (23)连接数量要求.............................................................................................................................................. 无线性能要求....................................................................................................................................吞吐量性能要求 (23)覆盖性能要求................................................................................................................................................接收灵敏度要求............................................................................................................................................5.4.管理和维护要求 (24)本地管理和配置要求......................................................................................................................本地管理基本要求......................................................................................................................................用户分级管理 (24)系统信息管理..............................................................................................................................................基本配置 .....................................................................................................................................................高级配置 .....................................................................................................................................................设备管理 .....................................................................................................................................................网络诊断 .....................................................................................................................................................设备认证注册功能......................................................................................................................................远程管理要求..................................................................................................................................远程管理基本要求......................................................................................................................................远程参数配置和性能监测..........................................................................................................................远程故障诊断功能......................................................................................................................................设备告警功能..............................................................................................................................................远程链路维持功能......................................................................................................................................软件远程管理..............................................................................................................................................业务部署和控制..........................................................................................................................................上行家庭网关远程管理实现方式 ................................................................................................................日志功能要求..................................................................................................................................5.5.预配置要求 ..................................................................................................................................预配置要求......................................................................................................................................5.6.硬件要求 ......................................................................................................................................基本要求..........................................................................................................................................硬件基本框图示例..........................................................................................................................5.7.软件要求 ......................................................................................................................................基本要求..........................................................................................................................................软件基本架构................................................................................................. 错误!未定义书签。

中国移动通信企业标准中国移动C M -I M S 试点测试规范 —— C S C F /B G C F 设备分册C h i n a M o b i l e C M -I M S T r i a lT e s t i n g S p e c i f i c a t i o n-C S C F /B G C F 版本号：1.1.0 中国移动通信集团公司 发布╳╳╳╳-╳╳-╳╳发布 ╳╳╳╳-╳╳-╳╳实施QB-╳╳-╳╳╳-╳╳╳╳目录1. 范围 (1)2. 规范性引用文件 (1)3. 术语、定义和缩略语 (1)4. 测试环境及说明 (2)4.1. 测试环境配置 (2)4.2. CM-IMS网络总体架构 ......................................................... 错误！未定义书签。

5. 设备功能测试 (3)5.1. P-CSCF (3)5.1.1. 用户注册/注销 (4)5.1.2. 注册异常处理 (11)5.1.3. 会话管理 (13)5.1.4. 会话与事务异常处理 (17)5.2. I-CSCF (21)5.2.1. 用户注册处理 (22)5.2.2. 注册异常处理 (23)5.2.3. 会话管理 (27)5.2.4. 网络拓扑隐藏处理......................................................... 错误！未定义书签。

5.3. S-CSCF (28)5.3.1. 用户注册/注销处理 (29)5.3.2. 异常处理 (42)5.3.3. 会话管理 (43)5.3.4. S-CSCF会话控制异常处理 (47)5.4. BGCF (50)5.5. 安全相关测试 (52)5.5.1. HTTP Digest (52)6. 编制历史 (56)前言本规范是依据中国移动IMS设备规范及3GPP相关协议规定而制定的，内容包括中国移动IMS网络中涉及的网元设备（P-CSCF、I-CSCF、S-CSCF/BGCF）的功能、接口规程、信令配合、维护、测量、性能、软硬件要求等方面，目的是在CM-IMS试点阶段，指导中国移动各分公司用于CSCF及BGCF设备入网测试，保证中国移动IMS网络中所涉及的网元设备的互通以及在网络中正常可靠地运行。

sip协议initial requestSIP协议：初始请求详解随着互联网技术的发展，网络通信协议的重要性日益凸显。

其中，SIP（Session Initiation Protocol）协议作为一种新兴的多媒体通信协议，广泛应用于VoIP（语音）、视频、流媒体等应用场景。

本文将详细介绍SIP协议的初始请求过程，帮助读者了解其工作原理，并提供实用的信息和建议。

一、SIP协议概述SIP是一种基于文本的通信协议，主要用于建立、修改和终止多媒体会话。

它独立于底层网络，适用于不同的网络环境，如互联网、移动通信网络等。

SIP协议包含三个主要实体：用户代理（User Agent）、SIP服务器（SIP Server）和代理服务器（Proxy）。

二、初始请求过程SIP协议的初始请求过程主要包括三个步骤：请求（Request）、响应（Response）和重定向（Redirection）。

1. 请求：当用户想要开始一个多媒体会话时，用户代理向代理服务器发送一个INVITE请求。

这个请求包含了会话的相关信息，如目标地址、媒体类型等。

2. 响应：代理服务器接收到请求后，根据实际情况返回适当的响应。

如果会话已经存在，则返回200 OK响应；如果会话不存在或请求无效，则返回其他类型的响应。

3. 重定向：如果代理服务器无法处理请求，它会返回一个重定向响应，指示用户代理向其他服务器发送请求。

三、实用信息和建议1. SIP协议的配置和使用需要一定的专业知识，建议读者在了解基本原理的基础上，参考相关文档和指南进行操作。

2. 了解SIP协议的工作原理对于开发基于SIP的应用程序非常重要。

读者可以参考相关文档和教程，学习如何编写SIP客户端和服务器代码。

3. SIP协议的安全性是一个重要问题。

读者需要了解如何保护通信数据的安全，如使用加密算法对消息进行加密。

4. 对于希望在特定网络环境中使用SIP协议的用户，了解该环境的网络架构和限制非常重要。

PSTN Phone
SIP Phone
Uni Phone
MPhGoCnPe
H.323 Phone
SIP 逻辑实体
UAS：用户代理服务端 UAC：用户代理客户端，
UAC和UAS是一个逻辑功能，发起请求的一方为UAC，处理请求的一方为UAS。根据此刻正在 处理的消息，SIP设备实体不停在UAC和UAS间转换，即UAC／UAS角色在事物中存在。可以 将UAC理解为初始化请求的一段代码，并且在事务中遵循UAC的规则。如果它接下来收到一个 请求，那么在那个事务中，它就是作为UAS来处理请求；UAS同理。 代理服务器：代理服务器接收SIP请求并将其路由至其他代理服务器或最终用户 重定向服务器：重定向服务器收到请求时，可以通过应答将路由信息推送到客户端，客户端收 到应答可以重新向指定的服务器发起请求 注册服务器：用来接受UAC的注册请求，登记用户的联系方式信息，如果存在定位服务器，把 信息写入定位服务器
来重定向呼叫。 401:在进行这项请求之前,用户需要授权 403:禁止请求——不要再次尝试 407:在行进之前,首先用户代理授权 501:因为没有实现该服务,服务器不能供给该请 603:被叫用户拒绝该呼叫
以上为常用的status-code，更多code参考RFC 3261协议
头域定义
头域定义一
务进行排序的，提供事务的唯一标志，并且区分请求和请求的重发 Contact 会话参与者的联系方式
头域定义二
message-body定义
Message-body由头域中的Content-type决定，在SIP中，一般为基于RFC 2327 SDP的会话描 述(Session Description)，会话双方通过交换会话描述信息协商会话的媒体类型及相关参数，具 体规范参考RFC3264 offer/answer model with sdp

the final error response in a provisional response. The Reason header
field is a candidate to be used for such encapsulation.
Schulzrinne, et. al. Standards Track [Page 2]
RFC 3326 The Reason Header Field for SIP December 2002
Initially, the Reason header field defined here appears to be most
useful for BYE and CANCEL requests, but it can appear in any request
6. Acknowledgments ............................................ 7
7. Authors' Addresses ......................................... 7
8. Normative References ....................................... 7
December 2002
The Reason Header Field for the Session Initiation Protocol (SIP)
Status of this Memo
3.4. ISUP interworking .......................................... 5
4. IANA Considerations ........................................ 6

SIP: Session Initiation Protocol目录1、SIP协议介绍92、SIP协议功能概况103、术语124、实施概览125、协议的结构226、协议的定义247、SIP消息：337．1 请求347．2应答357.3 头域367.3.1 头域格式。

367.3.2 头域分类。

397.3.3 缩写格式407.4包体407.4.1 消息正文类型(MessageBodyType)407.4.2 消息体长度417.5 分帧的SIP消息（Framing SIP Messages）418 一般用户代理行为418.1 UAC特性428.1.1 产生一个请求428.1.1.1 Request-URI438.1.1.2 TO438.1.1.3 From448.1.1.4 Call-ID458.1.1.5 Cseq468.1.1.6 Max-Forwards468.1.1.7 Via478.1.1.8 Contact488.1.1.9 Supported 和 Require488.1.1.10 附加信息部分498.1.2 发送一个请求498.1.3 处理应答508.1.3.1: transaction 层的错误508.1.3.2 未知的应答518.1.3.3 Vias518.1.3.4 处理3xx应答518.1.3.5 处理4xx应答538.2 UAS特性548.2.1 方法判定558.2.2 XX判断558.2.2.1 TO 和Request-URI558.2.2.2 合并的请求568.2.2.3 Require568.2.3 内容处理578.2.4 应用扩展588.2.5 处理请求588.2.6 产生应答598.2.6.1 发送一个临时应答598.2.6.2 XX和Tags598.2.7 无状态UAS行为608.3 重定向服务器619 取消一个请求(Cancel)639.1 客户行为(Client Behavior)639.2 服务端行为(Server Behavior)6510 注册(Registrations)6610.1 概览6610.2 构造一个REGISTER请求6710.2.1 增加绑定7010.2.1.1 设置Contact地址的过期参数7110.2.2 删除绑定7110.2.3 访问绑定7210.2.4 刷新绑定7210.2.5 设置内部时钟7310.2.6 寻找注册服务器7310.2.7 传送一个请求7310.2.8 错误响应7410.3 处理REGISTER请求7411 查询能力7711.1 构造OPTIONS请求7811.2 处理OPTIONS请求7912 对话(Dialog)8112.1 创建一个对话8212.1.1 UAS行为8312.1.2 UAC行为8412.2 对话中的请求8512.2.1 UAC行为8612.1.1.1 产生请求8612.2.1.2 处理应答8812.2.2 UAS行为8912.3 终止对话9013 初始化一个会话9013.1 概览9013.2 UAC处理9113.2.1 创建一个初始化的INVITE9113.2.2处理INVITE应答9413.2.2.1 1xx应答9413.2.2.2 3xx应答9513.2.2.3 4xx,5xx,6xx应答9513.2.2.4 2xx 应答9513.3 UAS处理9713.3.1 处理INVITE9713.3.1.1 提示进度9813.3.1.2 INVITE请求转发9913.3.1.3 INVITE请求的拒绝9913.3.1.4 接受INVITE请求9914 更改已经存在的会话10014.1 UAC行为10114.2 UAS行为10315 结束一个会话10415.1 使用BYE请求终止一个会话10615.1.1 UAC行为10615.1.2 UAS行为10616 proxy行为10716.1 概述10716.2 有状态的proxy10816.3 验证请求11016.4 路由信息预处理11216.5 确定请求的目的11316.6 请求转发11516.7 应答的处理12516.8 处理定时器C13416.9 处理通讯层的错误13416.10 CANCEL处理13516.11 无状态的proxy13616.12 Proxy Route处理的总结13816.12.1例子13916.12.1.1 基本SIP四边形13916.12.1.2 穿越一个严格路由proxy141 17事务14417.1 客户端事务14717.1.1 INVITE客户事务14717.1.1.1 INVITE事务概述14717.1.1.2 正式的描述14817.1.1.3 构造ACK请求15217.1.2 非INVITE客户端事务15417.1.2.2 正式的描述15417.1.3 客户端事务匹配应答15617.1.4 处理通讯错误15617.2 服务端事务15817.2.1 INVITE服务端事务15817.2.2 非INVITE服务端事务16117.2.3 为服务端事务匹配请求。

Network Working Group R. Mahy Request for Comments: 3891 Cisco Systems, Inc. Category: Standards Track B. Biggs R. Dean September 2004 The Session Initiation Protocol (SIP) "Replaces" HeaderStatus of this MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2004).AbstractThis document defines a new header for use with Session InitiationProtocol (SIP) multi-party applications and call control. TheReplaces header is used to logically replace an existing SIP dialogwith a new SIP dialog. This primitive can be used to enable avariety of features, for example: "Attended Transfer" and "CallPickup". Note that the definition of these example features is non- normative.Mahy, et al. Standards Track [Page 1]Table of Contents1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 22. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 43. User Agent Server Behavior: Receiving a Replaces Header . . . 44. User Agent Client Behavior: Sending a Replaces Header . . . . 65. Proxy Behavior. . . . . . . . . . . . . . . . . . . . . . . . 76. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. The Replaces Header . . . . . . . . . . . . . . . . . . 76.2. New Option Tag for Require and Supported Headers. . . . 87. Usage Examples. . . . . . . . . . . . . . . . . . . . . . . . 97.1. Replacing an Early Dialog at the Originator . . . . . . 98. Security Considerations . . . . . . . . . . . . . . . . . . . 119. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9.1. Registration of "Replaces" SIP Header . . . . . . . . . 139.2. Registration of "replaces" SIP Option-tag . . . . . . . 1310. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 1311. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References. . . . . . . . . . . . . . . . . . 1311.2. Informative References. . . . . . . . . . . . . . . . . 1412. Authors’ Addresses. . . . . . . . . . . . . . . . . . . . . . 1513. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 16 1. OverviewThis document describes a SIP [1] extension header field as part ofthe SIP multiparty applications architecture framework [10]. TheReplaces header is used to logically replace an existing SIP dialogwith a new SIP dialog. This is especially useful in peer-to-peercall control environments.One use of the "Replaces" header is to replace one participant withanother in a multimedia conversation. While this functionality isalready available using 3rd party call control [11] style callcontrol, the 3pcc model requires a central point of control which may not be desirable in many environments. As such, a method ofperforming these same call control primitives in a distributed,peer-to-peer fashion is very desirable.Use of a new INVITE with a new header for dialog matching was chosen over making implicit associations in an incoming INVITE based oncall-id or other fields for the following reasons:o An INVITE already has the correct semantics for a new callo Using an explicit Replaces header in a new request makes theintent of the request obvious.Mahy, et al. Standards Track [Page 2]o A unique call-id may be given to the replacement call. Thisavoids dialog matching problems in any of the related User Agents. o There are no adverse effects if the header is unsupported.The Replaces header enables services such as attended call transfer, retrieve from park, and transition from locally mixed conferences to two party calls in a distributed peer-to-peer way. This list ofservices is not exhaustive. Although the Replaces header isfrequently used in combination with the REFER [8] method as used in a Transfer [12], they may be used independently.For example, Alice is talking to Bob from phone1. She transfers Bob to a Parking Place while she goes to the lab. When she gets thereshe retrieves the "parked" call from phone2 by sending an INVITE with a Replaces header field to Bob with the dialog information Bob shared with the Parking Place. Alice got this information using some out of band mechanism. Perhaps she subscribed to this information from the Parking Place (using the session dialog package [13]), or went to awebsite and clicked on a URI. A short call flow for this examplefollows. (Via and Max-Forwards headers are omitted for clarity.)Alice Alice Parkingphone1 phone2 Bob Place| | | ||<===============================>| || | | || Alice transfers Bob to Parking Place || | | ||------------REFER/200----------->| *1 *2 ||<--NOTIFY/200 (trying)-----------|--INVITE/200/ACK-->||<--NOTIFY/200 (success)----------|<=================>||------------BYE/200------------->| || | | || | | || Alice later retrieves call from another phone || | | || *3 |-INV w/Replaces->| || |<--200-----------| || |---ACK---------->|----BYE/200------->|| |<===============>| || | | |Mahy, et al. Standards Track [Page 3]Message *1: Bob-> Parking PlaceINVITE sip:parkingplace@ SIP/2.0To: <sip:parkingplace@>From: <sip:bob@>;tag=7743Call-ID: 425928@CSeq: 1 INVITEContact: <sip:bob@>Referred-By: <sip:alice@>Message *2: Parking Place -> BobSIP/2.0 200 OKTo: <sip:parkingplace@>;tag=6472From: <sip:bob@>;tag=7743Call-ID: 425928@CSeq: 1 INVITEContact: <sip:parkplace@>Message *3: Alice@phone2 -> BobINVITE sip:bob@To: <sip:bob@>From: <sip:alice@>;tag=8983Call-ID: 09870@CSeq: 1 INVITEContact: <sip:alice@>Require: replacesReplaces: 425928@;to-tag=7743;from-tag=64722. ConventionsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2]. This document refers frequently to the terms "confirmed dialog" and"early dialog". These are defined in Section 12 of SIP [1].3. User Agent Server Behavior: Receiving a Replaces HeaderThe Replaces header contains information used to match an existingSIP dialog (call-id, to-tag, and from-tag). Upon receiving an INVITE with a Replaces header, the User Agent (UA) attempts to match thisinformation with a confirmed or early dialog. The User Agent Server (UAS) matches the to-tag and from-tag parameters as if they were tags Mahy, et al. Standards Track [Page 4]present in an incoming request. In other words, the to-tag parameter is compared to the local tag, and the from-tag parameter is compared to the remote tag.If more than one Replaces header field is present in an INVITE, or if a Replaces header field is present in a request other than INVITE,the UAS MUST reject the request with a 400 Bad Request response.The Replaces header has specific call control semantics. If both aReplaces header field and another header field with contradictorysemantics are present in a request, the request MUST be rejected with a 400 "Bad Request" response.If the Replaces header field matches more than one dialog, the UAMUST act as if no match is found.If no match is found, the UAS rejects the INVITE and returns a 481Call/Transaction Does Not Exist response. Likewise, if the Replaces header field matches a dialog which was not created with an INVITE,the UAS MUST reject the request with a 481 response.If the Replaces header field matches a dialog which has alreadyterminated, the UA SHOULD decline the request with a 603 Declinedresponse. (If the matched invitation was just terminated, thereplacement request should fail as well. Declining the request with a 600-class response prevents an irritating race-condition where the UA rings or alerts for a replacement call which is not wanted.)If the Replaces header field matches an active dialog, the UA MUSTverify that the initiator of the new INVITE is authorized to replace the matched dialog. If the initiator of the new INVITE has beensuccessfully authenticated as equivalent to the user who is beingreplaced, then the replacement is authorized. For example, if theuser being replaced and the initiator of the replacement dialog share the same credentials for Digest authentication [6], or they sign the replacement request with S/MIME [7] with the same private key andpresent the (same) corresponding certificate used in the originaldialog, then the replacement is authorized.Alternatively, the Referred-By mechanism [4] defines a mechanism that the UAS can use to verify that a replacement request was sent onbehalf of the other participant in the matched dialog (in this case, triggered by a REFER request). If the replacement request contains a Referred-By header that corresponds to the user being replaced, theUA SHOULD treat the replacement as if the replacement was authorized by the replaced party. The Referred-By header SHOULD reference acorresponding, valid Refererred-By Authenticated Identity Body [5]. Mahy, et al. Standards Track [Page 5]The UA MAY apply other local policy to authorize the remainder of the request. In other words, the UAS may apply a different policy to the replacement dialog than was applied to the replaced dialog.In addition, the UA MAY use other authorization mechanisms definedfor this purpose in standards track extensions. Extensions coulddefine other mechanisms for transitively asserting authorization of a replacement.If authorization is successful, the UA attempts to accept the newINVITE, reassign the user interface and other resources of thematched dialog to the new INVITE, and shut down the replaced dialog. If the UA cannot accept the new INVITE (for example: it cannotestablish required QoS or keying, or it has incompatible media), the UA MUST return an appropriate error response and MUST leave thematched dialog unchanged.If the Replaces header field matches a confirmed dialog, it checksfor the presence of the "early-only" flag in the Replaces headerfield. (This flag allows the UAC to prevent a potentiallyundesirable race condition described in Section 7.1.) If the flag is present, the UA rejects the request with a 486 Busy response.Otherwise, it accepts the new INVITE by sending a 200-class response, and shuts down the replaced dialog by sending a BYE. If the Replaces header field matches an early dialog that was initiated by the UA, it accepts the new INVITE by sending a 200-class response, and shutsdown the replaced dialog by sending a CANCEL.If the Replaces header field matches an early dialog that was notinitiated by this UA, it returns a 481 (Call/Transaction Does NotExist) response to the new INVITE, and leaves the matched dialogunchanged. Note that since Replaces matches only a single dialog,the replacement dialog will not be retargeted according to the sameforking logic as the original request which created the early dialog. (Currently, no use cases have been identified for replacing just asingle dialog in this circumstance.)4. User Agent Client Behavior: Sending a Replaces HeaderA User Agent that wishes to replace a single existing early orconfirmed dialog with a new dialog of its own, MAY send the targetUser Agent an INVITE request containing a Replaces header field. The User Agent Client (UAC) places the Call-ID, to-tag, and from-taginformation for the target dialog in a single Replaces header fieldand sends the new INVITE to the target. If the user agent onlywishes to replace an early dialog (as in the Call Pickup example inSection 7.1), the UAC MAY also include the "early-only" parameter in Mahy, et al. Standards Track [Page 6]the Replaces header field. A UAC MUST NOT send an INVITE with aReplaces header field that attempts to replace an early dialog which was not originated by the target of the INVITE with a Replaces header field.Note that use of this mechanism does not provide a way to matchmultiple dialogs, nor does it provide a way to match an entire call, an entire transaction, or to follow a chain of proxy forking logic.For example, if Alice replaces Cathy in an early dialog with Bob, but Bob does not answer, Alice’s replacement request will not match other dialogs to which Bob’s UA redirects, nor other branches to which his proxy forwards. Although this specification takes reasonableprecautions to prevent unexpected behavior in the face of forking,implementations SHOULD only address replacement requests (i.e., setthe Request-URI of the replacement request) to the SIP Contact URI of the target.5. Proxy behaviorProxy Servers do not require any new behavior to support thisextension. They simply pass the Replaces header field transparently as described in the SIP specification.Note that it is possible for a proxy (especially when forking basedon some application layer logic, such as caller screening or time-of-day routing) to forward an INVITE request containing a Replacesheader field to a completely orthogonal set of Contacts other thanthe original request it was intended to replace. In this case, theINVITE request with the Replaces header field will fail.6. Syntax6.1. The Replaces HeaderThe Replaces header field indicates that a single dialog identifiedby the header field is to be shut down and logically replaced by the incoming INVITE in which it is contained. It is a request headeronly, and defined only for INVITE requests. The Replaces headerfield MAY be encrypted as part of end-to-end encryption. Only asingle Replaces header field value may be present in a SIP request.This document adds the following entry to Table 2 of [1]. Additions to this table are also provided for extension methods defined at the time of publication of this document. This is provided as a courtesy to the reader and is not normative in any way. MESSAGE, SUBSCRIBEand NOTIFY, REFER, INFO, UPDATE, PRACK, and PUBLISH are definedrespectively in [15], [16], [8], [17], [18], [19], and [20].Mahy, et al. Standards Track [Page 7]Header field where proxy ACK BYE CAN INV OPT REG MSG ------------ ----- ----- --- --- --- --- --- --- --- Replaces R - - - o - - -SUB NOT REF INF UPD PRA PUB --- --- --- --- --- --- --- Replaces R - - - - - - -The following syntax specification uses the augmented Backus-NaurForm (BNF) as described in RFC 2234 [3]. The syntax below relies on a number of productions from SIP [1].Replaces = "Replaces" HCOLON callid *(SEMI replaces-param) replaces-param = to-tag / from-tag / early-flag / generic-paramto-tag = "to-tag" EQUAL tokenfrom-tag = "from-tag" EQUAL tokenearly-flag = "early-only"A Replaces header field MUST contain exactly one to-tag and exactlyone from-tag, as they are required for unique dialog matching. Forcompatibility with dialogs initiated by RFC 2543 [9] compliant UAs, a tag of zero matches both tags of zero and null. A Replaces headerfield MAY contain the early-flag.Examples:Replaces: 98732@;from-tag=r33th4x0r;to-tag=ff87ffReplaces: 12adf2f34456gs5;to-tag=12345;from-tag=54321;early-onlyReplaces: 87134@171.161.34.23;to-tag=24796;from-tag=06.2. New Option Tag for Require and Supported HeadersThis specification defines a new Require/Supported header option tag "replaces". UAs which support the Replaces header MUST include the"replaces" option tag in a Supported header field. UAs that wantexplicit failure notification if Replaces is not supported MAYinclude the "replaces" option in a Require header field.Example:Require: replaces, 100relMahy, et al. Standards Track [Page 8]7. Usage ExamplesThe following non-normative examples are not intended to enumerateall the possibilities for the usage of this extension, but rather to provide examples or ideas only. For more examples, please see SIPService Examples [14]. Via and Max-Forwards headers are omitted for clarity and brevity.7.1. Replacing an Early Dialog at the OriginatorIn this example, Bob just arrived in the lab and hasn’t registeredthere yet. He hears his desk phone ring. He quickly logs into asoftware UA on a nearby computer. Among other things, the softwareUA has access to the dialog state of his desk phone. When it notices that his phone is ringing, it offers him the choice of taking thecall there. The software UA sends an INVITE with Replaces to Alice. When Alice’s UA receives this new INVITE, it CANCELs her originalINVITE and connects Alice to Bob.Bob BobAlice desk lab| | |*1 |-----INVITE----------->| |*2 |<----180---------------| Bob hears desk phone || | ringing from lab but || | isn’t REGISTERed yet || | || |<--fetch dialog state --|| |---response ----------->|*3/4 |<-----INVITE with Replaces/200/ACK--------------|*5/6 |------CANCEL/200------>| |*7 |<-----487--------------| ||------ACK------------->| || | || | |Message *1: Alice -> Bob’s desk phoneINVITE sip:bob@ SIP/2.0To: <sip:bob@>From: <sip:alice@>;tag=7743Call-ID: 425928@CSeq: 1 INVITEContact: <sip:alice@>Mahy, et al. Standards Track [Page 9]Message *2: Bob’s desk phone -> AliceSIP/2.0 180 RingingTo: <sip:bob@>;tag=6472From: <sip:alice@>;tag=7743Call-ID: 425928@CSeq: 1 INVITEContact: <sip:bob@>Message *3: Bob in lab -> AliceINVITE sip:alice@To: <sip:alice@>From: <sip:bob@>;tag=8983Call-ID: 09870@CSeq: 1 INVITEContact: <sip:bob@>Replaces: 425928@;to-tag=7743;from-tag=6472;early-onlyMessage *4: Alice -> Bob in labSIP/2.0 200 OKTo: <sip:alice@>;tag=9232From: <sip:bob@>;tag=8983Call-ID: 09870@CSeq: 1 INVITEContact: <sip:alice@>Message *5: Alice -> Bob’s deskCANCEL sip:bob@ SIP/2.0To: <sip:bob@>From: <sip:alice@>;tag=7743Call-ID: 425928@CSeq: 1 CANCELContact: <sip:alice@>Message *6: Bob’s desk -> AliceSIP/2.0 200 OKTo: <sip:bob@>From: <sip:alice@>;tag=7743Call-ID: 425928@CSeq: 1 CANCELContact: <sip:bob@>Mahy, et al. Standards Track [Page 10]Message *7: Bob’s desk -> AliceSIP/2.0 487 Request TerminatedTo: <sip:bob@>;tag=6472From: <sip:alice@>;tag=7743Call-ID: 425928@CSeq: 1 INVITE8. Security ConsiderationsThe extension specified in this document significantly changes therelative security of SIP devices. Currently in SIP, even if aneavesdropper learns the Call-ID, To, and From headers of a dialog,they cannot easily modify or destroy that dialog if Digestauthentication or end-to-end message integrity are used.This extension can be used to disconnect participants or replaceparticipants in a multimedia conversation. As such, invitations with the Replaces header MUST only be accepted if the peer requestingreplacement has been properly authenticated using a standard SIPmechanism (Digest or S/MIME), and authorized to request a replacement of the target dialog. All SIP implementations are already requiredto support Digest Authentication. In addition, implementations which support the Replaces header SHOULD also implement the Referred-Bymechanism.How a User Agent determines which requests are legitimatelyauthorized to make dialog replacements is non-trivial and depends on a considerable amount of local policy configuration. In general,there are four cases when an authorization for a replacement isreasonable or warranted.1. Replacement made by a party considered equivalent to the replaced party2. Replacement made on behalf of the replaced party (perhapstransitively)3. Replacement made by a former participant4. Replacement made by a specifically authorized partyStarting with #1 for example, if an executive and an assistant bothreceive requests for a shared address-of-record, if so configured,either should be able to replace dialogs of the other for the shared identity. Both could even share the same keying material (Digest or S/MIME), or one could hold an authorization document signed by the Mahy, et al. Standards Track [Page 11]other expressing this relationship. Likewise, in a call centerenvironment, each call center agent could possess credentials towhich supervisors also have access.The most common use case of a replacement is on the request of thereplaced participant (who no longer wants to be involved). This isthe case in many features, such as completing an Attended Transferand converting a 3-way call to a point-to-point call. Suchreplacements are typically triggered by a REFER [8] request from the replaced participant. The Referred-By [4] mechanism defines one way to identify the apparent original requester and can point to a SIPAuthenticated Identity Body [5] (an S/MIME-based signed assertion) to secure this information.In the example in section 1, Alice sends an INVITE with Replaces toBob. Alice was a former participant in the conversation and had aprevious dialog relationship with Bob. Alice can use the same Digest or S/MIME credentials she used to authenticate with Bob during theoriginal call to prove that she was a former participant. Note that this justification for replacing calls is more dangerous than theothers, and in most cases is another way to authorize that thereplacing participant is available. Implementations SHOULD NOT rely on this method as an authorization mechanism.The last scenario is the easiest to secure but the least likely to be useful in practice. It is unlikely that an arbitrary host in theInternet is aware of any special authorization relationship betweenthe replaced and the replacing parties. However, this use case maybe useful in some environments. Since this usage does noteffectively degrade the security of the solution, it is stillallowed.Some mechanisms for obtaining the dialog information needed by theReplaces header (Call-ID, to-tag, and from-tag) include URIs on a web page, subscriptions to an appropriate event package, andnotifications after a REFER request. Since manipulating this dialog information could cause User Agents to replace the wrong dialog, use of message integrity protection for this information is STRONGLYRECOMMENDED. Use of end-to-end security mechanisms to encrypt thisinformation is also RECOMMENDED.This extension was designed to take advantage of future signature or authorization schemes defined in standards track extensions. Ingeneral, call control features benefit considerably from such work. Mahy, et al. Standards Track [Page 12]9. IANA Considerations9.1. Registration of "Replaces" SIP headerName of Header: ReplacesShort form: noneNormative description: section 6.1 of this document9.2. Registration of "replaces" SIP Option-tagName of option: replacesDescription: Support for the SIP Replaces headerSIP headers defined: ReplacesNormative description: This document10. AcknowledgmentsThanks to Robert Sparks, Alan Johnston, Dan Petrie, Ben Campbell, and many other members of the SIP WG for their continued support of thecause of distributed call control in SIP.11. References11.1. Normative References[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:Session Initiation Protocol", RFC 3261, June 2002.[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[3] Crocker, D. and P. Overell, "Augmented BNF for SyntaxSpecifications: ABNF", RFC 2234, November 1997.[4] Sparks, R., "The Session Initiation Protocol (SIP) Referred-ByMechanism", RFC 3892, September 2004.[5] Peterson, J., "The Session Initiation Protocol (SIP)Authenticated Identity Body (AIB) Format", RFC 3893, September2004.Mahy, et al. Standards Track [Page 13][6] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:Basic and Digest Access Authentication", RFC 2617, June 1999.[7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions(S/MIME) Version 3.1 Message Specification", RFC 3851, July2004.11.2. Informative References[8] Sparks, R., "The Session Initiation Protocol (SIP) ReferMethod", RFC 3515, April 2003.[9] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,"SIP: Session Initiation Protocol", RFC 2543, March 1999.[10] Mahy, R., "A Call Control and Multi-party usage framework forthe Session Initiation Protocol (SIP)", Work in Progress, March 2003.[11] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) inthe Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.[12] Sparks, R. and A. Johnston, "Session Initiation Protocol CallControl - Transfer", Work in Progress, February 2003.[13] Rosenberg, J. and H. Schulzrinne, "An INVITE Initiated DialogEvent Package for the Session Initiation Protocol (SIP)", Workin Progress, March 2003.[14] Johnston, A. and S. Donovan, "Session Initiation ProtocolService Examples", Work in Progress, March 2003.[15] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., andD. Gurle, "Session Initiation Protocol (SIP) Extension forInstant Messaging", RFC 3428, December 2002.[16] Roach, A., "Session Initiation Protocol (SIP)-Specific EventNotification", RFC 3265, June 2002.[17] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.[18] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATEMethod", RFC 3311, October 2002.Mahy, et al. Standards Track [Page 14][19] Rosenberg, J. and H. Schulzrinne, "Reliability of ProvisionalResponses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.[20] Campbell, B., "SIMPLE Presence Publication Mechanism", Work inProgress, February 2003.12. Authors’ AddressesRohan MahyCisco Systems, Inc.5617 Scotts Valley DrScotts Valley, CA 95066USAEMail: rohan@Billy BiggsEMail: bbiggs@Rick DeanEMail: rfc@Mahy, et al. Standards Track [Page 15]13. Full Copyright StatementCopyright (C) The Internet Society (2004).This document is subject to the rights, licenses and restrictionscontained in BCP 78, and except as set forth therein, the authorsretain all their rights.This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HEREPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS ORIMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OFTHE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual PropertyThe IETF takes no position regarding the validity or scope of anyIntellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described inthis document or the extent to which any license under such rightsmight or might not be available; nor does it represent that it hasmade any independent effort to identify any such rights. Information on the IETF’s procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.Copies of IPR disclosures made to the IETF Secretariat and anyassurances of licenses to be made available, or the result of anattempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of thisspecification can be obtained from the IETF on-line IPR repository at /ipr.The IETF invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietaryrights that may cover technology that may be required to implementthis standard. Please address the information to the IETF at ietf-ipr@.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Mahy, et al. Standards Track [Page 16]。

(RFC 3261取代了RFC 2543)
2
SIP (Session Initiation Protocol)
A Signaling Protocol 使用 IP Client / Server 架構 相似於 HTTP的文字編碼方式
sip:andy@.tw sip:+886424961356@.tw Request and Response
19
實作成果
VMS錄製、聽取語音留言
.tw/~jiayu/meeting/20070831/Recording.htm .tw/~jiayu/meeting/20070831/Listen.htm
IVR聽取語音留言
8
SIP封包格式
INVITE sip:bob@ SIP/2.0
Via: SIP/2.0/UDP ;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@>
From: Alice <sip:alice@>;tag=1928301774
Reference
1
SIP (Session Initiation Protocol)
由IETF的MMUSIC (Multiparty Multimedia Session Control) Working Group開發
RFC 2543 - SIP: Session Initiation Protocol RFC 3261 - SIP: Session Initiation Protocol
Bob
1. Invite
2. 100 Trying
3. Invite
4. 100 Trying

Network Working Group M. Barnes, Ed. Request for Comments: 4244 Nortel Category: Standards Track November 2005 An Extension to the Session Initiation Protocol (SIP)for Request History InformationStatus of This MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited. Copyright NoticeCopyright (C) The Internet Society (2005).AbstractThis document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP)request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specificapplication or user. This document defines a new optional SIPheader, History-Info, for capturing the history information inrequests.Table of Contents1. Introduction (2)1.1. Overview (2)1.2. Conventions Used in This Document (3)1.3. Background: Why define a Generic "Request History"capability? (3)2. "Request History" Requirements (4)2.1. Security Requirements (6)2.2. Privacy Requirements (7)3. Request History Information Description (7)3.1. Optionality of History-Info (8)3.2. Securing History-Info (8)3.3. Ensuring the Privacy of History-Info (9)4. Request History Information Protocol Details (9)4.1. Protocol Structure of History-Info (10)4.2. Protocol Examples (11)4.3. Protocol Usage (12)Barnes Standards Track [Page 1]4.3.1. User Agent Client (UAC) Behavior (12)4.3.2. User Agent Server (UAS) Behavior (13)4.3.3. Proxy Behavior (13)4.3.4. Redirect Server Behavior (18)4.4. Security for History-Info (18)4.5. Example Applications Using History-Info (19)4.5.1. Example with Privacy Header for EntireRequest at Proxy2 (21)4.5.2. Example with Privacy Header for SpecificURI (UA4) at Proxy2 (22)5. Application Considerations (24)6. Security Considerations (25)7. IANA Considerations (25)7.1. Registration of New SIP History-Info Header (25)7.2. Registration of "history" for SIP Privacy Header (26)8. Normative References (26)9. Informative References (26)10. Acknowledgements (26)11. Contributors’ Addresses (27)Appendix. Example Scenarios (28)Appendix A. Sequentially forking (History-Info in Response) (28)Appendix B. Voicemail (34)Appendix C. Automatic Call Distribution Example (39)Appendix D. Session via Redirect and Proxy Servers (41)1. Introduction1.1. OverviewMany services that SIP is anticipated to support require the ability to determine why and how the call arrived at a specific application. Examples of such services include (but are not limited to) sessionsinitiated to call centers via "click to talk" SIP Uniform ResourceLocators (URLs) on a web page, "call history/logging" style services within intelligent "call management" software for SIP User Agents(UAs), and calls to voicemail servers. Although SIP implicitlyprovides the redirect/retarget capabilities that enable calls to berouted to chosen applications, there is currently no standardmechanism within SIP for communicating the history of such a request. This "request history" information allows the receiving applicationto determine hints about how and why the call arrived at theapplication/user.This document defines a new SIP header, History-Info, to provide astandard mechanism for capturing the request history information toenable a wide variety of services for networks and end-users. TheHistory-Info header provides a building block for development of new services.Barnes Standards Track [Page 2]Section 1.3 provides additional background motivation for the Request History capability. Section 2 identifies the requirements for asolution, with Section 3 providing an overall description of thesolution.Section 4 provides the details of the additions to the SIP protocol. Example uses of the new header are included in Section 4.5, withadditional scenarios included in the Appendix.Section 5 summarizes the application considerations identified in the previous sections. Section 6 summarizes the security solution.1.2. Conventions Used in This DocumentThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].1.3. Background: Why define a Generic "Request History" capability?SIP implicitly provides redirect/retarget capabilities that enablecalls to be routed to specific applications as defined in [RFC3261]. The term ’retarget’ will be used henceforth in this document to refer to the process of a Proxy Server/User Agent Client (UAC) changing aUniform Resource Identifier (URI) in a request and thus changing the target of the request. This term is chosen to avoid associating this request history only with the specific SIP Redirect Server capability that provides for a response to be sent back to a UAC requesting that the UAC should retarget the original request to an alternate URI.The rules for determining request targets as described in Section16.5 of [RFC3261] are consistent with the use of the retarget term in this document.The motivation for the request history is that in the process ofretargeting, old routing information can be forever lost. This lost information may be important history that allows elements to whichthe call is retargeted to process the call in a locally defined,application-specific manner. The proposal in this document is toprovide a mechanism for transporting the request history. It is not proposing any application-specific behavior for a Proxy or UA uponreceipt of the information. Indeed, such behavior should be a local decision for the recipient application.Current network applications provide the ability for elementsinvolved with the call to exchange additional information relating to how and why the call was routed to a particular destination. Thefollowing are examples of such applications:Barnes Standards Track [Page 3]1. Web "referral" applications, whereby an application residingwithin a web server determines that a visitor to a website hasarrived at the site via an "associate" site that will receive some "referral" commission for generating this traffic2. Email forwarding whereby the forwarded-to user obtains a "history" of who sent the email to whom and at what time3. Traditional telephony services such as voicemail, call-center"automatic call distribution", and "follow-me" style servicesSeveral of the aforementioned applications currently defineapplication-specific mechanisms through which it is possible toobtain the necessary history information.In addition, request history information could be used to enhancebasic SIP functionality by providing the following:o Some diagnostic information for debugging SIP requests. (Note that the diagnostic utility of this mechanism is limited by the factthat its use by entities that retarget is optional.)o A stronger security solution for SIP. A side effect is that eachproxy that captures the "request history" information in a securemanner provides an additional means (without requiring signed keys) for the original requestor to be assured that the request wasproperly retargeted.2. "Request History" RequirementsThe following list constitutes a set of requirements for a "RequestHistory" capability.1) CAPABILITY-req: The "Request History" capability provides acapability to inform proxies and UAs involved in processing arequest about the history/progress of that request. Although this is inherently provided when the retarget is in response to a SIPredirect, it is deemed useful for non-redirect retargetingscenarios, as well.2) OPTIONALITY-req: The "Request History" information is optional.2.1) In many cases, it is anticipated that whether the history is added to the Request would be a local policy decisionenforced by the specific application; thus, no specificprotocol element is needed.Barnes Standards Track [Page 4]2.2) Due to the capability being "optional" from the SIP protocol perspective, the impact to an application of not having the"Request History" must be described. Applicabilityguidelines to be addressed by applications using thiscapability must be provided as part of the solution to these requirements.3) GENERATION-req: "Request History" information is generated whenthe request is retargeted.3.1) In some scenarios, it might be possible for more than oneinstance of retargeting to occur within the same Proxy. Aproxy should also generate Request History information forthe ’internal retargeting’.3.2) An entity (UA or proxy) retargeting in response to a redirect or REFER should include any Request History information from the redirect/REFER in the new request.4) ISSUER-req: "Request History" information can be generated by a UA or proxy. It can be passed in both requests and responses.5) CONTENT-req: The "Request History" information for eachoccurrence of retargeting shall include the following:5.1) The new URI or address to which the request is in the process of being retargeted,5.2) The URI or address from which the request was retargeted,5.3) The reason for the Request-URI or address modification,5.4) Chronological ordering of the Request History information.6) REQUEST-VALIDITY-req: Request History is applicable to requestsnot sent within an established dialog (e.g., INVITE, REGISTER,MESSAGE, and OPTIONS).7) BACKWARDS-req: Request History information may be passed from the generating entity backwards towards the UAC. This is needed toenable services that inform the calling party about the dialogestablishment attempts.8) FORWARDS-req: Request History information may also be included by the generating entity in the request, if it is forwarded onwards. Barnes Standards Track [Page 5]The Request History information is being inserted by a networkelement retargeting a Request, resulting in a slightly differentproblem than the basic SIP header problem, thus requiring specificconsideration. It is recognized that these security requirements can be generalized to a basic requirement of being able to secureinformation that is inserted by proxies.The potential security problems include the following:1) A rogue application could insert a bogus Request History entryeither by adding an additional entry as a result of retargeting or entering invalid information.2) A rogue application could re-arrange the Request Historyinformation to change the nature of the end application or tomislead the receiver of the information.3) A rogue application could delete some or all of the RequestHistory information.Thus, a security solution for "Request History" must meet thefollowing requirements:1) SEC-req-1: The entity receiving the Request History must be ableto determine whether any of the previously added Request Historycontent has been altered.2) SEC-req-2: The ordering of the Request History information must be preserved at each instance of retargeting.3) SEC-req-3: The entity receiving the information conveyed by theRequest History must be able to authenticate the entity providing the request.4) SEC-req-4: To ensure the confidentiality of the Request Historyinformation, only entities that process the request should havevisibility to the information.It should be noted that these security requirements apply to anyentity making use of the Request History information, either byretargeting and capturing the information, or as an applicationmaking use of the information received in either a Request orResponse.Barnes Standards Track [Page 6]Since the Request-URI that is captured could inadvertently revealinformation about the originator, there are general privacyrequirements that MUST be met:1) PRIV-req-1: The entity retargeting the Request must ensure that it maintains the network-provided privacy (as described in [RFC3323]) associated with the Request as it is retargeted.2) PRIV-req-2: The entity receiving the Request History must maintain the privacy associated with the information.In addition, local policy at a proxy may identify privacyrequirements associated with the Request-URI being captured in the Request History information.3) PRIV-req-3: Request History information subject to privacyrequirements shall not be included in outgoing messages unless it is protected as described in [RFC3323].3. Request History Information DescriptionThe fundamental functionality provided by the request historyinformation is the ability to inform proxies and UAs involved inprocessing a request about the history or progress of that request(CAPABILITY-req). The solution is to capture the Request-URIs as arequest is forwarded in a new header for SIP messages: History-Info(CONTENT-req). This allows for the capturing of the history of arequest that would be lost with the normal SIP processing involved in the subsequent forwarding of the request. This solution proposes no changes in the fundamental determination of request targets or in the request forwarding as defined in Sections 16.5 and 16.6 of the SIPprotocol specification [RFC3261].The History-Info header can appear in any request not associated with an established dialog (e.g., INVITE, REGISTER, MESSAGE, REFER andOPTIONS, PUBLISH and SUBSCRIBE, etc.) (REQUEST-VALIDITY-req) and any valid response to these requests (ISSUER-req).The History-Info header is added to a Request when a new request iscreated by a UAC or forwarded by a Proxy, or when the target of arequest is changed. The term ’retarget’ is introduced to refer tothis changing of the target of a request and the subsequentforwarding of that request. It should be noted that retargeting only occurs when the Request-URI indicates a domain for which theprocessing entity is responsible. In terms of the SIP protocol, the processing associated with retargeting is described in Sections 16.5 Barnes Standards Track [Page 7]and 16.6 of [RFC3261]. As described in Section 16.5 of [RFC3261], it is possible for the target of a request to be changed by the sameproxy multiple times (referred to as ’internal retargeting’ inSection 2), as the proxy MAY add targets to the target set afterbeginning Request Forwarding. Section 16.6 of [RFC3261] describesRequest Forwarding. It is during this process of Request Forwarding that the History Information is captured as an optional, additionalheader field. Thus, the addition of the History-Info header does not impact fundamental SIP Request Forwarding. An entity (UA or proxy)changing the target of a request in response to a redirect or REFERSHOULD also propagate any History-Info header from the initialRequest in the new request (GENERATION-req, FORWARDS-req).3.1. Optionality of History-InfoThe History-Info header is optional in that neither UAs nor Proxiesare required to support it. A new Supported header, "histinfo", isincluded in the Request to indicate whether the History-Info headeris returned in Responses (BACKWARDS-req). In addition to the"histinfo" Supported header, local policy determines whether or notthe header is added to any request, or for a specific Request-URI,being retargeted. It is possible that this could restrict theapplicability of services that make use of the Request HistoryInformation to be limited to retargeting within domain(s) controlled by the same local policy, or between domain(s) which negotiatepolicies with other domains to ensure support of the given policy, or services for which complete History Information isn’t required toprovide the service (OPTIONALITY-req). All applications making useof the History-Info header MUST clearly define the impact of theinformation not being available and specify the processing of such a request.3.2. Securing History-InfoThis document defines a new header for SIP. The use of the Transport Layer Security (TLS) protocol [RFC2246] as a mandatory mechanism toensure the overall confidentiality of the History-Info headers (SEC- req-4) is strongly RECOMMENDED. This results in History-Info having at least the same level of security as other headers in SIP that are inserted by intermediaries. If TLS is not available for theconnection over which the request is being forwarded, then therequest MUST NOT include the History-Info header or the request MUST be redirected to the client, including the History-Info header, sothat the request can be retargeted by the client.With the level of security provided by TLS (SEC-req-3), theinformation in the History-Info header can thus be evaluated todetermine if information has been removed by evaluating the indices Barnes Standards Track [Page 8]for gaps (SEC-req-1, SEC-req-2). It would be up to the applicationto define whether it can make use of the information in the case ofmissing entries.Note that while using the SIPS scheme protects History-Info fromtampering by arbitrary parties outside the SIP message path, all the intermediaries on the path are trusted implicitly. A maliciousintermediary could arbitrarily delete, rewrite, or modify History-Info. This specification does not attempt to prevent or detectattacks by malicious intermediaries.3.3. Ensuring the Privacy of History-InfoSince the History-Info header can inadvertently reveal informationabout the requestor as described in [RFC3323], the Privacy headerSHOULD be used to determine whether an intermediary can include theHistory-Info header in a Request that it receives and forwards(PRIV-req-2) or that it retargets (PRIV-req-1). Thus, the History-Info header SHOULD NOT be included in Requests where the requestorhas indicated a priv-value of Session- or Header-level privacy.In addition, the History-Info header can reveal general routinginformation, which may be viewed by a specific intermediary ornetwork, to be subject to privacy restrictions. Thus, local policyMAY also be used to determine whether to include the History-Infoheader at all, whether to capture a specific Request-URI in theheader, or whether it be included only in the Request as it isretargeted within a specific domain (PRIV-req-3). In the lattercase, this is accomplished by adding a new priv-value, history, tothe Privacy header [RFC3323] indicating whether any or a specificHistory-Info header(s) SHOULD be forwarded.It is recognized that satisfying the privacy requirements can impact the functionality of this solution by overriding the request togenerate the information. As with the optionality and securityrequirements, applications making use of History-Info SHOULD address any impact this may have or MUST explain why it does not impact theapplication.4. Request History Information Protocol DetailsThis section contains the details and usage of the proposed new SIPprotocol elements. It also discusses the security aspects of thesolution.Barnes Standards Track [Page 9]4.1. Protocol Structure of History-InfoHistory-Info is a header field as defined by [RFC3261]. It is anoptional header field and MAY appear in any request or response notassociated with a dialog or which starts a dialog. For example,History-Info MAY appear in INVITE, REGISTER, MESSAGE, REFER, OPTIONS, SUBSCRIBE, and PUBLISH and any valid responses, plus NOTIFY requests that initiate a dialog.This document adds the following entry to Table 2 of [RFC3261]. The additions to this table are also provided for extension methods atthe time of publication of this document. This is provided as acourtesy to the reader and is not normative in any way.Header field where proxy ACK BYE CAN INV OPT REG MSG ------------ ----- ----- --- --- --- --- --- --- --- History-Info amdr - - - o o o oSUB NOT REF INF UPD PRA PUB --- --- --- --- --- --- --- History-Info amdr o o o - - - oThe History-Info header carries the following information, with themandatory parameters required when the header is included in arequest or response:o Targeted-to-URI (hi-targeted-to-uri): A mandatory parameter forcapturing the Request-URI for the specific Request as it isforwarded.o Index (hi-index): A mandatory parameter for History-Inforeflecting the chronological order of the information, indexed to also reflect the forking and nesting of requests. The format for this parameter is a string of digits, separated by dots toindicate the number of forward hops and retargets. This results in a tree representation of the history of the request, with the lowest-level index reflecting a branch of the tree. By addingthe new entries in order (i.e., following existing entries perthe details in Section 4.3.3.1), including the index and securing the header, the ordering of the History-Info headers in therequest is assured (SEC-req-2). In addition, applications mayextract a variety of metrics (total number of retargets, totalnumber of retargets from a specific branch, etc.) based upon the index values.o Reason: An optional parameter for History-Info, reflected in the History-Info header by including the Reason Header [RFC3326]escaped in the hi-targeted-to-uri. A reason is not included for Barnes Standards Track [Page 10]a hi-targeted-to-uri when it is first added in a History-Infoheader, but rather is added when the retargeting actually occurs. Note that this does appear to complicate the security problem;however, retargeting only occurs when the hi-targeted-to-uriindicates a domain for which the processing entity isresponsible. Thus, it would be the same processing entity thatinitially added the hi-targeted-to-URI to the header that wouldbe updating it with the Reason.o Privacy: An optional parameter for History-Info, reflected in the History-Info header field values by including the Privacy Header [RFC3323] with a priv-value of "history" escaped in the hi-targeted-to-uri or by adding the Privacy header with a priv-value of "history" to the Request. The use of the Privacy Header with a priv-value of "history" indicates whether a specific or allHistory-Info headers should not be forwarded.o Extension (hi-extension): An optional parameter to allow forfuture optional extensions. As per [RFC3261], any implementation not understanding an extension should ignore it.The following summarizes the syntax of the History-Info header, based upon the standard SIP syntax [RFC3261]:History-Info = "History-Info" HCOLONhi-entry *(COMMA hi-entry)hi-entry = hi-targeted-to-uri *( SEMI hi-param )hi-targeted-to-uri= name-addrhi-param = hi-index / hi-extensionhi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT)hi-extension = generic-param4.2. Protocol ExamplesThe following provides some examples of the History-Info header.Note that the backslash and CRLF between the fields in the examplesbelow are for readability purposes only.History-Info:<sip:UserA@?Reason=SIP%3B\cause%3D302>;index=1;foo=barHistory-Info: <sip:UserA@?Reason=SIP%3B \cause%3D302>; index=1.1,Barnes Standards Track [Page 11]<sip:UserB@?Privacy=history&Reason=SIP%3B\cause%3D486>;index=1.2,<sip:45432@>;index=1.34.3. Protocol UsageThis section describes the processing specific to UAs and Proxies for the History-Info header, the "histinfo" option tag, and the priv-value of "history". As discussed in Section 1.3, the fundamentalobjective is to capture the target Request-URIs as a request isforwarded. This allows for the capturing of the history of a request that would be lost due to subsequent (re)targeting and forwarding.To accomplish this for the entire history of a request, either theUAC must capture the Request-URI in a History-Info header in theinitial request or a proxy must add a History-Info header with both a hi-entry for the Request-URI in the initial request and a hi-entryfor the target Request-URI as the request is forwarded. The basicprocessing is for each entity forwarding a request to add a hi-entry for the target Request-URI, updating the index and adding the Reason as appropriate for any retargeted Request-URI.4.3.1. User Agent Client (UAC) BehaviorThe UAC SHOULD include the "histinfo" option tag in the Supportedheader in any request not associated with an established dialog forwhich the UAC would like the History-Info header in the response. In addition, the UAC MAY improve the diagnostic utility of its requestby adding a History-Info header, using the Request-URI of the request as the hi-target-to-uri and initializing the index to the RECOMMENDED value of 1 in the hi-entry. As a result, intermediaries and the UAS will know at least the original Request-URI, and if the Request-URIwas modified by a previous hop.In the case where the request is routed to a redirect server and the UAC receives a 3xx response with a Contact header, the UAC MAYmaintain the previous hi-entry(s) in the request. In this case, the reason header SHOULD be associated with the hi-targeted-to-uri in the previous (last) hi-entry, as described in Section 4.3.3.1.2. A newhi-entry MAY then be added for the URI from the Contact header (which becomes the new Request-URI). In this case, the index is created by reading and incrementing the value of the index from the previoushi-entry, thus following the same rules as those prescribed for aproxy in retargeting, described in Section 4.3.3.1.3. An example ofthis scenario can be found in Appendix D.A UAC that does not want the History-Info header added due to privacy considerations SHOULD include a Privacy header with a priv-value(s)of "session", "header", or "history" in the request.Barnes Standards Track [Page 12]With the exception of the processing of a 3xx response describedabove, the processing of the History-Info header received in theResponse is application specific and outside the scope of thisdocument. However, the validity of the information SHOULD be ensured prior to any application usage. For example, the entries MAY beevaluated to determine gaps in indices, which could indicate that an entry has been maliciously removed or removed for privacy reasons.Either way, an application MAY want to be aware of potentiallymissing information.4.3.2. User Agent Server (UAS) BehaviorThe processing of the History-Info header by a UAS in a Requestdepends upon local policy and specific applications at the UAS thatmight make use of the information. Prior to any application usage of the information, the validity SHOULD be ascertained. For example,the entries MAY be evaluated to determine gaps in indices, whichcould indicate that an entry has been maliciously removed or removed for privacy reasons. Either way, an application MAY want to be aware of potentially missing information.If the "histinfo" option tag is received in a request, the UAS SHOULD include any History-Info received in the request in the subsequentresponse.4.3.3. Proxy BehaviorThe inclusion of the History-Info header in a Request does not alter the fundamental processing of proxies for determining request targets as defined in Section 16.5 of [RFC3261]. Whether a proxy adds theHistory-Info header or a new hi-entry as it forwards a Requestdepends upon the following considerations:1. Whether the Request contains the "histinfo" option tag in theSupported header.2. Whether the proxy supports the History-Info header.3. Whether the Request contains a Privacy header with a priv-value of "session", "header", or "history".4. Whether any History-Info header added for a proxy/domain should go outside that domain. An example being the use of theHistory-Info header within the specific domain in which it isretargeted, however, policies (for privacy, user and networksecurity, etc.) would prohibit the exposure of that information outside that domain. To accommodate such a scenario, a proxyMAY insert the Privacy header with a priv-value of "history"when the request is being forwarded within the same domain. An example of such an application is provided in Appendix C. Barnes Standards Track [Page 13]。

RFC 3666 SIP Public Switched Telephone Network (PSTN) Call Flows.
RFC 3680 SIP Event Package for Registrations
RFC 3702 Authentication, Authorization, and Accounting Requirements for the SIP
RFC 3515 The Session Initiation Protocol (SIP) Refer Method
RFC 3578 Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the SIP
RFC 4244 An Extension to the SIP for Request History Information
RFC 4245 High-Level Requirements for Tightly Coupled SIP Conferencing
RFC 4320 Actions Addressing Identified Issues with the SIP's Non-INVITE Transaction
RFC 3581 An Extension to the SIP for Symmetric Response Routing
RFC 3603 Private SIP Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture.

Reliable Provisional Responses、
EarlyMedia扩展需求
• 扩展目的
– 传递可靠的呼叫进展 – 传递被叫侧的媒体描述
• 扩展方法
– 扩展消息 PRACK
• 为1xx响应提供消息确认
– 扩展消息头 RSeq／RAck
• 保证PRACK与对应的1xx匹配
– 1xx响应扩展消息头：RSeq – PRACK请求扩展消息头：RAck
• PRACK是1xx的“最终响应”
– 如果INVITE-1xx完成了Offer-Answer，PRACK-200PRACK可 以完成进一步的Offer-Answer
• PRACK－200PRACK是可靠传输的
– 如果可靠的1xx携带Answer，则必须建立Session
• 一次Offer-Answer结束了 • Early Session
ANM
200
INVITE ACK
200 INVITE
ACK
64 T1 ACM
ANM
CPG ?
如何传递呼叫中事件
STATE KEY LABORATORY TELECOMMUNICATION NETWORK
需求的分析（续）
UserA
INVITE SDP 100
– 增加消息
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
与传统Telephony业务互通的努力
• IETF
– Session Initiation Protocol for Telephones – 俗称 SIP-T
• ITU-T

Internet Engineering Task Force (IETF) K. Drage Request for Comments: 6050 Alcatel-Lucent Category: Informational November 2010 ISSN: 2070-1721A Session Initiation Protocol (SIP) Extensionfor the Identification of ServicesAbstractThis document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. The use of these extensions isonly applicable inside an administrative domain with previouslyagreed-upon policies for generation, transport, and usage of suchinformation. This document does NOT offer a general serviceidentification model suitable for use between different trust domains or for use in the Internet at large.The document also defines a URN to identify both services and UserAgent (UA) applications. This URN can be used within the SIP header fields defined in this document to identify services, and also within the framework defined for caller preferences and callee capabilities to identify usage of both services and applications between end UAs.Status of This MemoThis document is not an Internet Standards Track specification; it is published for informational purposes.This document is a product of the Internet Engineering Task Force(IETF). It represents the consensus of the IETF community. It hasreceived public review and has been approved for publication by theInternet Engineering Steering Group (IESG). Not all documentsapproved by the IESG are a candidate for any level of InternetStandard; see Section 2 of RFC 5741.Information about the current status of this document, any errata,and how to provide feedback on it may be obtained at/info/rfc6050.Drage Informational [Page 1]Copyright NoticeCopyright (c) 2010 IETF Trust and the persons identified as thedocument authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s LegalProvisions Relating to IETF Documents(/license-info) in effect on the date ofpublication of this document. Please review these documentscarefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e ofthe Trust Legal Provisions and are provided without warranty asdescribed in the Simplified BSD License.Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 32. Applicability Statement . . . . . . . . . . . . . . . . . . . 53. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 64. Syntax of the Header Fields . . . . . . . . . . . . . . . . . 6 4.1. The P-Asserted-Service Header . . . . . . . . . . . . . . 6 4.2. The P-Preferred-Service Header . . . . . . . . . . . . . . 7 4.3. Service and Application Definition . . . . . . . . . . . . 84.4. Registration Template . . . . . . . . . . . . . . . . . . 85. Usage of the P-Preferred-Service and P-Asserted-ServiceHeader Fields . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Usage of the P-Preferred-Service andP-Asserted-Service Header Fields in Requests . . . . . . . 10 5.1.1. Procedures at User Agent Clients (UAC) . . . . . . . . 10 5.1.2. Procedures at Intermediate Proxies . . . . . . . . . . 11 5.1.3. Procedures at User Agent Servers . . . . . . . . . . . 12 5.2. Usage of the P-Preferred-Service andP-Asserted-Service Header Fields in Responses . . . . . . 126. Examples of Usage . . . . . . . . . . . . . . . . . . . . . . 127. Security Considerations . . . . . . . . . . . . . . . . . . . 158. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8.1. P-Asserted-Service and P-Preferred-Service HeaderFields . . . . . . . . . . . . . . . . . . . . . . . . . . 168.2. Definition of Service-ID Values . . . . . . . . . . . . . 169. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 Drage Informational [Page 2]1. IntroductionThis document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service, possibly subject to the user being entitled to thatservice. The use of these extensions is only applicable inside anadministrative domain with previously agreed-upon policies forgeneration, transport, and usage of such information. This document does NOT offer a general service model suitable for use betweendifferent trust domains or for use in the Internet at large.The concept of "service" within SIP has no hard and fast rules. RFC 5897 [RFC5897] provides general guidance on what constitutes aservice within SIP and what does not.This document also makes use of the terms "derived serviceidentification" and "declarative service identification" as definedin RFC 5897 [RFC5897].It should be noted that RFC 5897 [RFC5897] clearly states thatdeclarative service identification -- the process by which a useragent inserts a moniker into a message that defines the desiredservice, separate from explicit and well-defined protocol mechanisms -- is harmful.During a session setup, proxies may need to understand what servicethe request is related to in order to know what application server to contact or other service logic to invoke. The SIP INVITE requestcontains all of the information necessary to determine the service.However, the calculation of the service may be computational anddatabase intensive. For example, a given trust domain’s definitionof a service might include request authorization. Moreover, theanalysis may require examination of the Session Description Protocol (SDP).For example, an INVITE request with video SDP directed to a video-on- demand Request-URI could be marked as an IPTV session. An INVITErequest with push-to-talk over cellular (PoC) routes could be marked as a PoC session. An INVITE request with a Require header fieldcontaining an option tag of "foogame" could be marked as a foogamesession.NOTE: If the information contained within the SIP INVITE request isnot sufficient to uniquely identify a service, the remedy is toextend the SIP signaling to capture the missing element. RFC 5897[RFC5897] provides further explanation.Drage Informational [Page 3]By providing a mechanism to compute and store the results of thedomain-specific service calculation, i.e., the derived serviceidentification, this optimization allows a single trusted proxy toperform an analysis of the request and authorize the requestor’spermission to request such a service. The proxy may then include aservice identifier that relieves other trusted proxies and trustedUAs from performing further duplicate analysis of the request fortheir service identification purposes. In addition, this extensionallows user agent clients outside the trust domain to provide a hint of the requested service.This extension does not provide for the dialog or transaction to berejected if the service is not supported end-to-end. SIP providesother mechanisms, such as the option-tag and use of the Require andProxy-Require header fields, where such functionality is required.No explicitly signaled service identification exists, and the session proceeds for each node’s definition of the service in use, on thebasis of information contained in the SDP and in other SIP headerfields.This mechanism is specifically for managing the information needs of intermediate routing devices between the calling user and the userrepresented by the Request-URI. In support of this mechanism, a URN is defined to identify the services. This URN has widerapplicability to additionally identify services and terminalapplications. Between end users, caller preferences and calleecapabilities as specified in RFC 3840 [RFC3840] and RFC 3841[RFC3841] provide an appropriate mechanism for indicating suchservice and application identification. These mechanisms have beenextended by RFC 5688 [RFC5688] to provide further capabilities inthis area.The mechanism proposed in this document relies on a new header field called ’P-Asserted-Service’ that contains a URN. This is supportedby a further new header field called ’P-Preferred-Service’ that also contains a URN and that allows the UA to express preferencesregarding the decisions made on service within the trust domain.An example of the P-Asserted-Service header field is:P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1 A proxy server that handles a request can, after authenticating theoriginating user in some way (for example: digest authentication) to ensure that the user is entitled to that service, insert such aP-Asserted-Service header field into the request and forward it to Drage Informational [Page 4]other trusted proxies. A proxy that is about to forward a request to a proxy server or UA that it does not trust removes all theP-Asserted-Service header field values.This document labels services by means of an informal URN. Thisprovides a hierarchical structure for defining services andsubservices, and provides an address that can be resolvable forvarious purposes outside the scope of this document, e.g., to obtain information about the service so described.2. Applicability StatementThis document describes private extensions to SIP (see RFC 3261[RFC3261]) that enable a network of trusted SIP servers to assert the service of end users or end systems. The use of these extensions is only applicable inside a ’trust domain’ as defined in "Short TermRequirements for Network Asserted Identity" (see RFC 3324 [RFC3324]). Nodes in such a trust domain are explicitly trusted by its users and end systems to publicly assert the service of each party, and thatthey have common and agreed-upon definitions of services andhomogeneous service offerings. The means by which the networkdetermines the service to assert is outside the scope of thisdocument (though it commonly entails some form of authentication).The mechanism for defining a trust domain is to provide a certain set of specifications known as ’Spec(T)’, and then specify compliance to that set of specifications. Spec(T) MUST specify behavior asdocumented in RFC 3324 [RFC3324].This document does NOT offer a general service model suitable forinter-domain use or use in the Internet at large. Its assumptionsabout the trust relationship between the user and the network may not apply in many applications. For example, these extensions do notaccommodate a model whereby end users can independently assert their service by use of the extensions defined here. End users asserttheir service by including the SIP and SDP parameters that correspond to the service they require. Furthermore, since the assertedservices are not cryptographically certified, they are subject toforgery, replay, and falsification in any architecture that does not meet the requirements of RFC 3324 [RFC3324].The asserted services also lack an indication of who specifically is asserting the service, and so it must be assumed that a member of the trust domain is asserting the service. Therefore, the information is only meaningful when securely received from a node known to be amember of the trust domain.Drage Informational [Page 5]Despite these limitations, there are sufficiently useful specialized deployments, that meet the assumptions described above and can accept the limitations that result, to warrant informational publication of this mechanism.3. ConventionsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119[RFC2119].Throughout this document, requirements for or references to proxyservers or proxy behavior apply similarly to other intermediarieswithin a trust domain (for example, back-to-back user agents(B2BUAs)).The term trust domain in this document has the meaning as defined in RFC 3324 [RFC3324].4. Syntax of the Header FieldsThe following syntax specification uses the augmented Backus-NaurForm (BNF) as described in RFC 5234 [RFC5234].4.1. The P-Asserted-Service HeaderThe P-Asserted-Service header field is used among trusted SIPentities (typically intermediaries) to carry the service information of the user sending a SIP message.The P-Asserted-Service header field carries information that isderived service identification. While a declarative serviceidentification can assist in deriving the value transferred in thisheader field, this should be in the form of streamlining the correct derived service identification.PAssertedService = "P-Asserted-Service"HCOLON PAssertedService-valuePAssertedService-value = Service-ID *(COMMA Service-ID)See Section 4.4 for the definition of Service-ID in ABNF.Proxies can (and will) add and remove this header field.Drage Informational [Page 6]Table 1 adds the header fields defined in this document to Table 2 in SIP [RFC3261], Section 7.1 of the SIP-specific event notification[RFC3265], Tables 1 and 2 in the SIP INFO method [RFC2976], Tables 1 and 2 in the reliability of provisional responses in SIP [RFC3262],Tables 1 and 2 in the SIP UPDATE method [RFC3311], Tables 1 and 2 in the SIP extension for instant messaging [RFC3428], Table 1 in the SIP REFER method [RFC3515], and Tables 2 and 3 in the SIP PUBLISH method [RFC3903]:Header field where proxy ACK BYE CAN INV OPT REG SUB _______________________________________________________________ P-Asserted-Service R admr - - - o o - oHeader field NOT PRA INF UPD MSG REF PUB _______________________________________________________________ P-Asserted-Service - - - - o o oTable 1Syntactically, there may be multiple P-Asserted-Service header fields in a request. The semantics of multiple P-Asserted-Service headerfields appearing in the same request is not defined at this time.Implementations of this specification MUST provide only oneP-Asserted-Service header field value.4.2. The P-Preferred-Service HeaderThe P-Preferred-Service header field is used by a user agent sending the SIP request to provide a hint to a trusted proxy of the preferred service that the user wishes to be used for the P-Asserted-Servicefield value that the trusted element will insert.The P-Preferred-Service header field carries information that isdeclarative service identification. Such information should only be used to assist in deriving a derived service identification at therecipient entity.PPreferredService = "P-Preferred-Service"HCOLON PPreferredService-valuePPreferredService-value = Service-ID *(COMMA Service-ID)See Section 4.4 for the definition of Service-ID in ABNF.Table 2 adds the header fields defined in this document to Table 2 in SIP [RFC3261], Section 7.1 of the SIP-specific event notification[RFC3265], Tables 1 and 2 in the SIP INFO method [RFC2976], Tables 1 and 2 in Reliability of provisional responses in SIP [RFC3262],Drage Informational [Page 7]Tables 1 and 2 in the SIP UPDATE method [RFC3311], Tables 1 and 2 in the SIP extension for Instant Messaging [RFC3428], Table 1 in the SIP REFER method [RFC3515], and Tables 2 and 3 in the SIP PUBLISH method [RFC3903]:Header field where proxy ACK BYE CAN INV OPT REG SUB _______________________________________________________________ P-Preferred-Service R dr - - - o o - oHeader field NOT PRA INF UPD MSG REF PUB _______________________________________________________________ P-Preferred-Service - - - - o o oTable 2Syntactically, there may be multiple P-Preferred-Service headerfields in a request. The semantics of multiple P-Preferred-Serviceheader fields appearing in the same request is not defined at thistime. Implementations of this specification MUST only provide oneP-Preferred-Service header field value.4.3. Service and Application DefinitionService definitions and characteristics are outside the scope of this document. Other standards organizations, vendors, and operators may define their own services and register them.A hierarchical structure is defined consisting of service identifiers or application identifiers, and subservice identifiers.The service and subservice identifiers are as described in Section 1. The URN may also be used to identify a service or an applicationbetween end users for use within the context of RFC 3840 [RFC3840]and RFC 3841 [RFC3841].IANA maintains a registry of service identifier values that have been assigned. This registry has been created by the actions of Section8.2 of this document.subservice identifiers are not managed by IANA. It is theresponsibility of the organization that registered the service tomanage the subservices.4.4. Registration TemplateBelow, we include the registration template for the URN schemeaccording to RFC 3406 [RFC3406]. The URN scheme is defined as aninformal Namespace ID (NID).Drage Informational [Page 8]Namespace ID: urn-7Registration Information:Registration version: 1; registration date: 2009-03-22Declared registrant of the namespace: 3GPP Specifications Manager(3gppContact@) (+33 (0)492944200)Declaration of syntactic structure: The URN consists of ahierarchical service identifier or application identifier, with a sequence of labels separated by periods. The leftmost label isthe most significant one and is called ’top-level serviceidentifier’, while names to the right are called ’subservices’ or ’sub-applications’. The set of allowable characters is the sameas that for domain names (see RFC 1123 [RFC1123]) and a subset of the labels allowed in RFC 3958 [RFC3958]. Labels are case-insensitive and MUST be specified in all lowercase. For any given service identifier, labels can be removed right-to-left and theresulting URN is still valid, referring a more generic service,with the exception of the top-level service identifier andpossibly the first subservice or sub-application identifier.Labels cannot be removed beyond a defined basic service; forexample, the label w.x may define a service, but the label w mayonly define an assignment authority for assigning subsequentvalues and not define a service in its own right. In other words, if a service identifier ’w.x.y.z’ exists, the URNs ’w.x’ and’w.x.y’ are also valid service identifiers, but w may not be avalid service identifier if it merely defines who is responsiblefor defining x.Service-ID = "urn:urn-7:" urn-service-idurn-service-id = top-level *("." sub-service-id)top-level = let-dig [ *26let-dig ]sub-service-id = let-dig [ *let-dig ]let-dig = ALPHA / DIGIT / "-"While the naming convention above uses the term "service", all the constructs are equally applicable to identifying applicationswithin the UA.Relevant ancillary documentation: NoneIdentifier uniqueness considerations: A service identifieridentifies a service, and an application identifier an application indicated in the service or application registration (see IANAConsiderations (Section 8)). Uniqueness is guaranteed by the IANA registration.Drage Informational [Page 9]Identifier persistence considerations: The service or applicationidentifier for the same service or application is expected to bepersistent, although there naturally cannot be a guarantee that a particular service will continue to be available globally or atall times.Process of identifier assignment: The process of identifierassignment is described in the IANA Considerations (Section 8).Process for identifier resolution: There is no single globalresolution service for service identifiers or applicationidentifiers.Rules for lexical equivalence: ’service’ identifiers are comparedaccording to case-insensitive string equality.Conformance with URN syntax: The BNF in the ’Declaration ofsyntactic structure’ above constrains the syntax for this URNscheme.Validation mechanism: Validation determines whether a given stringis currently a validly assigned URN (see RFC 3406 [RFC3406]). Due to the distributed nature of usage and since not all services are available everywhere, validation in this sense is not possible.Scope: The scope for this URN can be local to a single domain, ormay be more widely used.5. Usage of the P-Preferred-Service and P-Asserted-Service HeaderFields5.1. Usage of the P-Preferred-Service and P-Asserted-Service HeaderFields in Requests5.1.1. Procedures at User Agent Clients (UAC)The UAC MAY insert a P-Preferred-Service in a request that creates a dialog, or a request outside of a dialog. This information canassist the proxies in identifying appropriate service capabilities to apply to the call. This information MUST NOT conflict with other SIP or SDP information included in the request. Furthermore, the SIP or SDP information needed to signal functionality of this service MUSTbe present. Thus, if a service requires a video component, then the SDP has to include the media line associated with that videocomponent; it cannot be assumed from the P-Preferred-Service headerfield value. Similarly, if the service requires particular SIPDrage Informational [Page 10]functionality for which a SIP extension and a Require header fieldvalue is defined, then the request has to include that SIP signaling as well as the P-Preferred-Service header field value.A UAC that is within the same trust domain as the proxy to which itsends a request (e.g., a media gateway or application server) MAYinsert a P-Asserted-Service header field in a request that creates a dialog, or a request outside of a dialog. This information MUST NOT conflict with other SIP or SDP information included in the request.Furthermore, the SIP or SDP information needed to signalfunctionality of this service MUST be present.5.1.2. Procedures at Intermediate ProxiesA proxy in a trust domain can receive a request from a node that ittrusts or a node that it does not trust. When a proxy receives arequest from a node it does not trust and it wishes to add aP-Asserted-Service header field, the proxy MUST identify the service appropriate to the capabilities (e.g., SDP) in the request, MAYauthenticate the originator of the request (in order to determinewhether the user is subscribed for that service). Where theoriginator of the request is authenticated, the proxy MUST use theidentity that results from this checking and authentication to insert a P-Asserted-Service header field into the request.When a proxy receives a request containing a P-Preferred-Serviceheader field, the Proxy MAY use the contents of that header field to assist in determining the service to be included in a P-Asserted-Service header field (for instance, to prioritize the order ofcomparison of filter criteria for potential services that the request could match). The proxy MUST NOT use the contents of theP-Preferred-Service header field to identify the service withoutfirst checking against the capabilities (e.g., SDP) contained in the request. If the proxy inserts a P-Asserted-Service header field inthe request, the proxy MUST remove the P-Preferred-Service headerfield before forwarding the request; otherwise, the Proxy SHOULDinclude the P-Preferred-Service header field when forwarding therequest.If the proxy receives a request from a node that it trusts, it canuse the information in the P-Asserted-Service header field, if any,as if it had authenticated the user itself.If there is no P-Asserted-Service header field present, or it is not possible to match the request to a specific service as identified by the service identifier, a proxy MAY add one containing it using itsown analysis of the information contained in the SIP request. If the proxy received the request from an element that it does not trust and Drage Informational [Page 11]there is a P-Asserted-Service header present, the proxy MUST replace that header field’s contents with a new analysis or remove thatheader field.The analysis performed to identify such service identifiers isoutside the scope of this document. However, it is perfectly validas a result of the analysis not to include any service identifier in the forwarded request, and thus not include a P-Asserted-Serviceheader field.If a proxy forwards a request to a node outside the proxy’s trustdomain, there MUST NOT be a P-Asserted-Service header field in theforwarded request.5.1.3. Procedures at User Agent ServersFor a User Agent Server (UAS) outside the trust domain, theP-Asserted-Service header is removed before it reaches this entity;therefore, there are no procedures for such a device.However, if a UAS receives a request from a previous element that it does not trust, it MUST NOT use the P-Asserted-Service header fieldin any way.If a UA is part of the trust domain from which it received a request containing a P-Asserted-Service header field, then it can use thevalue freely, but it MUST ensure that it does not forward theinformation to any element that is not part of the trust domain.5.2. Usage of the P-Preferred-Service and P-Asserted-Service HeaderFields in ResponsesThere is no usage of these header fields in responses.6. Examples of UsageIn this example, creates a P-Asserted-Serviceheader field from the user identity it discovered from SIP digestauthentication, the list of services appropriate to that user, andthe services that correspond to the SDP information included in therequest. Note that F1 and F2 are about identifying the user and donot directly form part of the capability provided in this document.It forwards this information to a trusted proxy that forwards it to a trusted gateway. Note that these examples consist of partial SIPmessages that illustrate only those header fields relevant to theauthenticated identity problem.Drage Informational [Page 12]* F1 -> INVITE sip:+14085551212@ SIP/2.0Via: SIP/2.0/TCP ;branch=z9hG4bK-123To: <sip:+14085551212@>From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748Call-ID: 245780247857024504CSeq: 1 INVITEMax-Forwards: 70v=0o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddds=-c=IN IP6 5555::aaa:bbb:ccc:dddt=0 0m=audio 3456 RTP/AVPF 97 96b=AS:25.4a=curr:qos local sendrecva=curr:qos remote nonea=des:qos mandatory local sendrecva=des:qos mandatory remote sendrecva=sendrecva=rtpmap:97 AMRa=fmtp:97 mode-set=0,2,5,7; maxframes* F2 -> SIP/2.0 407 Proxy AuthorizationVia: SIP/2.0/TCP ;branch=z9hG4bK-123To: <sip:+14085551212@>;tag=123456From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748Call-ID: 245780247857024504CSeq: 1 INVITEProxy-Authenticate: .... realm=""* F3 -> INVITE sip:+14085551212@ SIP/2.0Via: SIP/2.0/TCP ;branch=z9hG4bK-124To: <sip:+14085551212@>From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748Call-ID: 245780247857024504CSeq: 2 INVITEMax-Forwards: 70Proxy-Authorization: realm="" user="fluffy"Drage Informational [Page 13]。

Session Initiation Protocol (SIP):SIP服务器定位本文档状态本文档为Internet 团体定义了一个Internet standards track协议。

并且请求对这个文档进行讨论以便改进。

请参阅当前版本的”InternetOfficalProtocol Stands”(STD1)来确认本文档的标准化状态以及本协议的状态。

对本文档的发布是没有限制的。

版本信息Copyright （C）The Internet Society(2002). All Rights Reserved.概述SIP协议使用了DNS步骤来使得客户端能够把一个标准的SIP格式的资源（SIP URI）解析成为IP地址，端口，以及使用的协议。

同样SIP也支持服务端在客户端的主机失效的情况下使用DNS来向备份的客户端发送应答。

本文档描述了这些DNS的详细过程。

1．介绍SIP（RFC3261）是一个客户端/服务端的协议，它用来创建用户之间的通讯会话和管理用户之间的通讯会话的。

SIP 的终端系统叫做UA（用户代理），中间的结点叫做proxy 服务器。

一个典型的SIP配置，叫做一个SIP”梯形”,就像在图1中表示的一样。

在这个图中，呼叫方在domain A(UA1),希望呼叫在domain B的用户Joe(Joe@b)。

为了完成这个呼叫，他首先和在自己域内部的proxy1（domain A中的proxy 1）。

Proxy1向被叫方域的proxy 服务器（proxy2）转发这个请求。

Proxy2转发这个请求到被叫方，UA2。

作为呼叫流的一部分，proxy1需要确定domain B的SIP服务器。

为了能够确定这个，proxy1 使用DNS的步骤，使用SRV[2]和NAPTR[3]记录来确定这个地址。

本文档描述了SIP使用DNS的相关问题，并且提供了解决方法。

2．DNS需要解决的相关问题为了能够解决上边介绍的一般呼叫流所需要确定的呼叫双方两方面的问题，我们需要使用DNS。