ctly to the called party. However, the presence of Record-Route header fields in an earlier request or default proxy routing configuration in a user agent may override that behavior. When a Contact URI is used in a Request-URI, all URI parameters are allowed with the excep- tion of the method parameter, which is ignored. Contact header fields must be present in INVITE requests and 200 OK responses to invitations. In some cases, the Contact URI may not resolve directly to the user agent. For example, a UA behind a firewall ALG will need to use a Contact URI that resolves to the firewall ALG address. Otherwise, the use of the user agent's URI will result in the call failing because of the firewall blocking any direct routed SIP requests. Contact header fields may also be present in 1xx, 2xx, 3xx, and 485 responses. Only in a REGISTER request, a special Contact:*, along with an Expires: 0, header field is used to remove all existing registrations. Examples of Contact header fields in registrations are shown in Table 4.3. Otherwise, wild carding is not allowed. A Contact header field may contain a display name that can be in quotes. If a display name is present, the URI will be enclosed in < >. If any header field parameters are present, the URI will also be enclosed in along with any URI SIP Header Fields parameters, with the header field parameters outside the < >, even if no display name is present. There are three additional parameters defined for use in Contact header fields: q, action, and expires. They are placed at the end of the URI and separated by semicolons. The q value parameter is used to indicate relative pref- erence, which is represented by a decimal number in the range 0 to 1. The q value is not a probability, and there is no requirement that the q values for a given list of Contacts add up to 1. (The action parameter defined in RFC 2543 has been deprecated and is not used in RFC 3261. It was only used in reg- istration Contact header fields, and is used to specify proxy or redirect operation by the