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

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协议的用户，了解该环境的网络架构和限制非常重要。

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 为服务端事务匹配请求。