MUST NOT Requirements: MN-1: In this document, the key words "MUST", "**MUST NOT**", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations. MN-2: The Request-URI **MUST NOT** contain unescaped spaces or control characters and MUST NOT be enclosed in "<>". MN-3: The Request-URI MUST NOT contain unescaped spaces or control characters and **MUST NOT** be enclosed in "<>". MN-4: field rows with these names MAY be present in a message, but since their grammar does not follow the general form listed in Section 7.3, they **MUST NOT** be combined into a single header field row. MN-5: Even though an arbitrary number of parameter pairs may be attached to a header field value, any given parameter-name **MUST NOT** appear more than once. MN-6: The "chunked" transfer encoding of HTTP/1.1 **MUST NOT** be used for SIP. MN-7: A request outside of a dialog **MUST NOT** contain a To tag; the tag in the To field of a request identifies the peer of the dialog. MN-8: As with proxy recursion, a client processing 3xx class responses **MUST NOT** add any given URI to the target set more than once. MN-9: If it is rejected, all state changes **MUST NOT** be performed. MN-10: Note that Require and Proxy-Require **MUST NOT** be used in a SIP CANCEL request, or in an ACK request sent for a non-2xx response. MN-11: A UAS that wishes to apply some extension when generating the response **MUST NOT** do so unless support for that extension is indicated in the Supported header field in the request. MN-12: Of course, the server **MUST NOT** apply extensions not listed in the Supported header field in the request. MN-13: o A stateless UAS **MUST NOT** send provisional (1xx) responses. MN-14: o A stateless UAS **MUST NOT** retransmit responses. MN-15: However, redirect servers **MUST NOT** redirect a request to a URI equal to the one in the Request-URI; instead, provided that the URI does not point to itself, the server MAY proxy the request to the destination URI, or MAY reject it with a 404. MN-16: The CANCEL request **MUST NOT** contain any Require or Proxy-Require header fields. MN-17: If no provisional response has been received, the CANCEL request **MUST NOT** be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request. MN-18: In particular, the UAC **MUST NOT** create a new route set based on the presence or absence of a Record-Route header field in any response to a REGISTER request. MN-19: The "userinfo" and "@" components of the SIP URI **MUST NOT** be present. MN-20: UAs **MUST NOT** send a new registration (that is, containing new Contact header field values, as opposed to a retransmission) until they have received a final response from the registrar for the previous one or the previous REGISTER request has timed out. MN-21: The REGISTER-specific Contact header field value of "*" applies to all registrations, but it **MUST NOT** be used unless the Expires header field is present with a value of "0". MN-22: Registrars **MUST NOT** include a Record-Route header field in any response to a REGISTER request. MN-23: The UAC **MUST NOT** add a Route header field to the request. MN-24: o Once the UAS has sent or received an answer to the initial offer, it **MUST NOT** generate subsequent offers in any responses to the initial INVITE. MN-25: Note that a UAC **MUST NOT** initiate a new INVITE transaction within a dialog while another INVITE transaction is in progress in either direction. MN-26: A UA **MUST NOT** send a BYE outside of a dialog. MN-27: The caller's UA MAY send a BYE for either confirmed or early dialogs, and the callee's UA MAY send a BYE on confirmed dialogs, but **MUST NOT** send a BYE on early dialogs. MN-28: However, the callee's UA **MUST NOT** send a BYE on a confirmed dialog until it has received an ACK for its 2xx response or until the server transaction times out. MN-29: Notice that a proxy is not required to detect merged requests and **MUST NOT** treat merged requests as an error condition. MN-30: An element **MUST NOT** refuse to proxy a request because it contains a method or header field it does not know about. MN-31: If the request contains a Max-Forwards header field with a field value of zero (0), the element **MUST NOT** forward the request. MN-32: If a target URI is already present in the set (based on the definition of equality for the URI type), it **MUST NOT** be added again. MN-33: A proxy **MUST NOT** add additional targets to the target set if the Request-URI of the original request does not indicate a resource this proxy is responsible for. MN-34: As above, any given URI **MUST NOT** be added to the set more than once. MN-35: Fields not detailed in the processing described below **MUST NOT** be removed. MN-36: The proxy **MUST NOT** reorder field values with a common field name (See Section 7.3.1). MN-37: The proxy **MUST NOT** add to, modify, or remove the message body. MN-38: Endpoints **MUST NOT** use a URI obtained from a Record-Route header field outside the dialog in which it was provided. MN-39: If the request has a Route header field, this alternative **MUST NOT** be used unless it is known that next hop proxy is a loose router. MN-40: Such a policy **MUST NOT** be used if the proxy is not certain that the IP address, port, and transport correspond to a server that is a loose router. MN-41: The request method **MUST NOT** be included in the calculation of the branch parameter. MN-42: If no Via header field values remain in the response, the response was meant for this element and **MUST NOT** be forwarded. MN-43: If a 6xx response is received, it is not immediately forwarded, but the stateful proxy SHOULD cancel all client pending transactions as described in Section 10, and it **MUST NOT** create any new branches in this context. MN-44: A stateful proxy **MUST NOT** immediately forward any other responses. MN-45: In particular, a stateful proxy **MUST NOT** forward any 100 (Trying) response. MN-46: A proxy **MUST NOT** insert a tag into the To header field of a 1xx or 2xx response if the request did not contain one. MN-47: A proxy **MUST NOT** modify the tag in the To header field of a 1xx or 2xx response. MN-48: A proxy **MUST NOT** modify the To tag in any forwarded response to a request that contains a To tag. MN-49: The proxy **MUST NOT** add to, modify, or remove the message body. MN-50: Unless otherwise specified, the proxy **MUST NOT** remove any header field values other than the Via header field value discussed in Section 16.7 Item 3. MN-51: In particular, the proxy **MUST NOT** remove any "received" parameter. MN-52: Furthermore, when handling a request statelessly, an element **MUST NOT** generate its own 100 (Trying) or any other provisional response. MN-53: Stateless proxies **MUST NOT** perform special processing for CANCEL requests. MN-54: The proxy **MUST NOT** add to, modify, or remove the message body. MN-55: Unless specified otherwise, the proxy **MUST NOT** remove any other header field values. MN-56: The client transaction **MUST NOT** generate an ACK. MN-57: Any retransmissions of the final response that are received while in the "Completed" state MUST cause the ACK to be re-passed to the transport layer for retransmission, but the newly received response **MUST NOT** be passed up to the TU. MN-58: If the @ sign is present in a SIP or SIPS URI, the user field **MUST NOT** be empty. MN-59: Even though an arbitrary number of URI parameters may be included in a URI, any given parameter-name **MUST NOT** appear more than once. MN-60: URIs **MUST NOT** contain unescaped space and control characters. MN-61: Current implementations **MUST NOT** attempt to improve robustness by treating received escaped characters in the host component as literally equivalent to their unescaped counterpart. MN-62: The method parameter **MUST NOT** be placed in the Request-URI. MN-63: An implementation **MUST NOT** proceed with transmitting the request. MN-64: An implementation **MUST NOT** send a request requiring an extension that it does not support. MN-65: "Not applicable" means that the header field **MUST NOT** be present in a request. MN-66: Similarly, a header field labeled "not applicable" for a response means that the UAS **MUST NOT** place the header field in the response, and the UAC MUST ignore the header field in the response. MN-67: The absence of an Allow header field **MUST NOT** be interpreted to mean that the UA sending the message supports no methods. MN-68: Although not a comma- separated list, this header field name may be present multiple times, and **MUST NOT** be combined into a single header line using the usual rules described in Section 7.3. MN-69: Although not a comma-separated list, this header field name may be present multiple times, and **MUST NOT** be combined into a single header line using the usual rules described in Section 7.3.1. MN-70: Although an optional header field, the Require **MUST NOT** be ignored if it is present. MN-71: A system receiving this warning **MUST NOT** take any automated action. MN-72: If there is no explicit expiration time, the address is only valid once for recursing, and **MUST NOT** be cached for future transactions. MN-73: Servers **MUST NOT** accept credentials using the "Basic" authorization scheme, and servers also MUST NOT challenge with "Basic". MN-74: Servers MUST NOT accept credentials using the "Basic" authorization scheme, and servers also **MUST NOT** challenge with "Basic". MN-75: Additionally, registrars and redirect servers MAY make use of 401 (Unauthorized) responses for authentication, but proxies **MUST NOT**, and instead MAY use the 407 (Proxy Authentication Required). MN-76: Servers **MUST NOT** attempt to challenge an ACK. MN-77: Although the CANCEL method does take a response (a 2xx), servers **MUST NOT** attempt to challenge CANCEL requests since these requests cannot be resubmitted. MN-78: A UAC **MUST NOT** re-attempt requests with the credentials that have just been rejected (though the request may be retried if the nonce was stale). MN-79: Proxies **MUST NOT** add values to the Proxy-Authorization header field. MN-80: These credentials **MUST NOT** be cached across dialogs; however, if a UA is configured with the realm of its local outbound proxy, when one exists, then the UA MAY cache. MN-81: When multiple proxies are used in a chain, a Proxy- Authorization header field value **MUST NOT** be consumed by any proxy whose realm does not match the "realm" parameter specified in that value. MN-82: Note, however, that SIP servers **MUST NOT** accept or request Basic authentication. MN-83: RFC 2617 notes that a cnonce value **MUST NOT** be sent in an Authorization (and by extension Proxy-Authorization) header field if no qop directive has been sent. MN-84: If the From header field in an encrypted body differs from the value in the "outer" message, the value within the encrypted body SHOULD be displayed to the user, but **MUST NOT** be used in the "outer" header fields of any future messages. MN-85: If the certificate is invalid, revoked, or if it does not identify the appropriate party, the UA **MUST NOT** send the REGISTER message and otherwise proceed with the registration. SHALL NOT Requirements: ShaN-1: In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "**SHALL NOT**", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations. SHOULD NOT Requirements: SN-1: In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "**SHOULD NOT**", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations. SN-2: One largely non-method-specific guideline for the generation of responses is that UASs **SHOULD NOT** issue a provisional response for a non-INVITE request. SN-3: A CANCEL request **SHOULD NOT** be sent to cancel a request other than INVITE. SN-4: If the original request has generated a final response, the CANCEL **SHOULD NOT** be sent, as it is an effective no-op, since CANCEL has no effect on requests that have already generated a final response. SN-5: UACs **SHOULD NOT** use the "action" parameter. SN-6: A UA **SHOULD NOT** refresh bindings set up by other UAs. SN-7: If the transaction layer returns a timeout error because the REGISTER yielded no response, the UAC **SHOULD NOT** immediately re-attempt a registration to the same registrar. SN-8: The proxy **SHOULD NOT** initiate a CANCEL request. SN-9: Thus, a stateful proxy **SHOULD NOT** generate 100 (Trying) responses to non-INVITE requests. SN-10: The URI **SHOULD NOT** contain the transport parameter unless the proxy has knowledge (such as in a private network) that the next downstream element that will be in the path of subsequent requests supports that transport. SN-11: However, a proxy **SHOULD NOT** recurse to a non-SIPS URI if the Request-URI of the original request was a SIPS URI. SN-12: the proxy recurses on all of the contacts in a 3xx response, the proxy **SHOULD NOT** add the resulting contactless response to the response context. SN-13: As with a 3xx response, if a proxy "recurses" on the 416 by trying a SIP or SIPS URI instead, the 416 response **SHOULD NOT** be added to the response context. SN-14: A proxy which receives a 503 (Service Unavailable) response **SHOULD NOT** forward it upstream unless it can determine that any subsequent requests it might proxy will also generate a 503. SN-15: The URI **SHOULD NOT** contain the transport parameter unless the proxy has knowledge that the next upstream (as opposed to downstream) element that will be in the path of subsequent requests supports that transport. SN-16: The proxy **SHOULD NOT** cancel any outstanding client transactions associated with this response context due to this notification. SN-17: If a reliable transport is being used, the client transaction **SHOULD NOT** start timer A (Timer A controls request retransmissions). SN-18: In the "Proceeding" state, the client transaction **SHOULD NOT** retransmit the request any longer. SN-19: The 100 (Trying) response is constructed according to the procedures in Section 8.2.6, except that the insertion of tags in the To header field of the response (when none was present in the request) is downgraded from MAY to **SHOULD NOT**. SN-20: An implementation **SHOULD NOT** honor these obviously dangerous header fields: From, Call-ID, CSeq, Via, and Record-Route. SN-21: An implementation **SHOULD NOT** honor any requested Route header field values in order to not be used as an unwitting agent in malicious attacks. SN-22: An implementation **SHOULD NOT** honor requests to include header fields that may cause it to falsely advertise its location or capabilities. SN-23: Other HTTP/1.1 response codes **SHOULD NOT** be used. SN-24: The client **SHOULD NOT** retry the same request without modification (for example, adding appropriate authorization). SN-25: Authorization will not help, and the request **SHOULD NOT** be repeated. SN-26: A UAS **SHOULD NOT** use this response unless it truly cannot provide any useful service to the client. SN-27: It **SHOULD NOT** forward any other requests to that server for the duration specified in the Retry-After header field, if present. SN-28: However, if a user agent that supports S/MIME receives a request with an unsecured body, it **SHOULD NOT** respond with a secured body, but if it expects S/MIME from the sender (for example, because the sender's From header field value corresponds to an identity on its keychain), the UAS SHOULD notify its user that the session could not be secured. SN-29: Parallel signatures **SHOULD NOT** be used. SN-30: If these header fields are not intact end-to-end, implementations **SHOULD NOT** consider this a breach of security. SN-31: They **SHOULD NOT** however be used in the "outer" headers of any future messages. NOT RECOMMENDED Requirements: NRec-1: In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "**NOT RECOMMENDED**", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations. NRec-2: However, that approach for configuring an outbound proxy is **NOT RECOMMENDED**; a pre-existing route set with a single URI SHOULD be used instead. NRec-3: This behavior is **NOT RECOMMENDED**, as it will generally break interoperability. NRec-4: However, automated generation of re-INVITE or BYE is **NOT RECOMMENDED** to avoid flooding the network with traffic when there is congestion. NRec-5: However, this mechanism for sending the request through a specific next hop is **NOT RECOMMENDED**; instead a Route header field should be used for that purpose as described above. NRec-6: Elements MAY (though it is **NOT RECOMMENDED**) use smaller values of T1 within closed, private networks that do not permit general Internet connection. NRec-7: Therefore, placement of bodies in ACK for non-2xx is **NOT RECOMMENDED**, but if done, the body types are restricted to any that appeared in the INVITE, assuming that the response to the INVITE was not 415. NRec-8: While the SIP and SIPS URI syntax allows this field to be present, its use is **NOT RECOMMENDED**, because the passing of authentication information in clear text (such as URIs) has proven to be a security risk in almost every case where it has been used. MUST Requirements: MUST-1: In this document, the key words "**MUST**", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations. MUST-2: The start-line, each message-header line, and the empty line **MUST** be terminated by a carriage-return line-feed sequence (CRLF). MUST-3: Note that the empty line **MUST** be present even if the message-body is not. MUST-4: To be compliant with this specification, applications sending SIP messages **MUST** include a SIP-Version of "SIP/2.0". MUST-5: The SIP-Version string is case-insensitive, but implementations **MUST** send upper-case. MUST-6: It **MUST** be possible to combine the multiple header field rows into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. MUST-7: Implementations **MUST** be able to process multiple header field rows with the same name in any combination of the single-value-per-line or comma-separated value forms. MUST-8: If a header field appears in a message not matching its category (such as a request header field in a response), it **MUST** be ignored. MUST-9: Implementations **MUST** accept both the long and short forms of each header name. MUST-10: The Internet media type of the message body **MUST** be given by the Content-Type header field. MUST-11: If the body has undergone any encoding such as compression, then this **MUST** be indicated by the Content- Encoding header field; otherwise, Content-Encoding MUST be omitted. MUST-12: If the body has undergone any encoding such as compression, then this MUST be indicated by the Content- Encoding header field; otherwise, Content-Encoding **MUST** be omitted. MUST-13: Implementations that send requests containing multipart message bodies **MUST** send a session description as a non-multipart message body if the remote implementation requests this through an Accept header field that does not contain multipart. MUST-14: Implementations processing SIP messages over stream-oriented transports **MUST** ignore any CRLF appearing before the start-line [H4.1]. MUST-15: A valid SIP request formulated by a UAC **MUST**, at a minimum, contain the following header fields: To, From, CSeq, Call-ID, Max-Forwards, and Via; all of these header fields are mandatory in all SIP requests. MUST-16: When a pre-existing route set is present, the procedures for populating the Request-URI and Route header field detailed in Section 12.2.1.1 **MUST** be followed (even though there is no dialog), using the desired Request-URI as the remote target URI. MUST-17: All SIP implementations **MUST** support the SIP URI scheme. MUST-18: Any implementation that supports TLS **MUST** support the SIPS URI scheme. MUST-19: The From field **MUST** contain a new "tag" parameter, chosen by the UAC. MUST-20: It **MUST** be the same for all requests and responses sent by either UA in a dialog. MUST-21: In a new request created by a UAC outside of any dialog, the Call-ID header field **MUST** be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior. MUST-22: The method **MUST** match that of the request. MUST-23: The sequence number value **MUST** be expressible as a 32-bit unsigned integer and MUST be less than 2**31. MUST-24: The sequence number value MUST be expressible as a 32-bit unsigned integer and **MUST** be less than 2**31. MUST-25: A UAC **MUST** insert a Max-Forwards header field into each request it originates with a value that SHOULD be 70. MUST-26: When the UAC creates a request, it **MUST** insert a Via into that request. MUST-27: The protocol name and protocol version in the header field **MUST** be SIP and 2.0, respectively. MUST-28: The Via header field value **MUST** contain a branch parameter. MUST-29: The branch parameter value **MUST** be unique across space and time for all requests sent by the UA. MUST-30: The branch ID inserted by an element compliant with this specification **MUST** always begin with the characters "z9hG4bK". MUST-31: The Contact header field **MUST** be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. MUST-32: That is, the Contact header field value contains the URI at which the UA would like to receive requests, and this URI **MUST** be valid even if used in subsequent requests outside of any dialogs. MUST-33: If the Request-URI or top Route header field value contains a SIPS URI, the Contact header field **MUST** contain a SIPS URI as well. MUST-34: The option tags listed **MUST** only refer to extensions defined in standards-track RFCs. MUST-35: If the UAC wishes to insist that a UAS understand an extension that the UAC will apply to the request in order to process the request, it **MUST** insert a Require header field into the request listing the option tag for that extension. MUST-36: traversed understand that extension, it **MUST** insert a Proxy-Require header field into the request listing the option tag for that extension. MUST-37: As with the Supported header field, the option tags in the Require and Proxy-Require header fields **MUST** only refer to extensions defined in standards-track RFCs. MUST-38: Unless there is local policy specifying otherwise, the destination **MUST** be determined by applying the DNS procedures described in [4] as follows. MUST-39: If the first element in the route set indicated a strict router (resulting in forming the request as described in Section 12.2.1.1), the procedures **MUST** be applied to the Request-URI of the request. MUST-40: Independent of which URI is used as input to the procedures of [4], if the Request-URI specifies a SIPS resource, the UAC **MUST** follow the procedures of [4] as if the input URI were a SIPS URI. MUST-41: If the Request-URI contains a SIPS URI, any alternate destinations **MUST** be contacted with TLS. MUST-42: When a timeout error is received from the transaction layer, it **MUST** be treated as if a 408 (Request Timeout) status code has been received. MUST-43: If a fatal transport error is reported by the transport layer (generally, due to fatal ICMP errors in UDP or connection failures in TCP), the condition **MUST** be treated as a 503 (Service Unavailable) status code. MUST-44: A UAC **MUST** treat any final response it does not recognize as being equivalent to the x00 response code of that class, and MUST be able to process the x00 response code for all classes. MUST-45: A UAC MUST treat any final response it does not recognize as being equivalent to the x00 response code of that class, and **MUST** be able to process the x00 response code for all classes. MUST-46: A UAC **MUST** treat any provisional response different than 100 that it does not recognize as 183 (Session Progress). MUST-47: A UAC **MUST** be able to process 100 and 183 responses. MUST-48: In order to create a request based on a contact address in a 3xx response, a UAC **MUST** copy the entire URI from the target set into the Request-URI, except for the "method-param" and "header" URI parameters (see Section 19.1.1 for a definition of these parameters). MUST-49: Finally, once the new request has been constructed, it is sent using a new client transaction, and therefore **MUST** have a new branch ID in the top Via field as discussed in Section 8.1.1.7. MUST-50: If a request is accepted, all state changes associated with it **MUST** be performed. MUST-51: Once a request is authenticated (or authentication is skipped), the UAS **MUST** inspect the method of the request. MUST-52: If the UAS recognizes but does not support the method of a request, it **MUST** generate a 405 (Method Not Allowed) response. MUST-53: The UAS **MUST** also add an Allow header field to the 405 (Method Not Allowed) response. MUST-54: The Allow header field **MUST** list the set of methods supported by the UAS generating the message. MUST-55: If a UAS does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server **MUST** ignore that header field and continue processing the message. MUST-56: If the request has no tag in the To header field, the UAS core **MUST** check the request against ongoing transactions. MUST-57: If a UAS does not understand an option-tag listed in a Require header field, it **MUST** respond by generating a response with status code 420 (Bad Extension). MUST-58: The UAS **MUST** add an Unsupported header field, and list in it those options it does not understand amongst those in the Require header field of the request. MUST-59: These header fields **MUST** be ignored if they are present in these requests. MUST-60: An ACK request for a 2xx response **MUST** contain only those Require and Proxy-Require values that were present in the initial request. MUST-61: If there are any bodies whose type (indicated by the Content-Type), language (indicated by the Content-Language) or encoding (indicated by the Content-Encoding) are not understood, and that body part is not optional (as indicated by the Content- Disposition header field), the UAS **MUST** reject the request with a 415 (Unsupported Media Type) response. MUST-62: The response **MUST** contain an Accept header field listing the types of all bodies it understands, in the event the request contained bodies of types not supported by the UAS. MUST-63: If the request contained content encodings not understood by the UAS, the response **MUST** contain an Accept-Encoding header field listing the encodings understood by the UAS. MUST-64: If the request contained content with languages not understood by the UAS, the response **MUST** contain an Accept-Language header field indicating the languages understood by the UAS. MUST-65: The needed extension(s) **MUST** be included in a Require header field in the response. MUST-66: Any extensions applied to a non-421 response **MUST** be listed in a Require header field included in the response. MUST-67: When a 100 (Trying) response is generated, any Timestamp header field present in the request **MUST** be copied into this 100 (Trying) response. MUST-68: This value **MUST** contain the difference between the time of sending of the response and receipt of the request, measured in seconds. MUST-69: The From field of the response **MUST** equal the From header field of the request. MUST-70: The Call-ID header field of the response **MUST** equal the Call-ID header field of the request. MUST-71: The CSeq header field of the response **MUST** equal the CSeq field of the request. MUST-72: The Via header field values in the response **MUST** equal the Via header field values in the request and MUST maintain the same ordering. MUST-73: The Via header field values in the response MUST equal the Via header field values in the request and **MUST** maintain the same ordering. MUST-74: If a request contained a To tag in the request, the To header field in the response **MUST** equal that of the request. MUST-75: However, if the To header field in the request did not contain a tag, the URI in the To header field in the response **MUST** equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response (with the exception of the 100 (Trying) response, in which a tag MAY be present). MUST-76: However, if the To header field in the request did not contain a tag, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS **MUST** add a tag to the To header field in the response (with the exception of the 100 (Trying) response, in which a tag MAY be present). MUST-77: The same tag **MUST** be used for all responses to that request, both final and provisional (again excepting the 100 (Trying)). MUST-78: o A stateless UAS **MUST** ignore ACK requests. MUST-79: o A stateless UAS **MUST** ignore CANCEL requests. MUST-80: o To header tags **MUST** be generated for responses in a stateless manner - in a manner that will generate the same tag for the same request consistently. MUST-81: Redirect servers **MUST** ignore features that are not understood (including unrecognized header fields, any unknown option tags in Require, or even method names) and proceed with the redirection of the request in question. MUST-82: The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request **MUST** be identical to those in the request being cancelled, including tags. MUST-83: A CANCEL constructed by a client **MUST** have only a single Via header field value matching the top Via value in the request being cancelled. MUST-84: However, the method part of the CSeq header field **MUST** have a value of CANCEL. MUST-85: If the request being cancelled contains a Route header field, the CANCEL request **MUST** include that Route header field's values. MUST-86: If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client **MUST** wait for the arrival of a provisional response before sending the request. MUST-87: The destination address, port, and transport for the CANCEL **MUST** be identical to those used to send the original request. MUST-88: The only requirement is that a registrar for some domain **MUST** be able to read and write data to the location service, and a proxy or a redirect server for that domain MUST be capable of reading that same data. MUST-89: The only requirement is that a registrar for some domain MUST be able to read and write data to the location service, and a proxy or a redirect server for that domain **MUST** be capable of reading that same data. MUST-90: The Record-Route header field has no meaning in REGISTER requests or responses, and **MUST** be ignored if present. MUST-91: The following header fields, except Contact, **MUST** be included in a REGISTER request. MUST-92: This address-of-record **MUST** be a SIP URI or SIPS URI. MUST-93: A UA **MUST** increment the CSeq value by one for each REGISTER request with the same Call-ID. MUST-94: A registrar **MUST** not generate 6xx responses. MUST-95: Registrars **MUST** ignore the Record-Route header field if it is included in a REGISTER request. MUST-96: REGISTER requests **MUST** be processed by a registrar in the order that they are received. MUST-97: REGISTER requests **MUST** also be processed atomically, meaning that a particular REGISTER request is either processed completely or not at all. MUST-98: Each REGISTER message **MUST** be processed independently of any other registration or binding changes. MUST-99: To guarantee that the registrar supports any necessary extensions, the registrar **MUST** process the Require header field values as described for UASs in Section 8.2.2. MUST-100: If the authenticated user is not authorized to modify bindings, the registrar **MUST** return a 403 (Forbidden) and skip the remaining steps. MUST-101: If the address-of-record is not valid for the domain in the Request-URI, the registrar **MUST** send a 404 (Not Found) response and skip the remaining steps. MUST-102: The URI **MUST** then be converted to a canonical form. MUST-103: To do that, all URI parameters **MUST** be removed (including the user-param), and any escaped characters MUST be converted to their unescaped form. MUST-104: To do that, all URI parameters MUST be removed (including the user-param), and any escaped characters **MUST** be converted to their unescaped form. MUST-105: If the request has additional Contact fields or an expiration time other than zero, the request is invalid, and the server **MUST** return a 400 (Invalid Request) and skip the remaining steps. MUST-106: If not, it **MUST** remove the binding. MUST-107: If it does agree, it **MUST** remove the binding only if the CSeq in the request is higher than the value stored for that binding. MUST-108: Otherwise, the update **MUST** be aborted and the request fails. MUST-109: - If the field value has an "expires" parameter, that value **MUST** be taken as the requested expiration. MUST-110: - If there is no such parameter, but the request has an Expires header field, that value **MUST** be taken as the requested expiration. MUST-111: - If there is neither, a locally-configured default value **MUST** be taken as the requested expiration. MUST-112: This response **MUST** contain a Min-Expires header field that states the minimum expiration interval the registrar is willing to honor. MUST-113: If the Call-ID value in the existing binding differs from the Call-ID value in the request, the binding **MUST** be removed if the expiration time is zero and updated otherwise. MUST-114: If the value is higher than that of the existing binding, it **MUST** update or remove the binding as above. MUST-115: If not, the update **MUST** be aborted and the request fails. MUST-116: The binding updates **MUST** be committed (that is, made visible to the proxy or redirect server) if and only if all binding updates and additions succeed. MUST-117: If any one of them fails (for example, because the back-end database commit failed), the request **MUST** fail with a 500 (Server Error) response and all tentative binding updates MUST be removed. MUST-118: If any one of them fails (for example, because the back-end database commit failed), the request MUST fail with a 500 (Server Error) response and all tentative binding updates **MUST** be removed. MUST-119: The response **MUST** contain Contact header field values enumerating all current bindings. MUST-120: Each Contact value **MUST** feature an "expires" parameter indicating its expiration interval chosen by the registrar. MUST-121: All UAs **MUST** support the OPTIONS method. MUST-122: The response code chosen **MUST** be the same that would have been chosen had the request been an INVITE. MUST-123: UAs **MUST** assign values to the dialog ID components as described below. MUST-124: When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS **MUST** copy all Record-Route header field values from the request into the response (including the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or unknown to the UAS) and MUST maintain the order of those values. MUST-125: When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response (including the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or unknown to the UAS) and **MUST** maintain the order of those values. MUST-126: The UAS **MUST** add a Contact header field to the response. MUST-127: The URI provided in the Contact header field **MUST** be a SIP or SIPS URI. MUST-128: SIPS URI in the Request-URI or in the top Record-Route header field value, if there was any, or the Contact header field if there was no Record-Route header field, the Contact header field in the response **MUST** be a SIPS URI. MUST-129: This state **MUST** be maintained for the duration of the dialog. MUST-130: The route set **MUST** be set to the list of URIs in the Record-Route header field from the request, taken in order and preserving all URI parameters. MUST-131: If no Record-Route header field is present in the request, the route set **MUST** be set to the empty set. MUST-132: The remote target **MUST** be set to the URI from the Contact header field of the request. MUST-133: The remote sequence number **MUST** be set to the value of the sequence number in the CSeq header field of the request. MUST-134: The local sequence number **MUST** be empty. MUST-135: The call identifier component of the dialog ID **MUST** be set to the value of the Call-ID in the request. MUST-136: The local tag component of the dialog ID **MUST** be set to the tag in the To field in the response to the request (which always includes a tag), and the remote tag component of the dialog ID MUST be set to the tag from the From field in the request. MUST-137: The local tag component of the dialog ID MUST be set to the tag in the To field in the response to the request (which always includes a tag), and the remote tag component of the dialog ID **MUST** be set to the tag from the From field in the request. MUST-138: A UAS **MUST** be prepared to receive a request without a tag in the From field, in which case the tag is considered to have a value of null. MUST-139: The remote URI **MUST** be set to the URI in the From field, and the local URI MUST be set to the URI in the To field. MUST-140: The remote URI MUST be set to the URI in the From field, and the local URI **MUST** be set to the URI in the To field. MUST-141: When a UAC sends a request that can establish a dialog (such as an INVITE) it **MUST** provide a SIP or SIPS URI with global scope (i.e., the same SIP URI can be used in messages outside this dialog) in the Contact header field of the request. MUST-142: If the request has a Request- URI or a topmost Route header field value with a SIPS URI, the Contact header field **MUST** contain a SIPS URI. MUST-143: This state **MUST** be maintained for the duration of the dialog. MUST-144: The route set **MUST** be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. MUST-145: If no Record-Route header field is present in the response, the route set **MUST** be set to the empty set. MUST-146: The remote target **MUST** be set to the URI from the Contact header field of the response. MUST-147: The local sequence number **MUST** be set to the value of the sequence number in the CSeq header field of the request. MUST-148: The remote sequence number **MUST** be empty (it is established when the remote UA sends a request within the dialog). MUST-149: The call identifier component of the dialog ID **MUST** be set to the value of the Call-ID in the request. MUST-150: The local tag component of the dialog ID **MUST** be set to the tag in the From field in the request, and the remote tag component of the dialog ID MUST be set to the tag in the To field of the response. MUST-151: The local tag component of the dialog ID MUST be set to the tag in the From field in the request, and the remote tag component of the dialog ID **MUST** be set to the tag in the To field of the response. MUST-152: A UAC **MUST** be prepared to receive a response without a tag in the To field, in which case the tag is considered to have a value of null. MUST-153: The remote URI **MUST** be set to the URI in the To field, and the local URI MUST be set to the URI in the From field. MUST-154: The remote URI MUST be set to the URI in the To field, and the local URI **MUST** be set to the URI in the From field. MUST-155: The URI in the To field of the request **MUST** be set to the remote URI from the dialog state. MUST-156: The tag in the To header field of the request **MUST** be set to the remote tag of the dialog ID. MUST-157: The From URI of the request **MUST** be set to the local URI from the dialog state. MUST-158: The tag in the From header field of the request **MUST** be set to the local tag of the dialog ID. MUST-159: If the value of the remote or local tags is null, the tag parameter **MUST** be omitted from the To or From header fields, respectively. MUST-160: The Call-ID of the request **MUST** be set to the Call-ID of the dialog. MUST-161: Requests within a dialog **MUST** contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in each direction (excepting ACK and CANCEL of course, whose numbers equal the requests being acknowledged or cancelled). MUST-162: Therefore, if the local sequence number is not empty, the value of the local sequence number **MUST** be incremented by one, and this value MUST be placed into the CSeq header field. MUST-163: Therefore, if the local sequence number is not empty, the value of the local sequence number MUST be incremented by one, and this value **MUST** be placed into the CSeq header field. MUST-164: If the local sequence number is empty, an initial value **MUST** be chosen using the guidelines of Section 8.1.1.5. MUST-165: The method field in the CSeq header field value **MUST** match the method of the request. MUST-166: If the route set is empty, the UAC **MUST** place the remote target URI into the Request-URI. MUST-167: If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC **MUST** place the remote target URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters. MUST-168: If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI and **MUST** include a Route header field containing the route set values in order, including all parameters. MUST-169: If the route set is not empty, and its first URI does not contain the lr parameter, the UAC **MUST** place the first URI from the route set into the Request-URI, stripping any parameters that are not allowed in a Request-URI. MUST-170: The UAC **MUST** add a Route header field containing the remainder of the route set values in order, including all parameters. MUST-171: The UAC **MUST** then place the remote target URI into the Route header field as the last value. MUST-172: If the "secure" flag is true, that URI **MUST** be a SIPS URI. MUST-173: When a UAC receives a 2xx response to a target refresh request, it **MUST** replace the dialog's remote target URI with the URI from the Contact header field in that response, if present. MUST-174: If the UAS wishes to reject the request because it does not wish to recreate the dialog, it **MUST** respond to the request with a 481 (Call/Transaction Does Not Exist) status code and pass that to the server transaction. MUST-175: If the remote sequence number is empty, it **MUST** be set to the value of the sequence number in the CSeq header field value in the request. MUST-176: If the remote sequence number was not empty, but the sequence number of the request is lower than the remote sequence number, the request is out of order and **MUST** be rejected with a 500 (Server Internal Error) response. MUST-177: The UAS **MUST** then set the remote sequence number to the value of the sequence number in the CSeq header field value in the request. MUST-178: When a UAS receives a target refresh request, it **MUST** replace the dialog's remote target URI with the URI from the Contact header field in that request, if present. MUST-179: A UA that supports INVITE **MUST** also support ACK, CANCEL and BYE. MUST-180: o The initial offer **MUST** be in either an INVITE or, if not there, in the first reliable non-failure message from the UAS back to the UAC. MUST-181: o If the initial offer is in an INVITE, the answer **MUST** be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. MUST-182: The UAC **MUST** treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE. MUST-183: The UAC MUST treat the first session description it receives as the answer, and **MUST** ignore any session descriptions in subsequent responses to the initial INVITE. MUST-184: o If the initial offer is in the first reliable non-failure message from the UAS back to UAC, the answer **MUST** be in the acknowledgement for that message (in this specification, ACK for a 2xx response). MUST-185: All user agents that support INVITE **MUST** support these two exchanges. MUST-186: The Session Description Protocol (SDP) (RFC 2327 [1]) **MUST** be supported by all user agents as a means to describe sessions, and its usage for constructing offers and answers MUST follow the procedures defined in [13]. MUST-187: The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be supported by all user agents as a means to describe sessions, and its usage for constructing offers and answers **MUST** follow the procedures defined in [13]. MUST-188: Subsequent final responses (which would only arrive under error conditions) **MUST** be ignored. MUST-189: If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog **MUST** be transitioned to the "confirmed" state, and the route set for the dialog MUST be recomputed based on the 2xx response using the procedures of Section 12.2.1.2. MUST-190: If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog MUST be transitioned to the "confirmed" state, and the route set for the dialog **MUST** be recomputed based on the 2xx response using the procedures of Section 12.2.1.2. MUST-191: Otherwise, a new dialog in the "confirmed" state **MUST** be constructed using the procedures of Section 12.1.2. MUST-192: The UAC core **MUST** generate an ACK request for each 2xx received from the transaction layer. MUST-193: The sequence number of the CSeq header field **MUST** be the same as the INVITE being acknowledged, but the CSeq method MUST be ACK. MUST-194: The sequence number of the CSeq header field MUST be the same as the INVITE being acknowledged, but the CSeq method **MUST** be ACK. MUST-195: The ACK **MUST** contain the same credentials as the INVITE. MUST-196: If the 2xx contains an offer (based on the rules above), the ACK **MUST** carry an answer in its body. MUST-197: If the offer in the 2xx response is not acceptable, the UAC core **MUST** generate a valid answer in the ACK and then send a BYE immediately. MUST-198: The ACK **MUST** be passed to the client transport every time a retransmission of the 2xx final response that triggered the ACK arrives. MUST-199: If, after acknowledging any 2xx response to an INVITE, the UAC does not want to continue with that dialog, then the UAC **MUST** terminate the dialog by sending a BYE request as described in Section 15. MUST-200: It **MUST** provide the offer in its first non-failure reliable message back to the UAC. MUST-201: Each of these **MUST** indicate the same dialog ID. MUST-202: To prevent cancellation, the UAS **MUST** send a non-100 provisional response at every minute, to handle the possibility of lost provisional responses. MUST-203: If the INVITE request contained an offer, and the UAS had not yet sent an answer, the 2xx **MUST** contain an answer. MUST-204: If the INVITE did not contain an offer, the 2xx **MUST** contain an offer if the UAS had not yet sent an offer. MUST-205: If there is an ongoing INVITE client transaction, the TU **MUST** wait until the transaction reaches the completed or terminated state before initiating the new INVITE. MUST-206: If there is an ongoing INVITE server transaction, the TU **MUST** wait until the transaction reaches the confirmed or terminated state before initiating the new INVITE. MUST-207: If a UA receives a non-2xx final response to a re-INVITE, the session parameters **MUST** remain unchanged, as if no re-INVITE had been issued. MUST-208: A UAS that receives a second INVITE before it sends the final response to a first INVITE with a lower CSeq sequence number on the same dialog **MUST** return a 500 (Server Internal Error) response to the second INVITE and MUST include a Retry-After header field with a randomly chosen value of between 0 and 10 seconds. MUST-209: A UAS that receives a second INVITE before it sends the final response to a first INVITE with a lower CSeq sequence number on the same dialog MUST return a 500 (Server Internal Error) response to the second INVITE and **MUST** include a Retry-After header field with a randomly chosen value of between 0 and 10 seconds. MUST-210: A UAS that receives an INVITE on a dialog while an INVITE it had sent on that dialog is in progress **MUST** return a 491 (Request Pending) response to the received INVITE. MUST-211: If a UA receives a re-INVITE for an existing dialog, it **MUST** check any version identifiers in the session description or, if there are no version identifiers, the content of the session description to see if it has changed. MUST-212: If the session description has changed, the UAS **MUST** adjust the session parameters accordingly, possibly after asking the user for confirmation. MUST-213: The UAS **MUST** ensure that the session description overlaps with its previous session description in media formats, transports, or other parameters that require support from the peer. MUST-214: The UAC **MUST** consider the session terminated (and therefore stop sending or listening for media) as soon as the BYE request is passed to the client transaction. MUST-215: response at all is received for the BYE (that is, a timeout is returned by the client transaction), the UAC **MUST** consider the session and the dialog terminated. MUST-216: A UAS core receiving a BYE request for an existing dialog **MUST** follow the procedures of Section 12.2.2 to process the request. MUST-217: Whether or not it ends its participation on the session, the UAS core **MUST** generate a 2xx response to the BYE, and MUST pass that to the server transaction for transmission. MUST-218: Whether or not it ends its participation on the session, the UAS core MUST generate a 2xx response to the BYE, and **MUST** pass that to the server transaction for transmission. MUST-219: The UAS **MUST** still respond to any pending requests received for that dialog. MUST-220: When responding directly to a request, the element is playing the role of a UAS and **MUST** behave as described in Section 8.2. MUST-221: Any request that is forwarded to more than one location **MUST** be handled statefully. MUST-222: Requests forwarded between different types of transports where the proxy's TU must take an active role in ensuring reliable delivery on one of the transports **MUST** be forwarded transaction statefully. MUST-223: The proxy core **MUST** behave as a UAS with respect to sending an immediate provisional on that server transaction (such as 100 Trying) as described in Section 8.2.6. MUST-224: For all new requests, including any with unknown methods, an element intending to proxy the request **MUST**:. MUST-225: Before an element can proxy a request, it **MUST** verify the message's validity. MUST-226: If any of these checks fail, the element **MUST** behave as a user agent server (see Section 8.2) and respond with an error code. MUST-227: The request **MUST** be well-formed enough to be handled with a server transaction. MUST-228: Any components involved in the remainder of these Request Validation steps or the Request Forwarding section **MUST** be well-formed. MUST-229: Otherwise, the element **MUST** return a 483 (Too many hops) response. MUST-230: If the request contains a Proxy-Require header field (Section 20.29) with one or more option-tags this element does not understand, the element **MUST** return a 420 (Bad Extension) response. MUST-231: The response **MUST** include an Unsupported (Section 20.40) header field listing those option-tags the element did not understand. MUST-232: If an element requires credentials before forwarding a request, the request **MUST** be inspected as described in Section 22.3. MUST-233: The proxy **MUST** inspect the Request-URI of the request. MUST-234: If the Request-URI of the request contains a value this proxy previously placed into a Record-Route header field (see Section 16.6 item 4), the proxy **MUST** replace the Request-URI in the request with the last value from the Route header field, and remove that value from the Route header field. MUST-235: The proxy **MUST** then proceed as if it received this modified request. MUST-236: If the Request-URI contains a maddr parameter, the proxy **MUST** check to see if its value is in the set of addresses or domains the proxy is configured to be responsible for. MUST-237: If the Request-URI has a maddr parameter with a value the proxy is responsible for, and the request was received using the port and transport indicated (explicitly or by default) in the Request-URI, the proxy **MUST** strip the maddr and any non-default port or transport parameter and continue processing as if those values had not been present in the request. MUST-238: If the first value in the Route header field indicates this proxy, the proxy **MUST** remove that value from the request. MUST-239: If the Request-URI of the request contains an maddr parameter, the Request-URI **MUST** be placed into the target set as the only target URI, and the proxy MUST proceed to Section 16.6. MUST-240: If the Request-URI of the request contains an maddr parameter, the Request-URI MUST be placed into the target set as the only target URI, and the proxy **MUST** proceed to Section 16.6. MUST-241: If the domain of the Request-URI indicates a domain this element is not responsible for, the Request-URI **MUST** be placed into the target set as the only target, and the element MUST proceed to the task of Request Forwarding (Section 16.6). MUST-242: If the domain of the Request-URI indicates a domain this element is not responsible for, the Request-URI MUST be placed into the target set as the only target, and the element **MUST** proceed to the task of Request Forwarding (Section 16.6). MUST-243: When accessing the location service constructed by a registrar, the Request-URI **MUST** first be canonicalized as described in Section 10.3 before being used as an index. MUST-244: If the Request-URI indicates a resource at this proxy that does not exist, the proxy **MUST** return a 404 (Not Found) response. MUST-245: If the target set remains empty after applying all of the above, the proxy **MUST** return an error response, which SHOULD be the 480 (Temporarily Unavailable) response. MUST-246: The copy **MUST** initially contain all of the header fields from the received request. MUST-247: The Request-URI in the copy's start line **MUST** be replaced with the URI for this target. MUST-248: If the URI contains any parameters not allowed in a Request-URI, they **MUST** be removed. MUST-249: If the copy contains a Max-Forwards header field, the proxy **MUST** decrement its value by one (1). MUST-250: If the copy does not contain a Max-Forwards header field, the proxy **MUST** add one with a field value, which SHOULD be 70. MUST-251: If this proxy wishes to remain on the path of future requests in a dialog created by this request (assuming the request creates a dialog), it **MUST** insert a Record-Route header field value into the copy before any existing Record-Route header field values, even if a Route header field is already present. MUST-252: The URI placed in the Record-Route header field value **MUST** be a SIP or SIPS URI. MUST-253: This URI **MUST** contain an lr parameter (see Section 19.1.1). MUST-254: The URI placed in the Record-Route header field **MUST** resolve to the element inserting it (or a suitable stand-in) when the server location procedures of [4] are applied to it, so that subsequent requests reach the same SIP element. MUST-255: If the Request-URI contains a SIPS URI, or the topmost Route header field value (after the post processing of bullet 6) contains a SIPS URI, the URI placed into the Record-Route header field **MUST** be a SIPS URI. MUST-256: Furthermore, if the request was not received over TLS, the proxy **MUST** insert a Record-Route header field. MUST-257: In a similar fashion, a proxy that receives a request over TLS, but generates a request without a SIPS URI in the Request-URI or topmost Route header field value (after the post processing of bullet 6), **MUST** insert a Record-Route header field that is not a SIPS URI. MUST-258: If the URI placed in the Record-Route header field needs to be rewritten when it passes back through in a response, the URI **MUST** be distinct enough to locate at that time. MUST-259: A proxy **MUST** ensure that all such proxies are loose routers. MUST-260: This set **MUST** be pushed into the Route header field of the copy ahead of any existing values, if present. MUST-261: If the Route header field is absent, it **MUST** be added, containing that list of URIs. MUST-262: Furthermore, if the Request-URI contains a SIPS URI, TLS **MUST** be used to communicate with that proxy. MUST-263: If the copy contains a Route header field, the proxy **MUST** inspect the URI in its first value. MUST-264: If that URI does not contain an lr parameter, the proxy **MUST** modify the copy as follows:. MUST-265: - The proxy **MUST** place the Request-URI into the Route header field as the last value. MUST-266: - The proxy **MUST** then place the first Route header field value into the Request-URI and remove that value from the Route header field. MUST-267: If the proxy has reformatted the request to send to a strict-routing element as described in step 6 above, the proxy **MUST** apply those procedures to the Request-URI of the request. MUST-268: Otherwise, the proxy **MUST** apply the procedures to the first value in the Route header field, if present, else the Request-URI. MUST-269: Independently of which URI is being used as input to the procedures of [4], if the Request-URI specifies a SIPS resource, the proxy **MUST** follow the procedures of [4] as if the input URI were a SIPS URI. MUST-270: As described in [4], the proxy **MUST** attempt to deliver the message to the first tuple in that set, and proceed through the set in order until the delivery attempt succeeds. MUST-271: For each tuple attempted, the proxy **MUST** format the message as appropriate for the tuple and send the request using a new client transaction as detailed in steps 8 through 10. MUST-272: Thus, the branch parameter provided with the Via header field inserted in step 8 **MUST** be different for each attempt. MUST-273: The proxy **MUST** insert a Via header field value into the copy before the existing Via header field values. MUST-274: The first part **MUST** satisfy the constraints of Section 8.1.1.7 as described above. MUST-275: If a proxy wishes to detect loops, the "branch" parameter it supplies **MUST** depend on all information affecting processing of a request, including the incoming Request-URI and any header fields affecting the request's admission or routing. MUST-276: In particular, CANCEL and ACK requests (for non-2xx responses) **MUST** have the same branch value as the corresponding request they cancel or acknowledge. MUST-277: If the request will be sent to the next hop using a stream- based transport and the copy contains no Content-Length header field, the proxy **MUST** insert one with the correct value for the body of the request (see Section 20.14). MUST-278: A stateful proxy **MUST** create a new client transaction for this request as described in Section 17.1 and instructs the transaction to send the request using the address, port and transport determined in step 7. MUST-279: Timer C **MUST** be set for each client transaction when an INVITE request is proxied. MUST-280: The timer **MUST** be larger than 3 minutes. MUST-281: If none is found, the element **MUST** process the response (even if it is an informational response) as a stateless proxy (described below). MUST-282: As client transactions pass responses to the proxy layer, the following processing **MUST** take place:. MUST-283: The following processing **MUST** be performed on each response that is forwarded. MUST-284: For an INVITE transaction, if the response is a provisional response with status codes 101 to 199 inclusive (i.e., anything but 100), the proxy **MUST** reset timer C for that client transaction. MUST-285: The timer MAY be reset to a different value, but this value **MUST** be greater than 3 minutes. MUST-286: If the proxy chooses to recurse on any contacts in a 3xx response by adding them to the target set, it **MUST** remove them from the response before adding the response to the response context. MUST-287: Until a final response has been sent on the server transaction, the following responses **MUST** be forwarded immediately:. MUST-288: After a final response has been sent on the server transaction, the following responses **MUST** be forwarded immediately:. MUST-289: Any response chosen for immediate forwarding **MUST** be processed as described in steps "Aggregate Authorization Header Field Values" through "Record-Route". MUST-290: A stateful proxy **MUST** send a final response to a response context's server transaction if no final responses have been immediately forwarded by the above rules and all client transactions in this response context have been terminated. MUST-291: The stateful proxy **MUST** choose the "best" final response among those received and stored in the response context. MUST-292: If there are no final responses in the context, the proxy **MUST** send a 408 (Request Timeout) response to the server transaction. MUST-293: Otherwise, the proxy **MUST** forward a response from the responses stored in the response context. MUST-294: It **MUST** choose from the 6xx class responses if any exist in the context. MUST-295: The forwarded response **MUST** be processed as described in steps "Aggregate Authorization Header Field Values" through "Record- Route". MUST-296: If the selected response is a 401 (Unauthorized) or 407 (Proxy Authentication Required), the proxy **MUST** collect any WWW- Authenticate and Proxy-Authenticate header field values from all other 401 (Unauthorized) and 407 (Proxy Authentication Required) responses received so far in this response context and add them to this response without modification before forwarding. MUST-297: If the proxy received the request over TLS, and sent it out over a non-TLS connection, the proxy **MUST** rewrite the URI in the Record-Route header field to be a SIPS URI. MUST-298: If the proxy received the request over a non-TLS connection, and sent it out over TLS, the proxy **MUST** rewrite the URI in the Record-Route header field to be a SIP URI. MUST-299: The new URI provided by the proxy **MUST** satisfy the same constraints on URIs placed in Record-Route header fields in requests (see Step 4 of Section 16.6) with the following modifications:. MUST-300: The proxy **MUST** pass the response to the server transaction associated with the response context. MUST-301: If the server transaction is no longer available to handle the transmission, the element **MUST** forward the response statelessly by sending it to the server transport. MUST-302: The proxy **MUST** maintain the response context until all of its associated transactions have been terminated, even after forwarding a final response. MUST-303: If the forwarded response was a final response, the proxy **MUST** generate a CANCEL request for all pending client transactions associated with this response context. MUST-304: If timer C should fire, the proxy **MUST** either reset the timer with any value it chooses, or terminate the client transaction. MUST-305: If the client transaction has received a provisional response, the proxy **MUST** generate a CANCEL request matching that transaction. MUST-306: If the client transaction has not received a provisional response, the proxy **MUST** behave as if the transaction received a 408 (Request Timeout) response. MUST-307: If the transport layer notifies a proxy of an error when it tries to forward a request (see Section 18.4), the proxy **MUST** behave as if the forwarded request received a 503 (Service Unavailable) response. MUST-308: A proxy **MUST** cancel any pending client transactions associated with a response context when it receives a matching CANCEL request. MUST-309: If a matching response context is found, the element **MUST** immediately return a 200 (OK) response to the CANCEL request. MUST-310: Furthermore, the element **MUST** generate CANCEL requests for all pending client transactions in the context as described in Section 16.7 step 10. MUST-311: It **MUST** statelessly forward the CANCEL request (it may have statelessly forwarded the associated request previously). MUST-312: A stateless proxy **MUST** validate a request as described in Section 16.3. MUST-313: A stateless proxy **MUST** follow the request processing steps described in Sections 16.4 through 16.5 with the following exception:. MUST-314: o A stateless proxy **MUST** choose one and only one target from the target set. MUST-315: This choice **MUST** only rely on fields in the message and time-invariant properties of the server. MUST-316: In particular, a retransmitted request **MUST** be forwarded to the same destination each time it is processed. MUST-317: Furthermore, CANCEL and non-Routed ACK requests **MUST** generate the same choice as their associated INVITE. MUST-318: A stateless proxy **MUST** follow the request processing steps described in Section 16.6 with the following exceptions:. MUST-319: Therefore, the component of the branch parameter that makes it unique **MUST** be the same each time a retransmitted request is forwarded. MUST-320: Thus for a stateless proxy, the branch parameter **MUST** be computed as a combinatoric function of message parameters which are invariant on retransmission. MUST-321: o All other message transformations specified in Section 16.6 **MUST** result in the same transformation of a retransmitted request. MUST-322: In particular, if the proxy inserts a Record-Route value or pushes URIs into the Route header field, it **MUST** place the same values in retransmissions of the request. MUST-323: As for the Via branch parameter, this implies that the transformations **MUST** be based on time-invariant configuration or retransmission-invariant properties of the request. MUST-324: When a response arrives at a stateless proxy, the proxy **MUST** inspect the sent-by value in the first (topmost) Via header field value. MUST-325: If that address matches the proxy, (it equals a value this proxy has inserted into previous requests) the proxy **MUST** remove that header field value from the response and forward the result to the location indicated in the next Via header field value. MUST-326: If the address does not match the proxy, the message **MUST** be silently discarded. MUST-327: The initial state, "calling", **MUST** be entered when the TU initiates a new client transaction with an INVITE request. MUST-328: The client transaction **MUST** pass the request to the transport layer for transmission (see Section 18). MUST-329: If an unreliable transport is being used, the client transaction **MUST** start timer A with a value of T1. MUST-330: For any transport, the client transaction **MUST** start timer B with a value of 64*T1 seconds (Timer B controls transaction timeouts). MUST-331: When timer A fires, the client transaction **MUST** retransmit the request by passing it to the transport layer, and MUST reset the timer with a value of 2*T1. MUST-332: When timer A fires, the client transaction MUST retransmit the request by passing it to the transport layer, and **MUST** reset the timer with a value of 2*T1. MUST-333: When timer A fires 2*T1 seconds later, the request **MUST** be retransmitted again (assuming the client transaction is still in this state). MUST-334: This process **MUST** continue so that the request is retransmitted with intervals that double after each transmission. MUST-335: Whatever the value of T1, the exponential backoffs on retransmissions described in this section **MUST** be used. MUST-336: Furthermore, the provisional response **MUST** be passed to the TU. MUST-337: Any further provisional responses **MUST** be passed up to the TU while in the "Proceeding" state. MUST-338: When in either the "Calling" or "Proceeding" states, reception of a response with status code from 300-699 **MUST** cause the client transaction to transition to "Completed". MUST-339: The client transaction **MUST** pass the received response up to the TU, and the client transaction MUST generate an ACK request, even if the transport is reliable (guidelines for constructing the ACK from the response are given in Section 17.1.1.3) and then pass the ACK to the transport layer for transmission. MUST-340: The client transaction MUST pass the received response up to the TU, and the client transaction **MUST** generate an ACK request, even if the transport is reliable (guidelines for constructing the ACK from the response are given in Section 17.1.1.3) and then pass the ACK to the transport layer for transmission. MUST-341: The ACK **MUST** be sent to the same address, port, and transport to which the original request was sent. MUST-342: Any retransmissions of the final response that are received while in the "Completed" state **MUST** cause the ACK to be re-passed to the transport layer for retransmission, but the newly received response MUST NOT be passed up to the TU. MUST-343: If timer D fires while the client transaction is in the "Completed" state, the client transaction **MUST** move to the terminated state. MUST-344: When in either the "Calling" or "Proceeding" states, reception of a 2xx response **MUST** cause the client transaction to enter the "Terminated" state, and the response MUST be passed up to the TU. MUST-345: When in either the "Calling" or "Proceeding" states, reception of a 2xx response MUST cause the client transaction to enter the "Terminated" state, and the response **MUST** be passed up to the TU. MUST-346: The client transaction **MUST** be destroyed the instant it enters the "Terminated" state. MUST-347: A UAC core that generates an ACK for 2xx **MUST** instead follow the rules described in Section 13. MUST-348: The ACK request constructed by the client transaction **MUST** contain values for the Call-ID, From, and Request-URI that are equal to the values of those header fields in the request passed to the transport by the client transaction (call this the "original request"). MUST-349: The To header field in the ACK **MUST** equal the To header field in the response being acknowledged, and therefore will usually differ from the To header field in the original request by the addition of the tag parameter. MUST-350: The ACK **MUST** contain a single Via header field, and this MUST be equal to the top Via header field of the original request. MUST-351: The ACK MUST contain a single Via header field, and this **MUST** be equal to the top Via header field of the original request. MUST-352: The CSeq header field in the ACK **MUST** contain the same value for the sequence number as was present in the original request, but the method parameter MUST be equal to "ACK". MUST-353: The CSeq header field in the ACK MUST contain the same value for the sequence number as was present in the original request, but the method parameter **MUST** be equal to "ACK". MUST-354: If the INVITE request whose response is being acknowledged had Route header fields, those header fields **MUST** appear in the ACK. MUST-355: The request **MUST** be passed to the transport layer for transmission. MUST-356: If an unreliable transport is in use, the client transaction **MUST** set timer E to fire in T1 seconds. MUST-357: If a provisional response is received while in the "Trying" state, the response **MUST** be passed to the TU, and then the client transaction SHOULD move to the "Proceeding" state. MUST-358: If a final response (status codes 200-699) is received while in the "Trying" state, the response **MUST** be passed to the TU, and the client transaction MUST transition to the "Completed" state. MUST-359: If a final response (status codes 200-699) is received while in the "Trying" state, the response MUST be passed to the TU, and the client transaction **MUST** transition to the "Completed" state. MUST-360: If Timer E fires while in the "Proceeding" state, the request **MUST** be passed to the transport layer for retransmission, and Timer E MUST be reset with a value of T2 seconds. MUST-361: If Timer E fires while in the "Proceeding" state, the request MUST be passed to the transport layer for retransmission, and Timer E **MUST** be reset with a value of T2 seconds. MUST-362: If timer F fires while in the "Proceeding" state, the TU **MUST** be informed of a timeout, and the client transaction MUST transition to the terminated state. MUST-363: If timer F fires while in the "Proceeding" state, the TU MUST be informed of a timeout, and the client transaction **MUST** transition to the terminated state. MUST-364: If a final response (status codes 200-699) is received while in the "Proceeding" state, the response **MUST** be passed to the TU, and the client transaction MUST transition to the "Completed" state. MUST-365: If a final response (status codes 200-699) is received while in the "Proceeding" state, the response MUST be passed to the TU, and the client transaction **MUST** transition to the "Completed" state. MUST-366: Once the client transaction enters the "Completed" state, it **MUST** set Timer K to fire in T4 seconds for unreliable transports, and zero seconds for reliable transports. MUST-367: If Timer K fires while in this state, the client transaction **MUST** transition to the "Terminated" state. MUST-368: Once the transaction is in the terminated state, it **MUST** be destroyed immediately. MUST-369: The server transaction **MUST** generate a 100 (Trying) response unless it knows that the TU will generate a provisional or final response within 200 ms, in which case it MAY generate a 100 (Trying) response. MUST-370: The request **MUST** be passed to the TU. MUST-371: So long as the server transaction is in the "Proceeding" state, each of these **MUST** be passed to the transport layer for transmission. MUST-372: If a request retransmission is received while in the "Proceeding" state, the most recent provisional response that was received from the TU **MUST** be passed to the transport layer for retransmission. MUST-373: If, while in the "Proceeding" state, the TU passes a 2xx response to the server transaction, the server transaction **MUST** pass this response to the transport layer for transmission. MUST-374: The server transaction **MUST** then transition to the "Terminated" state. MUST-375: While in the "Proceeding" state, if the TU passes a response with status code from 300 to 699 to the server transaction, the response **MUST** be passed to the transport layer for transmission, and the state machine MUST enter the "Completed" state. MUST-376: While in the "Proceeding" state, if the TU passes a response with status code from 300 to 699 to the server transaction, the response MUST be passed to the transport layer for transmission, and the state machine **MUST** enter the "Completed" state. MUST-377: When the "Completed" state is entered, timer H **MUST** be set to fire in 64*T1 seconds for all transports. MUST-378: If an ACK is received while the server transaction is in the "Completed" state, the server transaction **MUST** transition to the "Confirmed" state. MUST-379: In this case, the server transaction **MUST** transition to the "Terminated" state, and MUST indicate to the TU that a transaction failure has occurred. MUST-380: In this case, the server transaction MUST transition to the "Terminated" state, and **MUST** indicate to the TU that a transaction failure has occurred. MUST-381: Once timer I fires, the server **MUST** transition to the "Terminated" state. MUST-382: Once the transaction is in the "Terminated" state, it **MUST** be destroyed immediately. MUST-383: While in the "Trying" state, if the TU passes a provisional response to the server transaction, the server transaction **MUST** enter the "Proceeding" state. MUST-384: The response **MUST** be passed to the transport layer for transmission. MUST-385: Any further provisional responses that are received from the TU while in the "Proceeding" state **MUST** be passed to the transport layer for transmission. MUST-386: If a retransmission of the request is received while in the "Proceeding" state, the most recently sent provisional response **MUST** be passed to the transport layer for retransmission. MUST-387: If the TU passes a final response (status codes 200-699) to the server while in the "Proceeding" state, the transaction **MUST** enter the "Completed" state, and the response MUST be passed to the transport layer for transmission. MUST-388: If the TU passes a final response (status codes 200-699) to the server while in the "Proceeding" state, the transaction MUST enter the "Completed" state, and the response **MUST** be passed to the transport layer for transmission. MUST-389: When the server transaction enters the "Completed" state, it **MUST** set Timer J to fire in 64*T1 seconds for unreliable transports, and zero seconds for reliable transports. MUST-390: While in the "Completed" state, the server transaction **MUST** pass the final response to the transport layer for retransmission whenever a retransmission of the request is received. MUST-391: Any other final responses passed by the TU to the server transaction **MUST** be discarded while in the "Completed" state. MUST-392: The server transaction remains in this state until Timer J fires, at which point it **MUST** transition to the "Terminated" state. MUST-393: The server transaction **MUST** be destroyed the instant it enters the "Terminated" state. MUST-394: All SIP elements **MUST** implement UDP and TCP. MUST-395: It has arisen out of the need to handle larger messages, which **MUST** use TCP, as discussed below. MUST-396: If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request **MUST** be sent using an RFC 2914 [43] congestion controlled transport protocol, such as TCP. MUST-397: If this causes a change in the transport protocol from the one indicated in the top Via, the value in the top Via **MUST** be changed. MUST-398: However, implementations **MUST** be able to handle messages up to the maximum datagram packet size. MUST-399: A client that sends a request to a multicast address **MUST** add the "maddr" parameter to its Via header field value containing the destination multicast address, and for IPv4, SHOULD add the "ttl" parameter with a value of 1. MUST-400: Before a request is sent, the client transport **MUST** insert a value of the "sent-by" field into the Via header field. MUST-401: Therefore, the client transport **MUST** be prepared to receive the response on the same connection used to send the request. MUST-402: To handle this case, the transport layer **MUST** also be prepared to receive an incoming connection on the source IP address from which the request was sent and port number in the "sent-by" field. MUST-403: **MUST** be prepared to receive incoming connections on any address and port that would be selected by a server based on the procedures described in Section 5 of [4]. MUST-404: For unreliable unicast transports, the client transport **MUST** be prepared to receive responses on the source IP address from which the request is sent (as responses are sent back to the source address) and the port number in the "sent-by" field. MUST-405: The client **MUST** be prepared to receive responses on any address and port that would be selected by a server based on the procedures described in Section 5 of [4]. MUST-406: For multicast, the client transport **MUST** be prepared to receive responses on the same multicast group and port to which the request is sent (that is, it needs to be a member of the multicast group it sent the request to.). MUST-407: If the value of the "sent-by" parameter in that header field value does not correspond to a value that the client transport is configured to insert into requests, the response **MUST** be silently discarded. MUST-408: If there is a match, the response **MUST** be passed to that transaction. MUST-409: Otherwise, the response **MUST** be passed to the core (whether it be stateless proxy, stateful proxy, or UA) for further processing. MUST-410: For any port and interface that a server listens on for UDP, it **MUST** listen on that same port and interface for TCP. MUST-411: When the server transport receives a request over any transport, it **MUST** examine the value of the "sent-by" parameter in the top Via header field value. MUST-412: If the host portion of the "sent-by" parameter contains a domain name, or if it contains an IP address that differs from the packet source address, the server **MUST** add a "received" parameter to that Via header field value. MUST-413: This parameter **MUST** contain the source address from which the packet was received. MUST-414: It **MUST** follow the following process:. MUST-415: o If the "sent-protocol" is a reliable transport protocol such as TCP or SCTP, or TLS over those, the response **MUST** be sent using the existing connection to the source of the original request that created the transaction, if that connection is still open. MUST-416: o Otherwise, if the Via header field value contains a "maddr" parameter, the response **MUST** be forwarded to the address listed there, using the port indicated in "sent-by", or port 5060 if none is present. MUST-417: o Otherwise (for unreliable unicast transports), if the top Via has a "received" parameter, the response **MUST** be sent to the address in the "received" parameter, using the port indicated in the "sent-by" value, or using port 5060 if none is specified explicitly. MUST-418: o Otherwise, if it is not receiver-tagged, the response **MUST** be sent to the address indicated by the "sent-by" value, using the procedures in Section 5 of [4]. MUST-419: If there are additional bytes in the transport packet beyond the end of the body, they **MUST** be discarded. MUST-420: If the message is a response, it **MUST** be discarded. MUST-421: The Content- Length header field **MUST** be used with stream oriented transports. MUST-422: For a SIPS URI, the transport parameter **MUST** indicate a reliable transport. MUST-423: The ttl parameter determines the time-to-live value of the UDP multicast packet and **MUST** only be used if maddr is a multicast address and the transport protocol is UDP. MUST-424: Since the uri-parameter mechanism is extensible, SIP elements **MUST** silently ignore any uri-parameters that they do not understand. MUST-425: Excluded US- ASCII characters (RFC 2396 [5]), such as space and control characters and characters used as URI delimiters, also **MUST** be escaped. MUST-426: All other characters **MUST** be escaped. MUST-427: Expanding the hname and hvalue tokens in Section 25 show that all URI reserved characters in header field names and values **MUST** be escaped. MUST-428: Any characters occurring in a telephone-subscriber that do not appear in an expansion of the BNF for the user rule **MUST** be escaped. MUST-429: Any present header component **MUST** be present in both URIs and match for the URIs to match. MUST-430: An implementation **MUST** include any provided transport, maddr, ttl, or user parameter in the Request-URI of the formed request. MUST-431: If the URI contains a method parameter, its value **MUST** be used as the method of the request. MUST-432: Unknown URI parameters **MUST** be placed in the message's Request-URI. MUST-433: When a tag is generated by a UA for insertion into a request or response, it **MUST** be globally unique and cryptographically random with at least 32 bits of randomness. MUST-434: If a stream-based protocol (such as TCP) is used as a transport, then the header field **MUST** be sent. MUST-435: A "mandatory" header field **MUST** be present in a request, and MUST be understood by the UAS receiving the request. MUST-436: A "mandatory" header field MUST be present in a request, and **MUST** be understood by the UAS receiving the request. MUST-437: A mandatory response header field **MUST** be present in the response, and the header field MUST be understood by the UAC processing the response. MUST-438: A mandatory response header field MUST be present in the response, and the header field **MUST** be understood by the UAC processing the response. MUST-439: If one is placed in a request by mistake, it **MUST** be ignored by the UAS receiving the request. MUST-440: Similarly, a header field labeled "not applicable" for a response means that the UAS MUST NOT place the header field in the response, and the UAC **MUST** ignore the header field in the response. MUST-441: If the URI contains a comma, question mark or semicolon, the URI **MUST** be enclosed in angle brackets (< and >). MUST-442: All methods, including ACK and CANCEL, understood by the UA **MUST** be included in the list of methods in the Allow header field, when present. MUST-443: Even if the "display-name" is empty, the "name-addr" form **MUST** be used if the "addr-spec" contains a comma, semicolon, or question mark. MUST-444: When present, its value indicates what additional content codings have been applied to the entity-body, and thus what decoding mechanisms **MUST** be applied in order to obtain the media-type referenced by the Content-Type header field. MUST-445: If multiple encodings have been applied to an entity-body, the content codings **MUST** be listed in the order in which they were applied. MUST-446: The server **MUST** only use encodings listed in the Accept-Encoding header field in the request. MUST-447: If a stream-based protocol (such as TCP) is used as transport, the header field **MUST** be used. MUST-448: If no body is present in a message, then the Content-Length header field value **MUST** be set to zero. MUST-449: The Content-Type header field **MUST** be present if the body is not empty. MUST-450: The sequence number **MUST** be expressible as a 32-bit unsigned integer. MUST-451: Even if the "display- name" is empty, the "name-addr" form **MUST** be used if the "addr-spec" contains a comma, question mark, or semicolon. MUST-452: Even if the "display-name" is empty, the "name-addr" form **MUST** be used if the "addr-spec" contains a comma, question mark, or semicolon. MUST-453: Each option tag defines a SIP extension that **MUST** be understood to process the request. MUST-454: A UAC compliant to this specification **MUST** only include option tags corresponding to standards-track RFCs. MUST-455: A UA compliant to this specification **MUST** only include option tags corresponding to standards-track RFCs. MUST-456: For implementations compliant to this specification, the value of the branch parameter **MUST** start with the magic cookie "z9hG4bK", as discussed in Section 8.1.1.7. MUST-457: The requested resource **MUST** be accessed through the proxy given by the Contact field. MUST-458: 305 (Use Proxy) responses **MUST** only be generated by UASs. MUST-459: The response **MUST** include an Allow header field containing a list of valid methods for the indicated address. MUST-460: This code is similar to 401 (Unauthorized), but indicates that the client **MUST** first authenticate itself with the proxy. MUST-461: The server **MUST** return a list of acceptable formats using the Accept, Accept-Encoding, or Accept-Language header field, depending on the specific problem with the content. MUST-462: The server **MUST** include a list of the unsupported extensions in an Unsupported header field in the response. MUST-463: Responses with this status code **MUST** contain a Require header field listing the required extensions. MUST-464: It **MUST** be possible to configure a server to respond with status 404 (Not Found) or to suppress the listing of possible choices for ambiguous Request-URIs. MUST-465: If no Retry-After is given, the client **MUST** act as if it had received a 500 (Server Internal Error) response. MUST-466: Operators of user agents or proxy servers that will authenticate received requests **MUST** adhere to the following guidelines for creation of a realm string for their server:. MUST-467: o Realm strings **MUST** be globally unique. MUST-468: For this reason, any credentials in the INVITE that were accepted by a server **MUST** be accepted by that server for the ACK. MUST-469: The WWW-Authenticate response-header field **MUST** be included in 401 (Unauthorized) response messages. MUST-470: When a UAC resubmits a request with its credentials after receiving a 401 (Unauthorized) or 407 (Proxy Authentication Required) response, it **MUST** increment the CSeq header field value as it would normally when sending an updated request. MUST-471: The proxy **MUST** populate the 407 (Proxy Authentication Required) message with a Proxy- Authenticate header field value applicable to the proxy for the requested resource. MUST-472: All 407 (Proxy Authentication Required) responses **MUST** be forwarded upstream toward the UAC following the procedures for any other response. MUST-473: Note that if an authentication scheme that does not support realms is used in the Proxy-Authorization header field, a proxy server **MUST** attempt to parse all Proxy-Authorization header field values to determine whether one of them has what the proxy server considers to be valid credentials. MUST-474: Each WWW-Authenticate and Proxy-Authenticate value received in responses to the forked request **MUST** be placed into the single response that is sent by the forking proxy to the UA; the ordering of these header field values is not significant. MUST-475: Since RFC 2543 is based on HTTP Digest as defined in RFC 2069 [39], SIP servers supporting RFC 2617 **MUST** ensure they are backwards compatible with RFC 2069. MUST-476: (The example in Section 3.5 of RFC 2617 is correct.) For SIP, the 'uri' **MUST** be enclosed in quotation marks. MUST-477: However, servers **MUST** always send a "qop" parameter in WWW-Authenticate and Proxy-Authenticate header field values. MUST-478: If a client receives a "qop" parameter in a challenge header field, it **MUST** send the "qop" parameter in any resulting authorization header field. MUST-479: These mechanisms **MUST** be used by a server to determine if the client supports the new mechanisms in RFC 2617 that were not specified in RFC 2069. MUST-480: Each user agent that supports S/MIME **MUST** contain a keyring specifically for end-users' certificates. MUST-481: Whenever the CMS SignedData message is used in S/MIME for SIP, it **MUST** contain the certificate bearing the public key necessary to verify the signature. MUST-482: If the certificate cannot be verified, because it is self-signed, or signed by no known authority, or if it is verifiable but its subject does not correspond to the From header field of request, the UAS **MUST** notify its user of the status of the certificate (including the subject of the certificate, its signer, and any key fingerprint information) and request explicit permission before proceeding. MUST-483: If the certificate cannot be verified because it is self-signed, or signed by no known authority, the UAC **MUST** notify its user of the status of the certificate (including the subject of the certificate, its signator, and any key fingerprint information) and request explicit permission before proceeding. MUST-484: If there is a discrepancy, the UA **MUST** notify its user of a change of the certificate (preferably in terms that indicate that this is a potential security breach) and acquire the user's permission before continuing to. MUST-485: If a UA receives an S/MIME body that has been encrypted with a public key unknown to the recipient, it **MUST** reject the request with a 493 (Undecipherable) response. MUST-486: Note that a user agent that receives a request containing an S/MIME body that is not optional (with a Content-Disposition header "handling" parameter of "required") **MUST** reject the request with a 415 Unsupported Media Type response if the MIME type is not understood. MUST-487: Finally, if during the course of a dialog a UA receives a certificate in a CMS SignedData message that does not correspond with the certificates previously exchanged during a dialog, the UA **MUST** notify its user of the change, preferably in terms that indicate that this is a potential security breach. MUST-488: o "multipart/signed" **MUST** be used only with CMS detached signatures. MUST-489: o S/MIME implementations **MUST** at a minimum support SHA1 as a digital signature algorithm, and 3DES as an encryption algorithm. MUST-490: Changes to any other header fields defined in this document constitute an integrity violation; users **MUST** be notified of a discrepancy. MUST-491: If present, the Date header field **MUST** always be the same in the "inner" and "outer" headers. MUST-492: If a SIP UA encounters an unknown header field with an integrity violation, it **MUST** ignore the header field. MUST-493: Any message bodies that require integrity protection **MUST** be attached to the "inner" message. MUST-494: The message must first be decrypted, and the "inner" From header field **MUST** be used as an index. MUST-495: These special characters **MUST** be in a quoted string to be used within a parameter value. MUST-496: Note, however, that any characters allowed there that are not allowed in the user part of the SIP URI **MUST** be escaped. MUST-497: The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] **MUST** be supported at a minimum by implementers when TLS is used in a SIP application. MUST-498: Proxy servers, redirect servers, and registrars **MUST** implement TLS, and MUST support both mutual and one-way authentication. MUST-499: Proxy servers, redirect servers, and registrars MUST implement TLS, and **MUST** support both mutual and one-way authentication. MUST-500: All SIP elements that support TLS **MUST** have a mechanism for validating certificates received during TLS negotiation; this entails possession of one or more root certificates issued by certificate authorities (preferably well-known distributors of site certificates comparable to those that issue root certificates for web browsers). MUST-501: All SIP elements that support TLS **MUST** also support the SIPS URI scheme. MUST-502: Proxy servers, redirect servers, registrars, and UAs **MUST** implement Digest Authorization, encompassing all of the aspects required in 22. MUST-503: The registrar SHOULD offer a certificate to the UA, and the site identified by the certificate **MUST** correspond with the domain in which the UA intends to register; for example, if the UA intends to register the address-of-record 'alice@atlanta.com', the site certificate must identify a host within the atlanta.com domain (such as sip.atlanta.com). MUST-504: The name **MUST** consist of alphanum (Section 25) characters only. MUST-505: This was changed to **MUST**. SHALL Requirements: Sha-1: In this document, the key words "MUST", "MUST NOT", "REQUIRED", "**SHALL**", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations. REQUIRED Requirements: Req-1: In this document, the key words "MUST", "MUST NOT", "**REQUIRED**", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations. SHOULD Requirements: S-1: In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "**SHOULD**", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations. S-2: The initial Request-URI of the message **SHOULD** be set to the value of the URI in the To field. S-3: A UAC **SHOULD** use the display name "Anonymous", along with a syntactically correct, but otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the identity of the client is to remain hidden. S-4: It **SHOULD** be the same in each registration from a UA. S-5: A UAC MUST insert a Max-Forwards header field into each request it originates with a value that **SHOULD** be 70. S-6: If the UAC supports extensions to SIP that can be applied by the server to the response, the UAC **SHOULD** include a Supported header field in the request listing the option tags (Section 19.2) for those extensions. S-7: However, that approach for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing route set with a single URI **SHOULD** be used instead. S-8: If the request contains a Route header field, the request **SHOULD** be sent to the locations derived from its topmost value, but MAY be sent to any server that the UA is certain will honor the Route and Request-URI policies specified in this document (as opposed to those in RFC 2543). S-9: In particular, a UAC configured with an outbound proxy **SHOULD**. S-10: The UAC **SHOULD** follow the procedures defined in [4] for stateful elements, trying each address until a server is contacted. S-11: If more than one Via header field value is present in a response, the UAC **SHOULD** discard the message. S-12: Upon receipt of a redirection response (for example, a 301 response status code), clients **SHOULD** use the URI(s) in the Contact header field to formulate one or more new requests based on the redirected request. S-13: If the original request had a SIPS URI in the Request- URI, the client MAY choose to recurse to a non-SIPS URI, but **SHOULD** inform the user of the redirection to an insecure URI. S-14: Failures **SHOULD** be detected through failure response codes (codes greater than 399); for network errors the client transaction will report any transport layer failures to the transaction user. S-15: When a failure for a particular contact address is received, the client **SHOULD** try the next contact address. S-16: In all other respects, requests sent upon receipt of a redirect response **SHOULD** re-use the header fields and bodies of the original request. S-17: If a 401 (Unauthorized) or 407 (Proxy Authentication Required) response is received, the UAC **SHOULD** follow the authorization procedures of Section 22.2 and Section 22.3 to retry the request with credentials. S-18: If possible, the UAC **SHOULD** retry the request, either omitting the body or using one of a smaller length. S-19: The UAC **SHOULD** retry sending the request, this time only using content with types listed in the Accept header field in the response, with encodings listed in the Accept-Encoding header field in the response, and with languages listed in the Accept-Language in the response. S-20: The client **SHOULD** retry the request, this time, using a SIP URI. S-21: The UAC **SHOULD** retry the request, this time omitting any extensions listed in the Unsupported header field in the response. S-22: This new request constitutes a new transaction and **SHOULD** have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous. S-23: UASs **SHOULD** process the requests in the order of the steps that follow in this section (that is, starting with authentication, then inspecting the method, the header fields, and so on throughout the remainder of this section). S-24: A UAS **SHOULD** ignore any malformed header fields that are not necessary for processing requests. S-25: If, on the other hand, the UAS decides to reject the request, it **SHOULD** generate a response with a 403 (Forbidden) status code and pass it to the server transaction for transmission. S-26: If the Request-URI uses a scheme not supported by the UAS, it **SHOULD** reject the request with a 416 (Unsupported URI Scheme) response. S-27: If the Request-URI does not identify an address that the UAS is willing to accept requests for, it **SHOULD** reject the request with a 404 (Not Found) response. S-28: If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core **SHOULD** generate a 482 (Loop Detected) response and pass it to the server transaction. S-29: If the desired extension is not supported, the server **SHOULD** rely only on baseline SIP and any other extensions supported by the client. S-30: Rather, UASs **SHOULD** generate a final response to a non-INVITE request as soon as possible. S-31: If there is a delay in generating the response, the UAS **SHOULD** add a delay value into the Timestamp value in the response. S-32: For well-formed CANCEL requests, it **SHOULD** return a 2xx response. S-33: Malformed values **SHOULD** be treated as equivalent to 3600. S-34: Once the CANCEL is constructed, the client **SHOULD** check whether it has received any response (provisional or final) for the request being cancelled (herein referred to as the "original request"). S-35: defined in Section 17.1.1.1), the client **SHOULD** then consider the original transaction cancelled and SHOULD destroy the client transaction handling the original request. S-36: defined in Section 17.1.1.1), the client SHOULD then consider the original transaction cancelled and **SHOULD** destroy the client transaction handling the original request. S-37: If the UAS did not find a matching transaction for the CANCEL according to the procedure above, it **SHOULD** respond to the CANCEL with a 481 (Call Leg/Transaction Does Not Exist). S-38: If the original request was an INVITE, the UAS **SHOULD** immediately respond to the INVITE with a 487 (Request Terminated). S-39: This response is constructed following the procedures described in Section 8.2.6 noting that the To tag of the response to the CANCEL and the To tag in the response to the original request **SHOULD** be the same. S-40: Call-ID: All registrations from a UAC **SHOULD** use the same Call-ID header field value for registrations sent to a particular registrar. S-41: Malformed values **SHOULD** be treated as equivalent to 3600. S-42: If the address-of-record in the To header field of a REGISTER request is a SIPS URI, then any Contact header field values in the request **SHOULD** also be SIPS URIs. S-43: UAs **SHOULD** support this mechanism so that bindings can be removed before their expiration interval has passed. S-44: A UA **SHOULD** use the same Call-ID for all registrations during a single boot cycle. S-45: Registration refreshes **SHOULD** be sent to the same network address as the original registration, unless redirected. S-46: If there is no configured registrar address, the UA **SHOULD** use the host part of the address- of-record as the Request-URI and address the request there, using the normal SIP server location mechanisms [4]. S-47: If not, and if the server also acts as a proxy server, the server **SHOULD** forward the request to the addressed domain, following the general behavior for proxying messages described in Section 16. S-48: A registrar **SHOULD** authenticate the UAC. S-49: The registrar **SHOULD** determine if the authenticated user is authorized to modify registrations for this address-of-record. S-50: The response **SHOULD** include a Date header field. S-51: An Accept header field **SHOULD** be included to indicate the type of message body the UAC wishes to receive in the response. S-52: Allow, Accept, Accept-Encoding, Accept-Language, and Supported header fields **SHOULD** be present in a 200 (OK) response to an OPTIONS request. S-53: If the response is generated by a proxy, the Allow header field **SHOULD** be omitted as it is ambiguous since a proxy is method agnostic. S-54: If the types include one that can describe media capabilities, the UAS **SHOULD** include a body in the response for that purpose. S-55: The URI **SHOULD** have global scope (that is, the same URI can be used in messages outside this dialog). S-56: A UAC **SHOULD** include a Contact header field in any target refresh requests within a dialog, and unless there is a need to change it, the URI SHOULD be the same as used in previous requests within the dialog. S-57: A UAC SHOULD include a Contact header field in any target refresh requests within a dialog, and unless there is a need to change it, the URI **SHOULD** be the same as used in previous requests within the dialog. S-58: If the response for a request within a dialog is a 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC **SHOULD** terminate the dialog. S-59: A UAC **SHOULD** also terminate a dialog if no response at all is received for the request (the client transaction would inform the TU about the timeout.). S-60: This is not an error condition, and a UAS **SHOULD** be prepared to receive and process requests with CSeq values more than one higher than the previous received request. S-61: An Allow header field (Section 20.5) **SHOULD** be present in the INVITE. S-62: For example, a UA capable of receiving INFO requests within a dialog [34] **SHOULD** include an Allow header field listing the INFO method. S-63: A Supported header field (Section 20.37) **SHOULD** be present in the INVITE. S-64: If the time indicated in the Expires header field is reached and no final answer for the INVITE has been received, the UAC core **SHOULD** generate a CANCEL request for the INVITE, as per Section 9. S-65: If the invitation expires before the UAS has generated a final response, a 487 (Request Terminated) response **SHOULD** be generated. S-66: A 300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved Temporarily) response **SHOULD** contain a Contact header field. S-67: A 486 (Busy Here) **SHOULD** be returned in such a scenario. S-68: If the UAS knows that no other end system will be able to accept this call, a 600 (Busy Everywhere) response **SHOULD** be sent instead. S-69: A UAS rejecting an offer contained in an INVITE **SHOULD** return a 488 (Not Acceptable Here) response. S-70: Such a response **SHOULD** include a Warning header field value explaining why the offer was rejected. S-71: A 2xx response to an INVITE **SHOULD** contain the Allow header field and the Supported header field, and MAY contain the Accept header field. S-72: If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is confirmed, but the session **SHOULD** be terminated. S-73: In any case, if these messages are sent automatically, they **SHOULD** be sent after some randomized interval. S-74: If the session description format has the capability for version numbers, the offerer **SHOULD** indicate that the version of the session description has changed. S-75: If a UAC receives a 491 response to a re-INVITE, it **SHOULD** start a timer with a value T chosen as follows:. S-76: When the timer fires, the UAC **SHOULD** attempt the re-INVITE once more, if it still desires for that session modification to take place. S-77: This response **SHOULD** include a Warning header field. S-78: If a UAS generates a 2xx response and never receives an ACK, it **SHOULD** generate a BYE to terminate the dialog. S-79: A UAS providing an offer in a 2xx (because the INVITE did not contain an offer) **SHOULD** construct the offer as if the UAS were making a brand new call, subject to the constraints of sending an offer that updates an existing session, as described in [13] in the case of SDP. S-80: Specifically, this means that it **SHOULD** include as many media formats and media types that the UA is willing to support. S-81: If, however, it is unacceptable to the UAC, the UAC **SHOULD** generate an answer with a valid session description, and then send a BYE to terminate the session. S-82: When a BYE is received on a dialog, any session associated with that dialog **SHOULD** terminate. S-83: If the BYE does not match an existing dialog, the UAS core **SHOULD** generate a 481 (Call/Transaction Does Not Exist) response and pass that to the server transaction. S-84: Once done, the UAS **SHOULD** terminate the session (and therefore stop sending and listening for media). S-85: Any other components, well-formed or not, **SHOULD** be ignored and remain unchanged when the message is forwarded. S-86: If the Request-URI has a URI whose scheme is not understood by the proxy, the proxy **SHOULD** reject the request with a 416 (Unsupported URI Scheme) response. S-87: If the Request-URI does not provide sufficient information for the proxy to determine the target set, it **SHOULD** return a 485 (Ambiguous) response. S-88: This response **SHOULD** contain a Contact header field containing URIs of new addresses to be tried. S-89: If a proxy uses a dynamic source of information while building the target set (for instance, if it consults a SIP Registrar), it **SHOULD** monitor that source for the duration of processing the request. S-90: New locations **SHOULD** be added to the target set as they become available. S-91: If the target set remains empty after applying all of the above, the proxy MUST return an error response, which **SHOULD** be the 480 (Temporarily Unavailable) response. S-92: The copy **SHOULD** maintain the ordering of the header fields as in the received request. S-93: If the copy does not contain a Max-Forwards header field, the proxy MUST add one with a field value, which **SHOULD** be 70. S-94: If this request is already part of a dialog, the proxy **SHOULD** insert a Record-Route header field value if it wishes to remain on the path of future requests in the dialog. S-95: If a proxy needs to be in the path of any type of dialog (such as one straddling a firewall), it **SHOULD** add a Record-Route header field value to every request with a method it does not understand since that method may have dialog semantics. S-96: A proxy choosing to detect loops **SHOULD** create a branch parameter separable into two parts by the implementation. S-97: The value placed in this part of the branch parameter **SHOULD** reflect all of those fields (including any Route, Proxy-Require and Proxy- Authorization header fields). S-98: If a proxy receives a 416 (Unsupported URI Scheme) response to a request whose Request-URI scheme was not SIP, but the scheme in the original received request was SIP or SIPS (that is, the proxy changed the scheme from SIP or SIPS to something else when it proxied a request), the proxy **SHOULD** add a new URI to the target set. S-99: This URI **SHOULD** be a SIP URI version of the non-SIP URI that was just tried. S-100: If a 6xx response is received, it is not immediately forwarded, but the stateful proxy **SHOULD** cancel all client pending transactions as described in Section 10, and it MUST NOT create any new branches in this context. S-101: If no 6xx class responses are present, the proxy **SHOULD** choose from the lowest response class stored in the response context. S-102: The proxy **SHOULD**. S-103: If the only response that was received is a 503, the proxy **SHOULD** generate a 500 response and forward that upstream. S-104: An element **SHOULD** preserve the To tag when simply forwarding a 3-6xx response to a request that did not contain a To tag. S-105: A proxy **SHOULD** also generate a CANCEL request for all pending client transactions associated with this response context when it receives a 6xx response. S-106: Because of the non-INVITE transaction's reliance on a two-way handshake, TUs **SHOULD** respond immediately to non-INVITE requests. S-107: These retransmissions **SHOULD** only be done while the client transaction is in the "calling" state. S-108: If the client transaction is still in the "Calling" state when timer B fires, the client transaction **SHOULD** inform the TU that a timeout has occurred. S-109: The client transaction **SHOULD** start timer D when it enters the "Completed" state, with a value of at least 32 seconds for unreliable transports, and a value of zero seconds for reliable transports. S-110: When entering this state, the client transaction **SHOULD** set timer F to fire in 64*T1 seconds. S-111: If Timer F fires while the client transaction is still in the "Trying" state, the client transaction **SHOULD** inform the TU about the timeout, and then it SHOULD enter the "Terminated" state. S-112: If Timer F fires while the client transaction is still in the "Trying" state, the client transaction SHOULD inform the TU about the timeout, and then it **SHOULD** enter the "Terminated" state. S-113: If a provisional response is received while in the "Trying" state, the response MUST be passed to the TU, and then the client transaction **SHOULD** move to the "Proceeding" state. S-114: The client transaction **SHOULD** inform the TU that a transport failure has occurred, and the client transaction SHOULD transition directly to the "Terminated" state. S-115: The client transaction SHOULD inform the TU that a transport failure has occurred, and the client transaction **SHOULD** transition directly to the "Terminated" state. S-116: Furthermore, while in the "Completed" state, if a request retransmission is received, the server **SHOULD** pass the response to the transport for retransmission. S-117: If those should all fail, based on the definition of failure in [4], the server transaction **SHOULD** inform the TU that a failure has occurred, and SHOULD transition to the terminated state. S-118: If those should all fail, based on the definition of failure in [4], the server transaction SHOULD inform the TU that a failure has occurred, and **SHOULD** transition to the terminated state. S-119: This duration **SHOULD** at least equal the longest amount of time the element would need in order to bring a transaction from instantiation to the terminated state. S-120: If an element sends a request over TCP because of these message size constraints, and that request would have otherwise been sent over UDP, if the attempt to establish the connection generates either an ICMP Protocol Not Supported, or results in a TCP reset, the element **SHOULD** retry the request, using UDP. S-121: A client that sends a request to a multicast address MUST add the "maddr" parameter to its Via header field value containing the destination multicast address, and for IPv4, **SHOULD** add the "ttl" parameter with a value of 1. S-122: A server **SHOULD** be prepared to receive requests on any IP address, port and transport combination that can be the result of a DNS lookup on a SIP or SIPS URI [4] that is handed out for the purposes of communicating with that server. S-123: If that connection is no longer open, the server **SHOULD** open a connection to the IP address in the "received" parameter, if present, using the port in the "sent-by" value, or the default port for that transport, if no port is specified. S-124: If that connection attempt fails, the server **SHOULD** use the procedures in [4] for servers in order to determine the IP address and port to open the connection and send the response to. S-125: If the address is a multicast address, the response **SHOULD** be sent using the TTL indicated in the "ttl" parameter, or with a TTL of 1 if that parameter is not present. S-126: If this fails, for example, elicits an ICMP "port unreachable" response, the procedures of Section 5 of [4] **SHOULD** be used to determine where to send the response. S-127: If the message is a request, the element **SHOULD** generate a 400 (Bad Request) response. S-128: Host, network, port or protocol unreachable errors, or parameter problem errors **SHOULD** cause the transport layer to inform the transport user of a failure in sending. S-129: Source quench and TTL exceeded ICMP errors **SHOULD** be ignored. S-130: If the transport user asks for a request to be sent over a reliable transport, and the result is a connection failure, the transport layer **SHOULD** inform the transport user of a failure in sending. S-131: If the user string contains a telephone number formatted as a telephone-subscriber, the user parameter value "phone" **SHOULD** be present. S-132: Elements processing URIs **SHOULD** ignore any disallowed components if they are present. S-133: An implementation **SHOULD** treat the presence of any headers or body parts in the URI as a desire to include them in the message, and choose to honor the request on a per-component basis. S-134: An implementation **SHOULD** verify the accuracy of any requested descriptive header fields, including: Content-Disposition, Content- Encoding, Content-Language, Content-Length, Content-Type, Date, Mime-Version, and Timestamp. S-135: An implementation **SHOULD** refuse to send these requests rather than modifying them to match their capabilities. S-136: To mitigate this problem, elements constructing telephone-subscriber fields to place in the userinfo part of a SIP or SIPS URI **SHOULD** fold any case-insensitive portion of telephone-subscriber to lower case, and order the telephone-subscriber parameters lexically by parameter name, excepting isdn-subaddress and post-dial, which occur first and in that order. S-137: m*: The header field **SHOULD** be sent, but clients/servers need to be prepared to receive messages without that header field. S-138: t: The header field **SHOULD** be sent, but clients/servers need to be prepared to receive messages without that header field. S-139: A UA **SHOULD** ignore extension header parameters that are not understood. S-140: The semantics are also identical, with the exception that if no Accept header field is present, the server **SHOULD** assume a default value of application/sdp. S-141: If no Accept-Encoding header field is present, the server **SHOULD** assume a default value of identity. S-142: If no Accept-Language header field is present, the server **SHOULD** assume all languages are acceptable to the client. S-143: In addition, a user **SHOULD** be able to disable this feature selectively. S-144: For backward-compatibility, if the Content-Disposition header field is missing, the server **SHOULD** assume bodies of Content-Type application/sdp are the disposition "session", while other content types are "render". S-145: If the handling parameter is missing, the value "required" **SHOULD** be assumed. S-146: Applications **SHOULD** use this field to indicate the size of the message-body to be transferred, regardless of the media type of the entity. S-147: A system **SHOULD** use the display name "Anonymous" if the identity of the client is to remain hidden. S-148: For these decisions, a message containing no Priority header field **SHOULD** be treated as if it specified a Priority of "normal". S-149: If the user wished to remain anonymous, the header field **SHOULD** either be omitted from the request or populated in such a way that does not reveal any private information. S-150: Implementers **SHOULD** make the Server header field a configurable option. S-151: Implementers **SHOULD** make the User-Agent header field a configurable option. S-152: The choices **SHOULD** also be listed as Contact fields (Section 20.10). S-153: The user can no longer be found at the address in the Request-URI, and the requesting client **SHOULD** retry at the new address given by the Contact header field (Section 20.10). S-154: The requestor **SHOULD** update any local directories, address books, and user location caches with this new value and redirect future requests to the address(es) listed. S-155: The requesting client **SHOULD** retry the request at the new address(es) given by the Contact header field (Section 20.10). S-156: The Reason-Phrase **SHOULD** identify the syntax problem in more detail, for example, "Missing Call-ID header field". S-157: If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) **SHOULD** be used instead. S-158: If the condition is temporary, the server **SHOULD** include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again. S-159: Instead, if a desirable extension is not listed in the Supported header field, servers **SHOULD** process the request using baseline SIP capabilities and any extensions supported by the client. S-160: The reason phrase **SHOULD** indicate a more precise cause as to why the callee is unavailable. S-161: This value **SHOULD** be settable by the UA. S-162: Additional information **SHOULD** be provided in the reason phrase. S-163: Status 600 (Busy Everywhere) **SHOULD** be used if the client knows that no other end system will be able to accept this call. S-164: A client (proxy or UAC) receiving a 503 (Service Unavailable) **SHOULD** attempt to forward the request to an alternate server. S-165: Once the originator has been identified, the recipient of the request **SHOULD** ascertain whether or not this user is authorized to make the request in question. S-166: o Realm strings **SHOULD** present a human-readable identifier that can be rendered to a user. S-167: Generally, a CANCEL request **SHOULD** be accepted by a server if it comes from the same hop that sent the request being canceled (provided that some sort of transport or network layer security association, as described in Section 26.2.1, is in place). S-168: When a UAC receives a challenge, it **SHOULD** render to the user the contents of the "realm" parameter in the challenge (which appears in either a WWW-Authenticate header field or Proxy-Authenticate header field) if the UAC device does not already know of a credential for the realm in question. S-169: When the originating UAC receives the 401 (Unauthorized), it **SHOULD**, if it is able, re-originate the request with the proper credentials. S-170: Once authentication credentials have been supplied (either directly by the user, or discovered in an internal keyring), UAs **SHOULD** cache the credentials for a given value of the To header field and "realm" and attempt to re-use these values on the next request for that destination. S-171: When the originating UAC receives the 407 (Proxy Authentication Required) it **SHOULD**, if it is able, re-originate the request with the proper credentials. S-172: The UAC **SHOULD** also cache the credentials used in the re-originated request. S-173: Because this is potentially very time- consuming in large networks, proxy servers **SHOULD** use an authentication scheme that supports realms in the Proxy-Authorization header field. S-174: As noted above, multiple credentials in a request **SHOULD** be differentiated by the "realm" parameter. S-175: The same credentials **SHOULD** be used for the same realm. S-176: Over time, users **SHOULD** use the same certificate when they populate the originating URI of signaling (the From header field) with the same address-of-record. S-177: However, users **SHOULD** acquire certificates from known public certificate authorities. S-178: However, the holder of a certificate **SHOULD** publish their certificate in any public directories as appropriate. S-179: Similarly, UACs **SHOULD** support a mechanism for importing (manually or automatically) certificates discovered in public directories corresponding to the target URIs of SIP requests. S-180: When a UAC sends a request containing an S/MIME body that initiates a dialog, or sends a non-INVITE request outside the context of a dialog, the UAC **SHOULD** structure the body as an S/MIME 'multipart/signed' CMS SignedData body. S-181: If the desired CMS service is EnvelopedData (and the public key of the target user is known), the UAC **SHOULD** send the EnvelopedData message encapsulated within a SignedData message. S-182: When a UAS receives a request containing an S/MIME CMS body that includes a certificate, the UAS **SHOULD** first validate the certificate, if possible, with any available root certificates for certificate authorities. S-183: The UAS **SHOULD** also determine the subject of the certificate (for S/MIME, the SubjectAltName will contain the appropriate identity) and compare this value to the From header field. S-184: If the certificate was successfully verified and the subject of the certificate corresponds to the From header field of the SIP request, or if the user (after notification) explicitly authorizes the use of the certificate, the UAS **SHOULD** add this certificate to a local keyring, indexed by the address-of-record of the holder of the certificate. S-185: When a UAS sends a response containing an S/MIME body that answers the first request in a dialog, or a response to a non-INVITE request outside the context of a dialog, the UAS **SHOULD** structure the body as an S/MIME 'multipart/signed' CMS SignedData body. S-186: If the desired CMS service is EnvelopedData, the UAS **SHOULD** send the EnvelopedData message encapsulated within a SignedData message. S-187: When a UAC receives a response containing an S/MIME CMS body that includes a certificate, the UAC **SHOULD** first validate the certificate, if possible, with any appropriate root certificate. S-188: The UAC **SHOULD** also determine the subject of the certificate and compare this value to the To field of the response; although the two may very well be different, and this is not necessarily indicative of a security breach. S-189: If the certificate was successfully verified, and the subject of the certificate corresponds to the To header field in the response, or if the user (after notification) explicitly authorizes the use of the certificate, the UAC **SHOULD** add this certificate to a local keyring, indexed by the address-of-record of the holder of the certificate. S-190: If the UAC had not transmitted its own certificate to the UAS in any previous transaction, it **SHOULD** use a CMS SignedData body for its next request or response. S-191: On future occasions, when the UA receives requests or responses that contain a From header field corresponding to a value in its keyring, the UA **SHOULD** compare the certificate offered in these messages with the existing certificate in its keyring. S-192: If the user authorizes this certificate, it **SHOULD** be added to the keyring alongside any previous value(s) for this address-of-record. S-193: This response **SHOULD** contain a valid certificate for the respondent (corresponding, if possible, to any address of record given in the To header field of the rejected request) within a MIME body with a 'certs-only' "smime-type" parameter. S-194: A user agent that receives such a response when S/MIME is sent **SHOULD** notify its user that the remote device does not support S/MIME, and it MAY subsequently resend the request without S/MIME, if appropriate; however, this 415 response may constitute a downgrade attack. S-195: If a user agent sends an S/MIME body in a request, but receives a response that contains a MIME body that is not secured, the UAC **SHOULD** notify its user that the session could not be secured. S-196: However, if a user agent that supports S/MIME receives a request with an unsecured body, it SHOULD NOT respond with a secured body, but if it expects S/MIME from the sender (for example, because the sender's From header field value corresponds to an identity on its keychain), the UAS **SHOULD** notify its user that the session could not be secured. S-197: o S/MIME bodies **SHOULD** have a Content-Disposition header field, and the value of the "handling" parameter SHOULD be "required.". S-198: o S/MIME bodies SHOULD have a Content-Disposition header field, and the value of the "handling" parameter **SHOULD** be "required.". S-199: UACs MAY send an initial request such as an OPTIONS message with a CMS detached signature in order to solicit the certificate of the remote side (the signature **SHOULD** be over a "message/sip" body of the type described in Section 23.4). S-200: o Senders of S/MIME bodies **SHOULD** use the "SMIMECapabilities" (see Section 2.5.2 of [24]) attribute to express their capabilities and preferences for further communications. S-201: o Each S/MIME body in a SIP message **SHOULD** be signed with only one certificate. S-202: If a UAS receives a request that contains a tunneled "message/sip" S/MIME body, it **SHOULD** include a tunneled "message/sip" body in the response with the same smime-type. S-203: Any traditional MIME bodies (such as SDP) **SHOULD** be attached to the "inner" message so that they can also benefit from S/MIME security. S-204: Note that for the purposes of loose timestamping, all SIP messages that tunnel "message/sip" **SHOULD** contain a Date header in both the "inner" and "outer" headers. S-205: If the From header field in an encrypted body differs from the value in the "outer" message, the value within the encrypted body **SHOULD** be displayed to the user, but MUST NOT be used in the "outer" header fields of any future messages. S-206: UAs **SHOULD** never include these in an "inner" message if they are not. S-207: UAs that receive any of these header fields in an encrypted body **SHOULD** ignore the encrypted values. S-208: In order to eliminate possible confusions about the addition or subtraction of entire header fields, senders **SHOULD** replicate all header fields from the request within the signed body. S-209: If a Date header is present in a message with a signed body, the recipient **SHOULD** compare the header field value with its own internal clock, if applicable. S-210: If a significant time discrepancy is detected (on the order of an hour or more), the user agent **SHOULD** alert the user to the anomaly, and note that it is a potential security breach. S-211: UAs **SHOULD** notify users of this circumstance and request explicit guidance on how to proceed. S-212: In order to provide end-to-end integrity, encrypted "message/sip" MIME bodies **SHOULD** be signed by the sender. S-213: For purposes of backwards compatibility, proxy servers, redirect servers, and registrars **SHOULD** support TLS_RSA_WITH_3DES_EDE_CBC_SHA. S-214: The use of SIPS in particular entails that mutual TLS authentication **SHOULD** be employed, as SHOULD the ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. S-215: The use of SIPS in particular entails that mutual TLS authentication SHOULD be employed, as **SHOULD** the ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. S-216: Certificates received in the authentication process **SHOULD** be validated with root certificates held by the client; failure to validate a certificate SHOULD result in the failure of the request. S-217: Certificates received in the authentication process SHOULD be validated with root certificates held by the client; failure to validate a certificate **SHOULD** result in the failure of the request. S-218: Proxy servers, redirect servers, and registrars **SHOULD** possess a site certificate whose subject corresponds to their canonical hostname. S-219: When a UA attempts to contact a proxy server, redirect server, or registrar, the UAC **SHOULD** initiate a TLS connection over which it will send SIP messages. S-220: Proxy servers, redirect servers, and registrars **SHOULD** be configured with at least one Digest realm, and at least one "realm" string supported by a given server SHOULD correspond to the server's hostname or domainname. S-221: Proxy servers, redirect servers, and registrars SHOULD be configured with at least one Digest realm, and at least one "realm" string supported by a given server **SHOULD** correspond to the server's hostname or domainname. S-222: If a UA holds one or more root certificates of certificate authorities in order to validate certificates for TLS or IPSec, it **SHOULD** be capable of reusing these to verify S/MIME certificates, as appropriate. S-223: When a UA comes online and registers with its local administrative domain, it **SHOULD** establish a TLS connection with its registrar (Section 10 describes how the UA reaches its registrar). S-224: The registrar **SHOULD** offer a certificate to the UA, and the site identified by the certificate MUST correspond with the domain in which the UA intends to register; for example, if the UA intends to register the address-of-record 'alice@atlanta.com', the site certificate must identify a host within the atlanta.com domain (such as sip.atlanta.com). S-225: When it receives the TLS Certificate message, the UA **SHOULD** verify the certificate and inspect the site identified by the certificate. S-226: The UA then creates a REGISTER request that **SHOULD** be addressed to a Request-URI corresponding to the site certificate received from the registrar. S-227: When the UA sends the REGISTER request over the existing TLS connection, the registrar **SHOULD** challenge the request with a 401 (Proxy Authentication Required) response. S-228: The "realm" parameter within the Proxy-Authenticate header field of the response **SHOULD** correspond to the domain previously given by the site certificate. S-229: When the UAC receives the challenge, it **SHOULD** either prompt the user for credentials or take an appropriate credential from a keyring corresponding to the "realm" parameter in the challenge. S-230: The username of this credential **SHOULD** correspond with the "userinfo" portion of the URI in the To header field of the REGISTER request. S-231: Once the registration has been accepted by the registrar, the UA **SHOULD** leave this TLS connection open provided that the registrar also acts as the proxy server to which requests are sent for users in this administrative domain. S-232: process described in the preceding section, it **SHOULD** reuse the TLS connection to the local proxy server when it sends an INVITE request to another user. S-233: The UA **SHOULD** reuse cached credentials in the INVITE to avoid prompting the user unnecessarily. S-234: When the local outbound proxy server has validated the credentials presented by the UA in the INVITE, it **SHOULD** inspect the Request-URI to determine how the message should be routed (see [4]). S-235: The local outbound proxy server at atlanta.com **SHOULD** therefore establish a TLS connection with the remote proxy server at biloxi.com. S-236: Since both of the participants in this TLS connection are servers that possess site certificates, mutual TLS authentication **SHOULD** occur. S-237: Each side of the connection **SHOULD** verify and inspect the certificate of the other, noting the domain name that appears in the certificate for comparison with the header fields of SIP messages. S-238: The atlanta.com proxy server, for example, **SHOULD** verify at this stage that the certificate received from the remote side corresponds with the biloxi.com domain. S-239: The proxy server at biloxi.com **SHOULD** inspect the certificate of the proxy server at atlanta.com in turn and compare the domain asserted by the certificate with the "domainname" portion of the From header field in the INVITE request. S-240: Once the INVITE has been approved by the biloxi proxy, the proxy server **SHOULD** identify the existing TLS channel, if any, associated with the user targeted by this request (in this case "bob@biloxi.com"). S-241: Before they forward the request, both proxy servers **SHOULD** add a Record-Route header field to the request so that all future requests in this dialog will pass through the proxy servers. S-242: When Carol wishes to send an INVITE to "bob@biloxi.com", her UA **SHOULD** initiate a TLS connection with the biloxi proxy directly (using the mechanism described in [4] to determine how to best to reach the given Request-URI). S-243: When her UA receives a certificate from the biloxi proxy, it **SHOULD** be verified normally before she passes her INVITE across the TLS connection. S-244: Carol **SHOULD** then establish a TCP connection with the designated address and send a new INVITE with a Request-URI containing the received contact address (recomputing the signature in the body as the request is readied). S-245: When the host on which a SIP proxy server is operating is routable from the public Internet, it **SHOULD** be deployed in an administrative domain with defensive operational policies (blocking source-routed traffic, preferably filtering ping traffic). S-246: UAs and proxy servers **SHOULD** challenge questionable requests with only a single 401 (Unauthorized) or 407 (Proxy Authentication Required), forgoing the normal response retransmission algorithm, and thus behaving statelessly towards unauthenticated requests. S-247: If the UAS has reason to believe that the scheme of the Request-URI has been improperly modified in transit, the UA **SHOULD** notify its user of a potential security breach. S-248: A user location service can infringe on the privacy of the recipient of a session invitation by divulging their specific whereabouts to the caller; an implementation consequently **SHOULD** be able to restrict, on a per-user basis, what kind of location and availability information is given out to certain classes of callers. S-249: The name MAY be of any length, but **SHOULD** be no more than twenty characters long. RECOMMENDED Requirements: Rec-1: In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "**RECOMMENDED**", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations. Rec-2: However, it is **RECOMMENDED** that header fields which are needed for proxy processing (Via, Route, Record-Route, Proxy-Require, Max-Forwards, and Proxy-Authorization, for example) appear towards the top of the message to facilitate rapid parsing. Rec-3: When a provider wishes to configure a UA with an outbound proxy, it is **RECOMMENDED** that this be done by providing it with a pre-existing route set with a single URI, that of the outbound proxy. Rec-4: Use of cryptographically random identifiers (RFC 1750 [12]) in the generation of Call-IDs is **RECOMMENDED**. Rec-5: It is **RECOMMENDED** that the UAC reuse the same To, From, and Call-ID used in the original redirected request, but the UAC MAY also choose to update the Call-ID header field value for new requests, for example. Rec-6: However, it is **RECOMMENDED** that a UAS accept requests even if they do not recognize the URI scheme (for example, a tel: URI) in the To header field, or if the To header field does not address a known or current user of this UAS. Rec-7: It is **RECOMMENDED** that a 487 (Request Terminated) response be generated to those pending requests. Rec-8: A **RECOMMENDED** mechanism to achieve this is for the proxy to append a unique identifier for the proxy instance to the user portion of the URI. Rec-9: However, the following procedure is **RECOMMENDED**. Rec-10: T1 MAY be chosen larger, and this is **RECOMMENDED** if it is known in advance (such as on high latency access links) that the RTT is larger. Rec-11: It is **RECOMMENDED** that connections be kept open for some implementation-defined duration after the last message was sent or received over that connection. Rec-12: The usage of an FQDN is **RECOMMENDED**. Rec-13: If a request is destined to an IP address, port, and transport to which an existing connection is open, it is **RECOMMENDED** that this connection be used to send the request, but another connection MAY be opened and used. Rec-14: It is also **RECOMMENDED** that a server listen for requests on the default SIP ports (5060 for TCP and UDP, 5061 for TLS over TCP) on all public interfaces. Rec-15: Using the fully-qualified domain name form is **RECOMMENDED** whenever possible. Rec-16: Therefore, it is **RECOMMENDED** that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element. Rec-17: It is **RECOMMENDED** that the value of "emergency" only be used when life, limb, or property are in imminent danger. Rec-18: It is **RECOMMENDED** that a realm string contain a hostname or domain name, following the recommendation in Section 3.2.1 of RFC 2617 [17]. Rec-19: The following rule is **RECOMMENDED** for proxy credential caching:. Rec-20: It is strongly **RECOMMENDED** that UAs be capable initiating TLS; UAs MAY also be capable of acting as a TLS server. Rec-21: For that reason, it is **RECOMMENDED** that TCP should be used as a transport protocol when S/MIME tunneling is employed. Rec-22: To address these concerns, it is **RECOMMENDED** that recipients of a request whose Request-URI contains a SIP or SIPS URI inspect the To header field value to see if it contains a SIPS URI (though note that it does not constitute a breach of security if this URI has the same scheme but is not equivalent to the URI in the To header field). MAY Requirements: MAY-1: In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "**MAY**", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations. MAY-2: Proxy, location, and registrar servers defined above are logical entities; implementations **MAY** combine them into a single application. MAY-3: SIP elements **MAY** support Request-URIs with schemes other than "sip" and "sips", for example the "tel" URI scheme of RFC 2806 [9]. MAY-4: SIP elements **MAY** translate non-SIP URIs using any mechanism at their disposal, resulting in SIP URI, SIPS URI, or some other scheme. MAY-5: While this specification suggests specific wording for the reason phrase, implementations **MAY** choose other text, for example, in the language indicated in the Accept-Language header field of the request. MAY-6: Multiple header field rows with the same field-name **MAY** be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list (that is, if follows the grammar defined in Section 7.3). MAY-7: field rows with these names **MAY** be present in a message, but since their grammar does not follow the general form listed in Section 7.3, they MUST NOT be combined into a single header field row. MAY-8: A compact form **MAY** be substituted for the longer form of a header field name at any time without changing the semantics of the message. MAY-9: field name **MAY** appear in both long and short forms within the same message. MAY-10: Requests, including new requests defined in extensions to this specification, **MAY** contain message bodies unless otherwise noted. MAY-11: All responses **MAY** include a body. MAY-12: The "multipart" MIME type defined in RFC 2046 [11] **MAY** be used within the body of the message. MAY-13: SIP messages **MAY** contain binary bodies or body parts. MAY-14: The To header field **MAY** contain a SIP or SIPS URI, but it may also make use of other URI schemes (the tel URL (RFC 2806 [9]), for example) when appropriate. MAY-15: Implementations **MAY** use the form "localid@host". MAY-16: SIP requests **MAY** contain a MIME-encoded message-body. MAY-17: Local policy **MAY** specify an alternate set of destinations to attempt. MAY-18: If the request contains a Route header field, the request SHOULD be sent to the locations derived from its topmost value, but **MAY** be sent to any server that the UA is certain will honor the Route and Request-URI policies specified in this document (as opposed to those in RFC 2543). MAY-19: If the original request had a SIPS URI in the Request- URI, the client **MAY** choose to recurse to a non-SIPS URI, but SHOULD inform the user of the redirection to an insecure URI. MAY-20: As the target set grows, the client **MAY** generate new requests to the URIs in any order. MAY-21: Requests to the URIs **MAY** be generated serially or in parallel. MAY-22: As a general rule, if the header field can accept a comma-separated list of values, then the new header field value **MAY** be appended to any existing values in the original redirected request. MAY-23: If the header field does not accept multiple values, the value in the original redirected request **MAY** be overwritten by the header field value communicated in the contact address. MAY-24: It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID used in the original redirected request, but the UAC **MAY** also choose to update the Call-ID header field value for new requests, for example. MAY-25: A UAS **MAY** apply any policy it wishes to determine whether to accept requests when the To. MAY-26: In rare circumstances, where the server cannot process the request without the extension, the server **MAY** send a 421 (Extension Required) response. MAY-27: However, if the To header field in the request did not contain a tag, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response (with the exception of the 100 (Trying) response, in which a tag **MAY** be present). MAY-28: However, redirect servers MUST NOT redirect a request to a URI equal to the one in the Request-URI; instead, provided that the URI does not point to itself, the server **MAY** proxy the request to the destination URI, or MAY reject it with a 404. MAY-29: However, redirect servers MUST NOT redirect a request to a URI equal to the one in the Request-URI; instead, provided that the URI does not point to itself, the server MAY proxy the request to the destination URI, or **MAY** reject it with a 404. MAY-30: Note that a Contact header field value **MAY** also refer to a different resource than the one originally called. MAY-31: A registrar **MAY** be co-located with a particular SIP proxy server for the same domain. MAY-32: A UAC **MAY** include a Route header field in a REGISTER request based on a pre-existing route set as described in Section 8.1. MAY-33: A Contact header field **MAY** be included:. MAY-34: Contact: REGISTER requests **MAY** contain a Contact header field with zero or more values containing address bindings. MAY-35: Implementations **MAY** treat values larger than 2**32-1 (4294967295 seconds or 136 years) as equivalent to 2**32-1. MAY-36: The Contact header field values of the request typically consist of SIP or SIPS URIs that identify particular SIP endpoints (for example, "sip:carol@cube2214a.chicago.com"), but they **MAY** use any URI scheme. MAY-37: Once a client has established bindings at a registrar, it **MAY** send subsequent registrations containing new bindings or modifications to existing bindings as necessary. MAY-38: When a client sends a REGISTER request, it **MAY** suggest an expiration interval that indicates how long the client would like the registration to be valid. MAY-39: It **MAY** combine several updates into one REGISTER request. MAY-40: If the response for a REGISTER request contains a Date header field, the client **MAY** use this header field to learn the current time in order to set any internal clocks. MAY-41: SIP UAs **MAY** listen to that address and use it to become aware of the location of other local users (see [33]); however, they do not respond to the request. MAY-42: If a UA receives a 423 (Interval Too Brief) response, it **MAY** retry the registration after making the expiration interval of all contact addresses in the REGISTER request equal to or greater than the expiration interval within the Min-Expires header field of the 423 (Interval Too Brief) response. MAY-43: A registrar **MAY** redirect REGISTER requests as appropriate. MAY-44: If no authentication mechanism is available, the registrar **MAY** take the From address as the asserted identity of the originator of the request. MAY-45: The registrar **MAY** choose an expiration less than the requested expiration interval. MAY-46: If and only if the requested expiration interval is greater than zero AND smaller than one hour AND less than a registrar-configured minimum, the registrar **MAY** reject the registration with a response of 423 (Interval Too Brief). MAY-47: Alternatively, a server receiving an OPTIONS request with a Max- Forwards header field value of 0 **MAY** respond to the request regardless of the Request-URI. MAY-48: An OPTIONS request **MAY** be sent as part of an established dialog to query the peer on capabilities that may be utilized later in the dialog. MAY-49: A Contact header field **MAY** be present in an OPTIONS. MAY-50: Contact header fields **MAY** be present in a 200 (OK) response and have the same semantics as in a 3xx response. MAY-51: A Warning header field **MAY** be present. MAY-52: A message body **MAY** be sent, the type of which is determined by the Accept header field in the OPTIONS request (application/sdp is the default if the Accept header field is not present). MAY-53: Extensions **MAY** define other means for creating dialogs. MAY-54: Once a dialog has been established between two UAs, either of them **MAY** initiate new transactions as needed within the dialog. MAY-55: Requests within a dialog **MAY** contain Record-Route and Contact header fields. MAY-56: Based on the To tag, the UAS **MAY** either accept or reject the request. MAY-57: An Accept (Section 20.1) header field **MAY** be present in the INVITE. MAY-58: The UAC **MAY** add an Expires header field (Section 20.19) to limit the validity of the invitation. MAY-59: A UAC **MAY** also find it useful to add, among others, Subject (Section 20.36), Organization (Section 20.25) and User-Agent (Section 20.41) header fields. MAY-60: The UAC **MAY** choose to add a message body to the INVITE. MAY-61: That same exact answer **MAY** also be placed in any provisional responses sent prior to the answer. MAY-62: o After having sent or received an answer to the first offer, the UAC **MAY** generate subsequent offers in requests based on rules specified for that method, but only if it has received answers to any previous offers, and has not sent any offers to which it hasn't gotten an answer. MAY-63: Depending on the status code of the 3xx response (see Section 21.3), the UAC **MAY** choose to try those new addresses. MAY-64: If desired, the UAS **MAY** use identifiers within the session description to detect this duplication. MAY-65: If the user is already a member of the session, and the session parameters contained in the session description have not changed, the UAS **MAY** silently accept the INVITE (that is, send a 2xx response without prompting the user). MAY-66: A UAS **MAY** send as many provisional responses as it likes. MAY-67: A 2xx response to an INVITE SHOULD contain the Allow header field and the Supported header field, and **MAY** contain the Accept header field. MAY-68: Of course, a UAC **MAY**. MAY-69: A UAC **MAY** choose not to add an Alert-Info header field or a body with Content-Disposition "alert" to re-INVITEs because UASs do not typically alert the user upon reception of a re-INVITE. MAY-70: However, a UA **MAY** initiate a regular transaction while an INVITE transaction is in progress. MAY-71: A UA **MAY** also initiate an INVITE transaction while a regular transaction is in progress. MAY-72: A UAS **MAY** choose not to generate 180 (Ringing) responses for a re- INVITE because UACs do not typically render this information to the user. MAY-73: For the same reason, UASs **MAY** choose not to use an Alert-Info header field or a body with Content-Disposition "alert" in responses to a re-INVITE. MAY-74: The caller's UA **MAY** send a BYE for either confirmed or early dialogs, and the callee's UA MAY send a BYE on confirmed dialogs, but MUST NOT send a BYE on early dialogs. MAY-75: The caller's UA MAY send a BYE for either confirmed or early dialogs, and the callee's UA **MAY** send a BYE on confirmed dialogs, but MUST NOT send a BYE on early dialogs. MAY-76: The UAC **MAY** continue with the sessions established by any 2xx responses, or MAY terminate them with BYE. MAY-77: The UAC MAY continue with the sessions established by any 2xx responses, or **MAY** terminate them with BYE. MAY-78: The element **MAY** respond with any. MAY-79: A stateful proxy **MAY** choose to "fork" a request, routing it to multiple destinations. MAY-80: In some circumstances, a proxy **MAY** forward requests using stateful transports (such as TCP) without being transaction-stateful. MAY-81: For instance, a proxy **MAY** forward a request from one TCP connection to another transaction statelessly as long as it places enough information in the message to be able to forward the response down the same connection the request arrived on. MAY-82: A stateful proxy **MAY** transition to stateless operation at any time during the processing of a request, so long as it did not do anything that would otherwise prevent it from being stateless initially (forking, for example, or generation of a 100 response). MAY-83: If the request was for OPTIONS, the element **MAY** act as the final recipient and respond per Section 11. MAY-84: An element **MAY** check for forwarding loops before forwarding a request. MAY-85: To determine if the request has looped, the element **MAY** perform the branch parameter calculation described in Step 8 of Section 16.6 on this message and compare it to the parameter received in that Via header field. MAY-86: If a loop is detected, the element **MAY** return a 482 (Loop Detected) response. MAY-87: If the target set for the request has not been predetermined as described above, this implies that the element is responsible for the domain in the Request-URI, and the element **MAY** use whatever mechanism it desires to determine where to send the request. MAY-88: Any information in or about the request or the current environment of the element **MAY** be used in the construction of the target set. MAY-89: If the Request-URI of the original request indicates a resource this proxy is responsible for, the proxy **MAY** continue to add targets to the set after beginning Request Forwarding. MAY-90: It **MAY** use any information obtained during that processing to determine new targets. MAY-91: As soon as the target set is non-empty, a proxy **MAY** begin forwarding the request. MAY-92: A stateful proxy **MAY** process the set in any order. MAY-93: It **MAY** process multiple targets serially, allowing each client transaction to complete before starting the next. MAY-94: It **MAY** start client transactions with every target in parallel. MAY-95: It also **MAY** arbitrarily divide the set into groups, processing the groups serially and processing the targets in each group in parallel. MAY-96: A proxy **MAY** insert a Record-Route header field value into any request. MAY-97: This URI **MAY** be different for each destination the request is forwarded to. MAY-98: The proxy **MAY** include parameters in the Record-Route header field value. MAY-99: A dialog-stateful proxy, for example, **MAY** refuse to accept future requests with that value in the Request-URI after the dialog has terminated. MAY-100: Non-dialog- stateful proxies, of course, have no concept of when the dialog has terminated, but they **MAY** encode enough information in the value to compare it against the dialog identifier of future requests and MAY reject requests not matching that information. MAY-101: Non-dialog- stateful proxies, of course, have no concept of when the dialog has terminated, but they MAY encode enough information in the value to compare it against the dialog identifier of future requests and **MAY** reject requests not matching that information. MAY-102: INVITE is the only such request in this specification, but extensions to the protocol **MAY** define others. MAY-103: The proxy **MAY** add any other appropriate header fields to the copy at this point. MAY-104: A proxy **MAY** have a local policy that mandates that a request visit a specific set of proxies before being delivered to the destination. MAY-105: Otherwise, this approach **MAY** be used, but the Route insertion mechanism above is preferred for its robustness, flexibility, generality and consistency of operation. MAY-106: The proxy **MAY** have a local policy to send the request to a specific IP address, port, and transport, independent of the values of the Route and Request-URI. MAY-107: The timer **MAY** be reset to a different value, but this value MUST be greater than 3 minutes. MAY-108: The proxy **MAY** select any response within that chosen class. MAY-109: If the selected response contains a Record-Route header field value originally provided by this proxy, the proxy **MAY** choose to rewrite the value before forwarding the response. MAY-110: After performing the processing described in steps "Aggregate Authorization Header Field Values" through "Record-Route", the proxy **MAY** perform any feature specific manipulations on the selected response. MAY-111: A stateful proxy **MAY** generate a CANCEL to any other request it has generated at any time (subject to receiving a provisional response to that request as described in section 9.1). MAY-112: A stateful proxy **MAY** generate CANCEL requests for pending INVITE client transactions based on the period specified in the INVITE's Expires header field elapsing. MAY-113: The stateless proxy **MAY** use any technique it likes to guarantee uniqueness of its branch IDs across transactions. MAY-114: Elements **MAY** (though it is NOT RECOMMENDED) use smaller values of T1 within closed, private networks that do not permit general Internet connection. MAY-115: T1 **MAY** be chosen larger, and this is RECOMMENDED if it is known in advance (such as on high latency access links) that the RTT is larger. MAY-116: Although any request **MAY** contain a body, a body in an ACK is special since the request cannot be rejected if the body is not understood. MAY-117: If it was, the body in the ACK **MAY** be any type listed in the Accept header field in the 415. MAY-118: The server transaction MUST generate a 100 (Trying) response unless it knows that the TU will generate a provisional or final response within 200 ms, in which case it **MAY** generate a 100 (Trying) response. MAY-119: The 100 (Trying) response is constructed according to the procedures in Section 8.2.6, except that the insertion of tags in the To header field of the response (when none was present in the request) is downgraded from **MAY** to SHOULD NOT. MAY-120: SIP elements **MAY** implement other protocols. MAY-121: If a request is destined to an IP address, port, and transport to which an existing connection is open, it is RECOMMENDED that this connection be used to send the request, but another connection **MAY** be opened and used. MAY-122: The userinfo part of a URI is optional and **MAY** be absent when the. MAY-123: If the host being addressed can process telephone numbers, for instance, an Internet telephony gateway, a telephone- subscriber field defined in RFC 2806 [9] **MAY** be used to populate the user field. MAY-124: Implementations not wishing to give special significance to the password portion of the field **MAY** simply treat "user:password" as a single string. MAY-125: Even without this parameter, recipients of SIP and SIPS URIs **MAY** interpret the pre-@ part as a telephone number if local restrictions on the name space for user name allow it. MAY-126: "Optional" means that an element **MAY** include the header field in a request or response, and a UA MAY ignore the header field if present in the request or response (The exception to this rule is the Require header field discussed in 20.32). MAY-127: "Optional" means that an element MAY include the header field in a request or response, and a UA **MAY** ignore the header field if present in the request or response (The exception to this rule is the Require header field discussed in 20.32). MAY-128: A UAS **MAY** include this header field in a 2xx response to a request that was successfully authenticated using digest based on the Authorization header field. MAY-129: Clients **MAY** apply content encodings to the body in requests. MAY-130: A server **MAY** apply content encodings to the bodies in responses. MAY-131: A UAC **MAY** treat a SIP or SIPS URI in an Error-Info header field as if it were a Contact in a redirect and generate a new INVITE, resulting in a recorded announcement session being established. MAY-132: A non-SIP URI **MAY** be rendered to the user. MAY-133: The field **MAY** be used by client software to filter calls. MAY-134: For example, the URI **MAY** be used to return missed calls or unestablished sessions. MAY-135: Provisional (1xx) responses **MAY** contain message bodies, including session descriptions. MAY-136: This response **MAY** be used to initiate local ringback. MAY-137: A server **MAY** use this status code to indicate that the call is being forwarded to a different set of destinations. MAY-138: The reason phrase **MAY** give further details about the status of the call, for example, "5 calls queued; expected waiting time is 15 minutes". MAY-139: The server **MAY** issue several 182 (Queued) responses to update the caller about the status of the queued call. MAY-140: The Reason-Phrase, header fields, or message body **MAY** be used to convey more details about the call progress. MAY-141: The response **MAY** include a message body containing a list of resource characteristics and location(s) from which the user or UA can choose the one most appropriate, if allowed by the Accept request header field. MAY-142: Unlike HTTP, the SIP response **MAY** contain several Contact fields or a list of addresses in a Contact field. MAY-143: UAs **MAY** use the Contact header field value for automatic redirection or MAY ask the user to confirm a choice. MAY-144: UAs MAY use the Contact header field value for automatic redirection or **MAY** ask the user to confirm a choice. MAY-145: Both proxies and UAs **MAY** cache this URI for the duration of the expiration time. MAY-146: If the URI cached from the Contact header field fails, the Request- URI from the redirected request **MAY** be tried again a single time. MAY-147: The client **MAY** repeat the request without modifications at any later time. MAY-148: The server **MAY** close the connection to prevent the client from continuing the request. MAY-149: If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client **MAY** try again. MAY-150: The response **MAY** indicate a better time to call in the Retry-After header field. MAY-151: Status 486 (Busy Here) **MAY** be used to more precisely indicate a particular reason for the call failure. MAY-152: The response **MAY** contain a listing of possible unambiguous addresses in Contact header fields. MAY-153: The response **MAY** indicate a better time to call in the Retry-After header field. MAY-154: A message body containing a description of media capabilities **MAY** be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request. MAY-155: This response **MAY** have a single body containing an appropriate public key that should be used to encrypt MIME bodies sent to this UA. MAY-156: The client **MAY** display the specific error condition and MAY retry the request after several seconds. MAY-157: The client MAY display the specific error condition and **MAY** retry the request after several seconds. MAY-158: If the condition is temporary, the server **MAY** indicate when the client may retry the request using the Retry-After header field. MAY-159: The server **MAY** indicate when the client should retry the request in a Retry-After header field. MAY-160: Servers **MAY** refuse the connection or drop the request instead of responding with 503 (Service Unavailable). MAY-161: The response **MAY** indicate a better time to call in the Retry-After header field. MAY-162: The response **MAY** indicate a better time to call in the Retry-After header field. MAY-163: The 606 (Not Acceptable) response **MAY** contain a list of reasons in a Warning header field describing why the session described cannot be supported. MAY-164: A message body containing a description of media capabilities **MAY** be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request. MAY-165: Any time that a proxy server or UA receives a request (with the exceptions given in Section 22.1), it **MAY** challenge the initiator of the request to provide assurance of its identity. MAY-166: Additionally, registrars and redirect servers **MAY** make use of 401 (Unauthorized) responses for authentication, but proxies MUST NOT, and instead MAY use the 407 (Proxy Authentication Required). MAY-167: Additionally, registrars and redirect servers MAY make use of 401 (Unauthorized) responses for authentication, but proxies MUST NOT, and instead **MAY** use the 407 (Proxy Authentication Required). MAY-168: If a server does not require authentication for a particular request, it **MAY** accept a default username, "anonymous", which has no password (password of ""). MAY-169: Similarly, UACs representing many users, such as PSTN gateways, **MAY** have their own device-specific username and password, rather than accounts for particular users, for their realm. MAY-170: When a UAS receives a request from a UAC, the UAS **MAY** authenticate the originator before the request is processed. MAY-171: UAs **MAY** cache credentials in any way they would like. MAY-172: If no credentials for a realm can be located, UACs **MAY** attempt to retry the request with a username of "anonymous" and no password (a password of ""). MAY-173: Once credentials have been located, any UA that wishes to authenticate itself with a UAS or registrar -- usually, but not necessarily, after receiving a 401 (Unauthorized) response -- **MAY** do so by including an Authorization header field with the request. MAY-174: Similarly, when a UAC sends a request to a proxy server, the proxy server **MAY** authenticate the originator before the request is processed. MAY-175: If no credentials for a realm can be located, UACs **MAY** attempt to retry the request with a username of "anonymous" and no password (a password of ""). MAY-176: These credentials MUST NOT be cached across dialogs; however, if a UA is configured with the realm of its local outbound proxy, when one exists, then the UA **MAY** cache. MAY-177: Any UA that wishes to authenticate itself to a proxy server -- usually, but not necessarily, after receiving a 407 (Proxy Authentication Required) response -- **MAY** do so by including a Proxy- Authorization header field value with the request. MAY-178: When resubmitting its request in response to a 401 (Unauthorized) or 407 (Proxy Authentication Required) that contains multiple challenges, a UAC **MAY** include an Authorization value for each WWW- Authenticate value and a Proxy-Authorization value for each Proxy- Authenticate value for which the UAC wishes to supply a credential. MAY-179: When it retries a request, a UAC **MAY** therefore supply multiple credentials in Authorization or Proxy-Authorization header fields with the same "realm" parameter value. MAY-180: Therefore, in SIP, a server **MAY** check that the Request-URI in the Authorization header field value corresponds to a user for whom the server is willing to accept forwarded or direct requests, but it is not necessarily a failure if the two fields are not equivalent. MAY-181: As an alternative, users **MAY** create self- signed certificates. MAY-182: A user agent that receives such a response when S/MIME is sent SHOULD notify its user that the remote device does not support S/MIME, and it **MAY** subsequently resend the request without S/MIME, if appropriate; however, this 415 response may constitute a downgrade attack. MAY-183: UACs **MAY** send an initial request such as an OPTIONS message with a CMS detached signature in order to solicit the certificate of the remote side (the signature SHOULD be over a "message/sip" body of the type described in Section 23.4). MAY-184: Note especially that senders **MAY** use the "preferSignedData". MAY-185: All other signature and encryption algorithms **MAY** be supported. MAY-186: If an integrity violation in a message is detected by its recipient, the message **MAY** be rejected with a 403 (Forbidden) response if it is a request, or any existing dialog MAY be terminated. MAY-187: If an integrity violation in a message is detected by its recipient, the message MAY be rejected with a 403 (Forbidden) response if it is a request, or any existing dialog **MAY** be terminated. MAY-188: A recipient **MAY** replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream. MAY-189: The backslash character ("\") **MAY** be used as a single-character quoting mechanism only within quoted-string and comment constructs. MAY-190: Implementers **MAY** also support any other ciphersuite. MAY-191: It is strongly RECOMMENDED that UAs be capable initiating TLS; UAs **MAY** also be capable of acting as a TLS server. MAY-192: UAs **MAY** have certificates of their own for mutual authentication with TLS, but no provisions are set forth in this document for their use. MAY-193: Proxy servers, redirect servers, registrars, and UAs **MAY** also implement IPSec or other lower-layer security protocols. MAY-194: In some architectures, UASs **MAY** receive requests over such TLS connections as well. MAY-195: UAs **MAY** support the signing and encrypting of MIME bodies, and transference of credentials with S/MIME as described in Section 23. MAY-196: A UA **MAY** hold root certificates specifically for validating S/MIME certificates. MAY-197: While implementers and network administrators **MAY** follow the normative guidelines given in the remainder of this section, these are provided only as example implementations. MAY-198: The proxy server that handles inbound requests for an administrative domain **MAY** also act as a local outbound proxy; for simplicity's sake we'll assume this to be the case for atlanta.com (otherwise the user agent would initiate a new TLS connection to a separate server at this point). MAY-199: The biloxi proxy **MAY** have a strict security policy that requires it to reject requests that do not match the administrative domain from which they have been proxied. MAY-200: The biloxi proxy **MAY** also have a strict policy that precludes it from even bothering to challenge requests that do not have biloxi.com in the "domainname" portion of the From header field - it treats these users as unauthenticated. MAY-201: Recipients **MAY** also inspect the Via header chain in order to double-check whether or not TLS was used for the entire request path until the local administrative domain was reached. MAY-202: As a further measure to prevent downgrade attacks, entities that accept only SIPS requests **MAY** also refuse connections on insecure ports. MAY-203: Thus it **MAY** be desirable for privacy reasons to create a To header field that differs from the Request-URI. MAY-204: The name **MAY** be of any length, but SHOULD be no more than twenty characters long. MAY-205: Some common and widely used header fields **MAY** be assigned one-letter compact forms (Section 7.3.3). OPTIONAL Requirements: O-1: In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "**OPTIONAL**" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations. O-2: content-disposition: Session;HANDLING=**OPTIONAL**.