All Downloads are FREE. Search and download functionalities are using the official Maven repository.

javax.sip.message.Response Maven / Gradle / Ivy

There is a newer version: 1.3.0-91
Show newest version
/**
 * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 * Unpublished - rights reserved under the Copyright Laws of the United States.
 * Copyright ? 2003 Sun Microsystems, Inc. All rights reserved.
 * Copyright ? 2005 BEA Systems, Inc. All rights reserved.
 *
 * Use is subject to license terms.
 *
 * This distribution may include materials developed by third parties.
 *
 * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 *
 * Module Name   : JSIP Specification
 * File Name     : Response.java
 * Author        : Phelim O'Doherty
 *
 *  HISTORY
 *  Version   Date      Author              Comments
 *  1.1     08/10/2002  Phelim O'Doherty    Initial version
 *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 */
package javax.sip.message;

import java.text.ParseException;

/**
 * A Response message is sent by a recipient of Request once it has received
 * and interpreted the Request. Responses are contain a Status-Code and a
 * Reason-Phrase, as well as Headers and a possible message body.
 * 

* The Status-Code is a 3-digit integer result code that indicates the * outcome of the attempt to understand and satisfy the Request. The * Reason-Phrase is intended to give a short textual description of the * Status-Code. The Status-Code is intended for use by automata, whereas * the Reason-Phrase is intended for the human user. The client is not * required to examine or display the Reason-Phrase. *

* RFC3261 defines status codes in the following classes: *

    *
  • 1xx: Provisional -- request received, continuing to process the request; * Provisional responses, also known as informational responses, indicate that * the server contacted is performing some further action and does not yet have * a definitive response. *
      *
    • This specification also supports the delivery of reliable provisional responses as defined in * RFC 3262. When * the UAC creates a new request, it can insist on reliable delivery of * provisional responses for that request. To do that, it inserts a Require * header field with the option tag 100rel into the request. A Require header * with the value 100rel MUST NOT be present in any requests excepting INVITE, * although other extensions to SIP may allow its usage with other request * methods. If the UAC does not wish to insist on usage of reliable provisional * responses, but merely indicate that it supports them if the UAS needs to send * one, a Supported header MUST be included in the request with the option tag * 100rel. The UAC SHOULD include this in all INVITE requests. *

      * A UAS MAY send any non-100 provisional response to INVITE reliably, so long * as the initial INVITE request (the request whose provisional response is * being sent reliably) contained a Supported header field with the option tag * 100rel. The provisional response to be sent reliably is * constructed by the UAS and MUST contain a Require header field containing * the option tag 100rel, and MUST include an RSeq header field. * Retransmissions of the reliable provisional response cease when a * matching PRACK is received by the UA core. PRACK is like any other request * within a dialog, and is treated likewise. A matching PRACK is defined as one * within the same dialog as the response, and whose method, CSeq-num, and * RSeq-num in the RAck header field match, respectively, the method and * sequence number from the CSeq and the sequence number from the RSeq of the * reliable provisional response. *

    *
  • 2xx: Success -- the action was successfully received, understood, and * accepted. *
  • 3xx: Redirection -- further action needs to be taken in order to * complete the request; 3xx responses give information about the user's new * location, or about alternative services that might be able to satisfy the call. *
  • 4xx: Client Error -- the request contains bad syntax or cannot be * fulfilled at this server; 4xx responses are definite failure responses from * a particular server. The client SHOULD NOT retry the same request without * modification. However, the same request to a different server might be * successful. *
  • 5xx: Server Error -- the server failed to fulfill an apparently valid * request; 5xx responses are failure responses given when a server itself has * erred. *
  • 6xx: Global Failure -- the request cannot be fulfilled at any server; * 6xx responses indicate that a server has definitive information about a * particular user, not just the particular instance indicated in the Request-URI. *
* SIP status codes are extensible. The response codes are consistent with, and * extend, HTTP/1.1 response codes. Not all HTTP/1.1 response codes are * appropriate, and only those that are appropriate are given here. Other * HTTP/1.1 response codes SHOULD NOT be used. Also, SIP defines a new class, * 6xx. *

* SIP applications are not required to understand the meaning of all * registered response codes, though such understanding is obviously desirable. * However, applications must understand the class of any status code, as * indicated by the first digit and outlined above. Applications treat any * unrecognized status code as being equivalent to the x00 status code of that * class, with the exception that an unrecognized status code must not be * cached. For example, if a client receives an unrecognized status code of 431, * it can safely assume that there was something wrong with its request and * treat the Response as if it had received a BAD_REQUEST(400) status code. In * such cases, user agents should present to the user the message body returned * with the Response, since that message body is likely to include * human-readable information which will explain the unusual status. *

* This specification supports the response codes defined in RFC3261 and also the response * code extensions for the event notification framework and PUBLISH, documented in * RFC3265 and * RFC3909, these are * highlighted in italic. Class status codes (x00, i.e. 100) are are highlighted * in bold. *

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ClassCode
PROVISIONAL (1xx) *
  • TRYING - 100
  • *
  • RINGING - 180
  • *
  • CALL_IS_BEING_FORWARDED - 181
  • *
  • QUEUED - 182
  • *
  • SESSION_PROGRESS - 183
  • *
    SUCCESS (2xx) *
  • OK - 200
  • *
  • ACCEPTED - 202 (Extension RFC3265)
  • *
    REDIRECTION (3xx) *
  • MULTIPLE_CHOICES - 300
  • *
  • MOVED_PERMANENTLY - 301
  • *
  • MOVED_TEMPORARILY - 302
  • *
  • USE_PROXY - 305
  • *
  • ALTERNATIVE_SERVICE - 380
  • *
    CLIENT_ERROR (4xx) *
  • BAD_REQUEST - 400
  • *
  • UNAUTHORIZED - 401
  • *
  • PAYMENT_REQUIRED - 402
  • *
  • FORBIDDEN - 403
  • *
  • NOT_FOUND - 404
  • *
  • METHOD_NOT_ALLOWED - 405
  • *
  • NOT_ACCEPTABLE - 406
  • *
  • PROXY_AUTHENTICATION_REQUIRED - 407
  • *
  • REQUEST_TIMEOUT - 408
  • *
  • GONE - 410
  • *
  • CONDITIONAL_REQUEST_FAILED - 412 (Extension RFC3909) *
  • REQUEST_ENTITY_TOO_LARGE - 413 *
  • REQUEST_URI_TOO_LONG - 414 *
  • UNSUPPORTED_MEDIA_TYPE - 415
  • *
  • UNSUPPORTED_URI_SCHEME - 416 *
  • BAD_EXTENSION - 420
  • *
  • EXTENSION_REQUIRED - 421 *
  • INTERVAL_TOO_BRIEF - 423 *
  • TEMPORARILY_UNAVAILABLE - 480
  • *
  • CALL_OR_TRANSACTION_DOES_NOT_EXIST - 481
  • *
  • LOOP_DETECTED - 482
  • *
  • TOO_MANY_HOPS - 483
  • *
  • ADDRESS_INCOMPLETE - 484
  • *
  • AMBIGUOUS - 485
  • *
  • BUSY_HERE - 486
  • *
  • REQUEST_TERMINATED - 487 *
  • NOT_ACCEPTABLE_HERE - 488 *
  • BAD EVENT - 489 (Extension RFC3265)
  • *
  • REQUEST_PENDING - 491 *
  • UNDECIPHERABLE - 493 *
  • SERVER_ERROR (5xx) *
  • SERVER_INTERNAL_ERROR - 500
  • *
  • NOT_IMPLEMENTED - 501
  • *
  • BAD_GATEWAY - 502
  • *
  • SERVICE_UNAVAILABLE - 503
  • *
  • SERVER_TIMEOUT - 504
  • *
  • VERSION_NOT_SUPPORTED - 505
  • *
  • MESSAGE_TOO_LARGE - 513 *
  • GLOBAL_ERROR (6xx) *
  • BUSY_EVERYWHERE - 600
  • *
  • DECLINE - 603
  • *
  • DOES_NOT_EXIST_ANYWHERE - 604
  • *
  • SESSION_NOT_ACCEPTABLE - 606
  • *
    * * @author BEA Systems, NIST * @version 1.2 * */ public interface Response extends Message { /** * Sets the status-code of Response. The status-code is a 3-digit integer * result code that indicates the outcome of an attempt to understand and * satisfy a request. The Status-Code is intended for use by automata. * * @param statusCode the new integer value of the status code. * @throws ParseException which signals that an error has been reached * unexpectedly while parsing the statusCode value. */ public void setStatusCode(int statusCode) throws ParseException; /** * Gets the integer value of the status code of Response, which identifies * the outcome of the request to which this response is related. * * @return the integer status-code of this Response message. */ public int getStatusCode(); /** * Sets reason phrase of Response. The reason-phrase is intended to give a * short textual description of the status-code. The reason-phrase is * intended for the human user. A client is not required to examine or * display the reason-phrase. While RFC3261 suggests specific wording for * the reason phrase, implementations MAY choose other text. * * @param reasonPhrase the new string value of the reason phrase. * @throws ParseException which signals that an error has been reached * unexpectedly while parsing the reasonPhrase value. */ public void setReasonPhrase(String reasonPhrase) throws ParseException; /** * Gets the reason phrase of this Response message. * * @return the string value of the reason phrase of this Response message. */ public String getReasonPhrase(); // Response status codes /** * This response indicates that the request has been received by the * next-hop server and that some unspecified action is being taken on * behalf of this call (for example, a database is being consulted). This * response, like all other provisional responses, stops retransmissions of * an INVITE by a UAC. The 100 (Trying) response is different from other * provisional responses, in that it is never forwarded upstream by a * stateful proxy. */ public static final int TRYING = 100; /** * The User Agent receiving the INVITE is trying to alert the user. This * response MAY be used to initiate local ringback. */ public static final int RINGING = 180; /** * A server MAY use this status code to indicate that the call is being * forwarded to a different set of destinations. */ public static final int CALL_IS_BEING_FORWARDED = 181; /** * The called party is temporarily unavailable, but the server has decided * to queue the call rather than reject it. When the callee becomes * available, it will return the appropriate final status response. The * reason phrase MAY give further details about the status of the call, * for example, "5 calls queued; expected waiting time is 15 minutes". The * server MAY issue several 182 (Queued) responses to update the caller * about the status of the queued call. */ public static final int QUEUED = 182; /** * The 183 (Session Progress) response is used to convey information about * the progress of the call that is not otherwise classified. The * Reason-Phrase, header fields, or message body MAY be used to convey more * details about the call progress. */ public static final int SESSION_PROGRESS = 183; /** * The request has succeeded. The information returned with the response * depends on the method used in the request. */ public static final int OK = 200; /** * The Acceptable extension response code signifies that the request has * been accepted for processing, but the processing has not been completed. * The request might or might not eventually be acted upon, as it might be * disallowed when processing actually takes place. There is no facility * for re-sending a status code from an asynchronous operation such as this. * The 202 response is intentionally non-committal. Its purpose is to allow * a server to accept a request for some other process (perhaps a * batch-oriented process that is only run once per day) without requiring * that the user agent's connection to the server persist until the process * is completed. The entity returned with this response SHOULD include an * indication of the request's current status and either a pointer to a * status monitor or some estimate of when the user can expect the request * to be fulfilled. This response code is specific to the event notification * framework. */ public static final int ACCEPTED = 202; /** * The address in the request resolved to several choices, each with its * own specific location, and the user (or UA) can select a preferred * communication end point and redirect its request to that location. *

    * 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. * However, no MIME types have been defined for this message body. *

    * The choices SHOULD also be listed as Contact fields. Unlike HTTP, the * SIP response MAY contain several Contact fields or a list of addresses * in a Contact field. User Agents MAY use the Contact header field value * for automatic redirection or MAY ask the user to confirm a choice. * However, this specification does not define any standard for such * automatic selection. *

    * This status response is appropriate if the callee can be reached at * several different locations and the server cannot or prefers not to * proxy the request. */ public static final int MULTIPLE_CHOICES = 300; /** * 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. 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. */ public static final int MOVED_PERMANENTLY = 301; /** * The requesting client SHOULD retry the request at the new address(es) * given by the Contact header field. The Request-URI of the new request * uses the value of the Contact header field in the response. *

    * The duration of the validity of the Contact URI can be indicated through * an Expires header field or an expires parameter in the Contact header * field. Both proxies and User Agents MAY cache this URI for the duration * of the expiration time. If there is no explicit expiration time, the * address is only valid once for recursing, and MUST NOT be cached for * future transactions. *

    * If the URI cached from the Contact header field fails, the Request-URI * from the redirected request MAY be tried again a single time. The * temporary URI may have become out-of-date sooner than the expiration * time, and a new temporary URI may be available. */ public static final int MOVED_TEMPORARILY = 302; /** * The requested resource MUST be accessed through the proxy given by the * Contact field. The Contact field gives the URI of the proxy. The * recipient is expected to repeat this single request via the proxy. * 305 (Use Proxy) responses MUST only be generated by UASs. */ public static final int USE_PROXY = 305; /** * The call was not successful, but alternative services are possible. The * alternative services are described in the message body of the response. * Formats for such bodies are not defined here, and may be the subject of * future standardization. */ public static final int ALTERNATIVE_SERVICE = 380; /** * The request could not be understood due to malformed syntax. The * Reason-Phrase SHOULD identify the syntax problem in more detail, for * example, "Missing Call-ID header field". */ public static final int BAD_REQUEST = 400; /** * The request requires user authentication. This response is issued by * UASs and registrars, while 407 (Proxy Authentication Required) is used * by proxy servers. */ public static final int UNAUTHORIZED = 401; /** * Reserved for future use. */ public static final int PAYMENT_REQUIRED = 402; /** * The server understood the request, but is refusing to fulfill it. * Authorization will not help, and the request SHOULD NOT be repeated. */ public static final int FORBIDDEN = 403; /** * The server has definitive information that the user does not exist at * the domain specified in the Request-URI. This status is also returned * if the domain in the Request-URI does not match any of the domains * handled by the recipient of the request. */ public static final int NOT_FOUND = 404; /** * The method specified in the Request-Line is understood, but not allowed * for the address identified by the Request-URI. The response MUST include * an Allow header field containing a list of valid methods for the * indicated address */ public static final int METHOD_NOT_ALLOWED = 405; /** * The resource identified by the request is only capable of generating * response entities that have content characteristics not acceptable * according to the Accept header field sent in the request. */ public static final int NOT_ACCEPTABLE = 406; /** * This code is similar to 401 (Unauthorized), but indicates that the client * MUST first authenticate itself with the proxy. This status code can be * used for applications where access to the communication channel (for * example, a telephony gateway) rather than the callee requires * authentication. */ public static final int PROXY_AUTHENTICATION_REQUIRED = 407; /** * The server could not produce a response within a suitable amount of * time, for example, if it could not determine the location of the user * in time. The client MAY repeat the request without modifications at * any later time. */ public static final int REQUEST_TIMEOUT = 408; /** * The requested resource is no longer available at the server and no * forwarding address is known. This condition is expected to be considered * permanent. 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. */ public static final int GONE = 410; /** * The server is refusing to service the PUBLISH request because the * entity-tag in the SIP-If-Match header does not match with existing * event state. * * @since v1.2 */ public static final int CONDITIONAL_REQUEST_FAILED = 412; /** * The server is refusing to process a request because the request * entity-body is larger than the server is willing or able to process. The * server MAY close the connection to prevent the client from continuing * the request. 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. */ public static final int REQUEST_ENTITY_TOO_LARGE = 413; /** * The server is refusing to service the request because the Request-URI * is longer than the server is willing to interpret. */ public static final int REQUEST_URI_TOO_LONG = 414; /** * The server is refusing to service the request because the message body * of the request is in a format not supported by the server for the * requested method. 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. */ public static final int UNSUPPORTED_MEDIA_TYPE = 415; /** * The server cannot process the request because the scheme of the URI in * the Request-URI is unknown to the server. */ public static final int UNSUPPORTED_URI_SCHEME = 416; /** * The server did not understand the protocol extension specified in a * Proxy-Require or Require header field. The server MUST include a list of * the unsupported extensions in an Unsupported header field in the response. */ public static final int BAD_EXTENSION = 420; /** * The UAS needs a particular extension to process the request, but this * extension is not listed in a Supported header field in the request. * Responses with this status code MUST contain a Require header field * listing the required extensions. *

    * A UAS SHOULD NOT use this response unless it truly cannot provide any * useful service to the client. 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. */ public static final int EXTENSION_REQUIRED = 421; /** * The server is rejecting the request because the expiration time of the * resource refreshed by the request is too short. This response can be * used by a registrar to reject a registration whose Contact header field * expiration time was too small. */ public static final int INTERVAL_TOO_BRIEF = 423; /** * The callee's end system was contacted successfully but the callee is * currently unavailable (for example, is not logged in, logged in but in a * state that precludes communication with the callee, or has activated the * "do not disturb" feature). The response MAY indicate a better time to * call in the Retry-After header field. The user could also be available * elsewhere (unbeknownst to this server). The reason phrase SHOULD indicate * a more precise cause as to why the callee is unavailable. This value * SHOULD be settable by the UA. Status 486 (Busy Here) MAY be used to more * precisely indicate a particular reason for the call failure. *

    * This status is also returned by a redirect or proxy server that * recognizes the user identified by the Request-URI, but does not currently * have a valid forwarding location for that user. */ public static final int TEMPORARILY_UNAVAILABLE = 480; /** * This status indicates that the UAS received a request that does not * match any existing dialog or transaction. */ public static final int CALL_OR_TRANSACTION_DOES_NOT_EXIST = 481; /** * The server has detected a loop. */ public static final int LOOP_DETECTED = 482; /** * The server received a request that contains a Max-Forwards header field * with the value zero. */ public static final int TOO_MANY_HOPS = 483; /** * The server received a request with a Request-URI that was incomplete. * Additional information SHOULD be provided in the reason phrase. This * status code allows overlapped dialing. With overlapped dialing, the * client does not know the length of the dialing string. It sends strings * of increasing lengths, prompting the user for more input, until it no * longer receives a 484 (Address Incomplete) status response. */ public static final int ADDRESS_INCOMPLETE = 484; /** * The Request-URI was ambiguous. The response MAY contain a listing of * possible unambiguous addresses in Contact header fields. Revealing * alternatives can infringe on privacy of the user or the organization. * 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. Some email and voice mail systems provide this * functionality. A status code separate from 3xx is used since the * semantics are different: for 300, it is assumed that the same person or * service will be reached by the choices provided. While an automated * choice or sequential search makes sense for a 3xx response, user * intervention is required for a 485 (Ambiguous) response. */ public static final int AMBIGUOUS = 485; /** * The callee's end system was contacted successfully, but the callee is * currently not willing or able to take additional calls at this end * system. The response MAY indicate a better time to call in the Retry-After * header field. The user could also be available elsewhere, such as * through a voice mail service. Status 600 (Busy Everywhere) SHOULD be * used if the client knows that no other end system will be able to accept * this call. */ public static final int BUSY_HERE = 486; /** * The request was terminated by a BYE or CANCEL request. This response is * never returned for a CANCEL request itself. */ public static final int REQUEST_TERMINATED = 487; /** * The response has the same meaning as 606 (Not Acceptable), but only * applies to the specific resource addressed by the Request-URI and the * request may succeed elsewhere. 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. */ public static final int NOT_ACCEPTABLE_HERE = 488; /** * The Bad Event extension response code is used to indicate that the * server did not understand the event package specified in a "Event" * header field. This response code is specific to the event notification * framework. */ public static final int BAD_EVENT = 489; /** * The request was received by a UAS that had a pending request within * the same dialog. */ public static final int REQUEST_PENDING = 491; /** * The request was received by a UAS that contained an encrypted MIME body * for which the recipient does not possess or will not provide an * appropriate decryption key. This response MAY have a single body * containing an appropriate public key that should be used to encrypt MIME * bodies sent to this UA. */ public static final int UNDECIPHERABLE = 493; /** * The server encountered an unexpected condition that prevented it from * fulfilling the request. The client MAY display the specific error * condition and MAY retry the request after several seconds. If the * condition is temporary, the server MAY indicate when the client may * retry the request using the Retry-After header field. */ public static final int SERVER_INTERNAL_ERROR = 500; /** * The server does not support the functionality required to fulfill the * request. This is the appropriate response when a UAS does not recognize * the request method and is not capable of supporting it for any user. * Proxies forward all requests regardless of method. Note that a 405 * (Method Not Allowed) is sent when the server recognizes the request * method, but that method is not allowed or supported. */ public static final int NOT_IMPLEMENTED = 501; /** * The server, while acting as a gateway or proxy, received an invalid * response from the downstream server it accessed in attempting to * fulfill the request. */ public static final int BAD_GATEWAY = 502; /** * The server is temporarily unable to process the request due to a * temporary overloading or maintenance of the server. The server MAY * indicate when the client should retry the request in a Retry-After * header field. If no Retry-After is given, the client MUST act as if it * had received a 500 (Server Internal Error) response. *

    * A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD * attempt to forward the request to an alternate server. It SHOULD NOT * forward any other requests to that server for the duration specified * in the Retry-After header field, if present. *

    * Servers MAY refuse the connection or drop the request instead of * responding with 503 (Service Unavailable). */ public static final int SERVICE_UNAVAILABLE = 503; /** * The server did not receive a timely response from an external server * it accessed in attempting to process the request. 408 (Request Timeout) * should be used instead if there was no response within the * period specified in the Expires header field from the upstream server. */ public static final int SERVER_TIMEOUT = 504; /** * The server does not support, or refuses to support, the SIP protocol * version that was used in the request. The server is indicating that * it is unable or unwilling to complete the request using the same major * version as the client, other than with this error message. */ public static final int VERSION_NOT_SUPPORTED = 505; /** * The server was unable to process the request since the message length * exceeded its capabilities. */ public static final int MESSAGE_TOO_LARGE = 513; /** * The callee's end system was contacted successfully but the callee is * busy and does not wish to take the call at this time. The response * MAY indicate a better time to call in the Retry-After header field. * If the callee does not wish to reveal the reason for declining the call, * the callee uses status code 603 (Decline) instead. This status response * is returned only if the client knows that no other end point (such as a * voice mail system) will answer the request. Otherwise, 486 (Busy Here) * should be returned. */ public static final int BUSY_EVERYWHERE = 600; /** * The callee's machine was successfully contacted but the user explicitly * does not wish to or cannot participate. The response MAY indicate a * better time to call in the Retry-After header field. This status * response is returned only if the client knows that no other end point * will answer the request. */ public static final int DECLINE = 603; /** * The server has authoritative information that the user indicated in the * Request-URI does not exist anywhere. */ public static final int DOES_NOT_EXIST_ANYWHERE = 604; /** * The user's agent was contacted successfully but some aspects of the * session description such as the requested media, bandwidth, or addressing * style were not acceptable. A 606 (Not Acceptable) response means that * the user wishes to communicate, but cannot adequately support the * session described. The 606 (Not Acceptable) response MAY contain a list * of reasons in a Warning header field describing why the session described * cannot be supported. *

    * 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. *

    * It is hoped that negotiation will not frequently be needed, and when a * new user is being invited to join an already existing conference, * negotiation may not be possible. It is up to the invitation initiator to * decide whether or not to act on a 606 (Not Acceptable) response. *

    * This status response is returned only if the client knows that no other * end point will answer the request. This specification renames this * status code from NOT_ACCEPTABLE as in RFC3261 to SESSION_NOT_ACCEPTABLE * due to it conflict with 406 (Not Acceptable) defined in this interface. */ public static final int SESSION_NOT_ACCEPTABLE = 606; }





    © 2015 - 2024 Weber Informatics LLC | Privacy Policy