001: /**
002: * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
003: * Unpublished - rights reserved under the Copyright Laws of the United States.
004: * Copyright © 2003 Sun Microsystems, Inc. All rights reserved.
005: * Copyright © 2005 BEA Systems, Inc. All rights reserved.
006: *
007: * Use is subject to license terms.
008: *
009: * This distribution may include materials developed by third parties.
010: *
011: * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
012: *
013: * Module Name : JSIP Specification
014: * File Name : Request.java
015: * Author : Phelim O'Doherty
016: *
017: * HISTORY
018: * Version Date Author Comments
019: * 1.1 08/10/2002 Phelim O'Doherty Initial version
020: *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
021: */package javax.sip.message;
022:
023: import javax.sip.address.URI;
024: import java.text.ParseException;
025:
026: /**
027: * A SIP Request is a request from a client to a server. The following Requests
028: * method names are defined by <a href = "http://www.ietf.org/rfc/rfc3261.txt">
029: * RFC3261</a>:
030: * <ul>
031: * <li>ACK - confirms that client has received a final Response to an INVITE
032: * Request.
033: * <li>BYE - indicates to the server that client wishes to release the
034: * call leg.
035: * <li>CANCEL - cancels a pending User Agent Client Request.
036: * <li>INVITE - indicates that user or service is being invited to participate
037: * in a session.
038: * <li>OPTIONS - queries a server with regards to its capabilities.
039: * <li>REGISTER - registers contact information with a SIP server.
040: * </ul>
041: *
042: * This specifications also supports the following method name extensions, documented in
043: * the following standards track RFCs:
044: * <ul>
045: * <li> INFO - used to carry session related control information that is
046: * generated during a session. This functionality is defined in
047: * <a href = "http://www.ietf.org/rfc/rfc2976.txt">RFC2976</a>.
048: * <li> PRACK - similiar in operation to ACK, however specific to the
049: * reliability of provisional Responses. This functionality is defined in
050: * <a href = "http://www.ietf.org/rfc/rfc3262.txt">RFC3262</a>.
051: * <li> UPDATE - allows a client to update parameters of a session without
052: * impacting the state of a dialog. This functionality is defined in
053: * <a href = "http://www.ietf.org/rfc/rfc3311.txt">RFC3311</a>.
054: * <li> SUBSCRIBE - provides an extensible framework by which SIP nodes can
055: * request notification from remote nodes indicating that certain events have
056: * occurred. This functionality is defined in
057: * <a href = "http://www.ietf.org/rfc/rfc3265.txt">RFC3265</a>.
058: * <li> NOTIFY - provides an extensible framework by which SIP nodes can
059: * get notification from remote nodes indicating that certain events have
060: * occurred. This functionality is defined in
061: * <a href = "http://www.ietf.org/rfc/rfc3265.txt">RFC3265</a>.
062: * <li> MESSAGE - for sending instant messages using a metaphor similar to that
063: * of a two-way pager or SMS enabled handset. This functionality is defined in
064: * <a href = "http://www.ietf.org/rfc/rfc3428.txt">RFC3428</a>.
065: * <li> REFER - requests that the recipient REFER to a resource provided in
066: * the request. This functionality is defined in
067: * <a href = "http://www.ietf.org/rfc/rfc3515.txt">RFC3515</a>.
068: * <li> PUBLISH - for publishing event state. This functionality is defined in
069: * <a href = "http://www.ietf.org/rfc/rfc3903.txt">RFC3903</a>.
070: * </ul>
071: * A valid SIP request formulated by a User Agent Client MUST, at a minimum, contain the
072: * following header fields: To, From, CSeq, Call-ID, Max-Forwards, and Via; all
073: * of these header fields are mandatory in all SIP requests. These six header
074: * fields are the fundamental building blocks of a SIP message, as they jointly
075: * provide for most of the critical message routing services including the
076: * addressing of messages, the routing of responses, limiting message
077: * propagation, ordering of messages, and the unique identification of
078: * transactions. These header fields are in addition to the mandatory request
079: * line, which contains the method, Request-URI, and SIP version.
080: *
081: * @author BEA Systems, NIST
082: * @version 1.2
083: */
084:
085: public interface Request extends Message {
086:
087: /**
088: * Gets method string of this Request message.
089: *
090: * @return the method of this Request message.
091: */
092: public String getMethod();
093:
094: /**
095: * Sets the method of Request to the newly supplied value. The standard
096: * RFC3261 methods are REGISTER for registering contact information, INVITE,
097: * ACK, and CANCEL for setting up sessions, BYE for terminating sessions, and
098: * OPTIONS for querying servers about their capabilities.
099: *
100: * @param method - the new string value of the method of Request
101: * @throws ParseException which signals that an error has been reached
102: * unexpectedly while parsing the method value.
103: */
104: public void setMethod(String method) throws ParseException;
105:
106: /**
107: * Gets the URI Object identifying the request URI of this Request, which
108: * indicates the user or service to which this request is addressed.
109: *
110: * @return Request URI of Request
111: */
112: public URI getRequestURI();
113:
114: /**
115: * Sets the RequestURI of Request. The Request-URI is a SIP or SIPS URI
116: * or a general URI. It indicates the user or service to which this request
117: * is being addressed. SIP elements MAY support Request-URIs with schemes
118: * other than "sip" and "sips", for example the "tel" URI scheme. SIP
119: * elements MAY translate non-SIP URIs using any mechanism at their disposal,
120: * resulting in SIP URI, SIPS URI, or some other scheme.
121: *
122: * @param requestURI - the new Request URI of this request message
123: */
124: public void setRequestURI(URI requestURI);
125:
126: // Request Constants
127:
128: /**
129: * An ACK is used to acknowledge the successful receipt
130: * of a message in a transaction. It is also used to illustrate the
131: * successful setup of a dialog via the a three-way handshake between an
132: * UAC and an UAS for an Invite transaction.
133: */
134: public static final String ACK = "ACK";
135:
136: /**
137: * The BYE request is used to terminate a specific
138: * session or attempted session. When a BYE is received on a dialog, any
139: * session associated with that dialog SHOULD terminate. A User Agent MUST
140: * NOT send a BYE outside of a dialog. The caller's User Agent MAY send a
141: * BYE for either confirmed or early dialogs, and the callee's User Agent
142: * MAY send a BYE on confirmed dialogs, but MUST NOT send a BYE on early
143: * dialogs. However, the callee's User Agent MUST NOT send a BYE on a
144: * confirmed dialog until it has received an ACK for its 2xx response or
145: * until the server transaction times out. If no SIP extensions have defined
146: * other application layer states associated with the dialog, the BYE also
147: * terminates the dialog.
148: */
149: public static final String BYE = "BYE";
150:
151: /**
152: * The CANCEL request is used to cancel a previous
153: * request sent by a client. Specifically, it asks the UAS to cease
154: * processing the request and to generate an error response to that request.
155: * CANCEL has no effect on a request to which a UAS has already given a
156: * final response. Because of this, it is most useful to CANCEL requests to
157: * which it can take a server long time to respond. For this reason, CANCEL
158: * is best for INVITE requests, which can take a long time to generate a
159: * response.
160: */
161: public static final String CANCEL = "CANCEL";
162:
163: /**
164: * The INVITE method is used by an user agent client that desires to
165: * initiate a session, session examples include, audio, video, or a game. The
166: * INVITE request asks a server to establish a session. This request may be
167: * forwarded by proxies, eventually arriving at one or more UAS's that can
168: * potentially accept the invitation. These UAS's will frequently need to
169: * query the user about whether to accept the invitation. After some time,
170: * those UAS's can accept the invitation (meaning the session is to be
171: * established) by sending a 2xx response. If the invitation is not
172: * accepted, a 3xx, 4xx, 5xx or 6xx response is sent, depending on the
173: * reason for the rejection. Before sending a final response, the UAS can
174: * also send provisional responses (1xx) to advise the UAC of progress in
175: * contacting the called user.
176: */
177: public static final String INVITE = "INVITE";
178:
179: /**
180: * The OPTIONS method allows a User Agent to query
181: * another User Agent or a proxy server as to its capabilities. This allows
182: * a client to discover information about the supported methods, content
183: * types, extensions, codecs, etc. without "ringing" the other party. For
184: * example, before a client inserts a Require header field into an INVITE
185: * listing an option that it is not certain the destination UAS supports,
186: * the client can query the destination UAS with an OPTIONS to see if this
187: * option is returned in a Supported header field. All User Agents MUST
188: * support the OPTIONS method.
189: */
190: public static final String OPTIONS = "OPTIONS";
191:
192: /**
193: * The REGISTER method requests the addition,
194: * removal, and query of bindings. A REGISTER request can add a new binding
195: * between an address-of-record and one or more contact addresses.
196: * Registration on behalf of a particular address-of-record can be performed
197: * by a suitably authorized third party. A client can also remove previous
198: * bindings or query to determine which bindings are currently in place for
199: * an address-of-record. A REGISTER request does not establish a dialog.
200: * Registration entails sending a REGISTER request to a special type of UAS
201: * known as a registrar. A registrar acts as the front end to the location
202: * service for a domain, reading and writing mappings based on the contents
203: * of REGISTER requests. This location service is then typically consulted
204: * by a proxy server that is responsible for routing requests for that domain.
205: */
206: public static final String REGISTER = "REGISTER";
207:
208: /**
209: * Notify is an extension method that informs subscribers of changes in state
210: * to which the subscriber has a subscription. Subscriptions are typically
211: * put in place using the SUBSCRIBE method; however, it is possible that
212: * other means have been used.
213: * <p>
214: * When a SUBSCRIBE request is answered with a 200-class response, the
215: * notifier MUST immediately construct and send a NOTIFY request to the
216: * subscriber. When a change in the subscribed state occurs, the notifier
217: * SHOULD immediately construct and send a NOTIFY request, subject to
218: * authorization, local policy, and throttling considerations.
219: * <p>
220: * A NOTIFY does not terminate its corresponding subscription. i.e. a single
221: * SUBSCRIBE request may trigger several NOTIFY requests. NOTIFY requests
222: * MUST contain a "Subscription-State" header with a value of "active",
223: * "pending", or "terminated". As in SUBSCRIBE requests, NOTIFY "Event"
224: * headers will contain a single event package name for which a notification
225: * is being generated. The package name in the "Event" header MUST match
226: * the "Event" header in the corresponding SUBSCRIBE message. If an "id"
227: * parameter was present in the SUBSCRIBE message, that "id" parameter MUST
228: * also be present in the corresponding NOTIFY messages.
229: * <p>
230: * Event packages may define semantics associated with the body of their
231: * NOTIFY requests; if they do so, those semantics apply. NOTIFY bodies
232: * are expected to provide additional details about the nature of the event
233: * which has occurred and the resultant resource state. When present, the
234: * body of the NOTIFY request MUST be formatted into one of the body formats
235: * specified in the "Accept" header of the corresponding SUBSCRIBE request.
236: * This body will contain either the state of the subscribed resource or a
237: * pointer to such state in the form of a URI
238: * <p>
239: * A NOTIFY request is considered failed if the response times out, or a
240: * non-200 class response code is received which has no "Retry-After"
241: * header and no implied further action which can be taken to retry the
242: * request. If a NOTIFY request receives a 481 response, the notifier MUST
243: * remove the corresponding subscription even if such subscription was
244: * installed by non-SUBSCRIBE means.
245: * <p>
246: * If necessary, clients may probe for the support of NOTIFY using the
247: * OPTIONS. The presence of the "Allow-Events" header in a message is
248: * sufficient to indicate support for NOTIFY. The "methods" parameter for
249: * Contact may also be used to specifically announce support for NOTIFY
250: * messages when registering.
251: *
252: */
253: public static final String NOTIFY = "NOTIFY";
254:
255: /**
256: * Subscribe is an extension method that is used to request current state
257: * and state updates from a remote node. SUBSCRIBE requests SHOULD contain
258: * an "Expires" header, which indicates the duration of the subscription.
259: * In order to keep subscriptions effective beyond the duration communicated
260: * in the "Expires" header, subscribers need to refresh subscriptions on a
261: * periodic basis using a new SUBSCRIBE message on the same dialog. If no
262: * "Expires" header is present in a SUBSCRIBE request, the implied default
263: * is defined by the event package being used.
264: * <p>
265: * 200-class responses to a SUBSCRIBE request indicate that the subscription
266: * has been accepted, and that a NOTIFY will be sent immediately. If the
267: * subscription resource has no meaningful state at the time that the SUBSCRIBE
268: * message is processed, this NOTIFY message MAY contain an empty or neutral body.
269: * 200-class responses to SUBSCRIBE requests also MUST contain an "Expires"
270: * header. The period of time in the response MAY be shorter but MUST NOT be
271: * longer than specified in the request. The period of time in the response
272: * is the one which defines the duration of the subscription. An "expires"
273: * parameter on the "Contact" header has no semantics for SUBSCRIBE and is
274: * explicitly not equivalent to an "Expires" header in a SUBSCRIBE request
275: * or response.
276: * <p>
277: * The Request URI of a SUBSCRIBE request, contains enough information to
278: * route the request to the appropriate entity. It also contains enough
279: * information to identify the resource for which event notification is
280: * desired, but not necessarily enough information to uniquely identify the
281: * nature of the event. Therefore Subscribers MUST include exactly one
282: * "Event" header in SUBSCRIBE requests, indicating to which event or class
283: * of events they are subscribing. The "Event" header will contain a token
284: * which indicates the type of state for which a subscription is being
285: * requested.
286: * <p>
287: * As SUBSCRIBE requests create a dialog, they MAY contain an "Accept"
288: * header. This header, if present, indicates the body formats allowed in
289: * subsequent NOTIFY requests. Event packages MUST define the behavior for
290: * SUBSCRIBE requests without "Accept" headers. If an initial SUBSCRIBE is
291: * sent on a pre-existing dialog, a matching 200-class response or successful
292: * NOTIFY request merely creates a new subscription associated with that
293: * dialog. Multiple subscriptions can be associated with a single dialog.
294: * <p>
295: * Unsubscribing is handled in the same way as refreshing of a subscription,
296: * with the "Expires" header set to "0". Note that a successful unsubscription
297: * will also trigger a final NOTIFY message.
298: * <p>
299: * If necessary, clients may probe for the support of SUBSCRIBE using the
300: * OPTIONS. The presence of the "Allow-Events" header in a message is
301: * sufficient to indicate support for SUBSCRIBE. The "methods" parameter for
302: * Contact may also be used to specifically announce support for SUBSCRIBE
303: * messages when registering.
304: *
305: */
306: public static final String SUBSCRIBE = "SUBSCRIBE";
307:
308: /**
309: * Message is an extension method that allows the transfer of Instant Messages.
310: * The MESSAGE request inherits all the request routing and security
311: * features of SIP. MESSAGE requests carry the content in the form of MIME
312: * body parts. The actual communication between participants happens in the
313: * media sessions, not in the SIP requests themselves. The MESSAGE method
314: * changes this assumption.
315: * <p>
316: * MESSAGE requests do not themselves initiate a SIP dialog; under
317: * normal usage each Instant Message stands alone, much like pager
318: * messages, that is there are no explicit association between messages.
319: * MESSAGE requests may be sent in the context of a dialog initiated by some
320: * other SIP request. If a MESSAGE request is sent within a dialog, it is
321: * "associated" with any media session or sessions associated with that dialog.
322: * <p>
323: * When a user wishes to send an instant message to another, the sender
324: * formulates and issues a Message request. The Request-URI of this request
325: * will normally be the "address of record" for the recipient of the instant
326: * message, but it may be a device address in situations where the client
327: * has current information about the recipient's location. The body of the
328: * request will contain the message to be delivered.
329: * <p>
330: * Provisional and final responses to the request will be returned to the
331: * sender as with any other SIP request. Normally, a 200 OK response will be
332: * generated by the user agent of the request's final recipient. Note that
333: * this indicates that the user agent accepted the message, not that the
334: * user has seen it.
335: * <p>
336: * The UAC MAY add an Expires header field to limit the validity of the message
337: * content. If the UAC adds an Expires header field with a non-zero value, it
338: * SHOULD also add a Date header field containing the time the message is sent.
339: * Most SIP requests are used to setup and modify communication sessions.
340: *
341: */
342: public static final String MESSAGE = "MESSAGE";
343:
344: /**
345: * Refer is an extension method that requests that the recipient REFER to a
346: * resource provided in the request, this can be used to enable many
347: * applications such as Call Transfer. The REFER method indicates that
348: * the recipient (identified by the Request-URI) should contact a third
349: * party using the contact information provided in the request. A REFER
350: * request MUST contain exactly one Refer-To header field value and MAY
351: * contain a body. A receiving agent may choose to process the body
352: * according to its Content-Type.
353: * <p>
354: * A User Agent accepting a well-formed REFER request SHOULD request
355: * approval from the user to proceed. If approval is granted, the User
356: * Agent MUST contact the resource identified by the URI. SIP proxies do
357: * not require modification to support the REFER method. A proxy should
358: * process a REFER request the same way it processes an OPTIONS request.
359: * <p>
360: * A REFER request implicitly establishes a subscription to the "refer"
361: * event. The agent issuing the REFER can terminate this subscription
362: * prematurely by unsubscribing. A REFER request MAY be placed outside
363: * the scope of a dialog created with an INVITE. REFER creates a dialog,
364: * and MAY be Record-Routed, hence MUST contain a single Contact header
365: * field value. REFERs occurring inside an existing dialog MUST follow
366: * the Route/Record-Route logic of that dialog. The NOTIFY mechanism MUST
367: * be used to inform the agent sending the REFER of the status of the
368: * reference. The dialog identifiers of each NOTIFY must match those of
369: * the REFER as they would if the REFER had been a SUBSCRIBE request. If
370: * more than one REFER is issued in the same dialog, the dialog
371: * identifiers do not provide enough information to associate the
372: * resulting NOTIFYs with the proper REFER. Therefore it MUST include an
373: * "id" parameter in the Event header field of each NOTIFY containing the
374: * sequence number of the REFER this NOTIFY is associated with. A REFER
375: * sent within the scope of an existing dialog will not fork. A REFER
376: * sent outside the context of a dialog MAY fork, and if it is accepted
377: * by multiple agents, MAY create multiple subscriptions.
378: *
379: */
380: public static final String REFER = "REFER";
381:
382: /**
383: * INFO is an extension method which allows for the carrying of session
384: * related control information that is generated during a session. One
385: * example of such session control information is ISUP and ISDN signaling
386: * messages used to control telephony call services. The purpose of the INFO
387: * message is to carry application level information along the SIP signaling
388: * path. The signaling path for the INFO method is the signaling path
389: * established as a result of the call setup. This can be either direct
390: * signaling between the calling and called user agents or a signaling path
391: * involving SIP proxy servers that were involved in the call setup and added
392: * themselves to the Record-Route header on the initial INVITE message.
393: * <p>
394: * The INFO method is used for communicating mid-session signaling
395: * information, it is not used to change the state of SIP calls, nor does it
396: * change the state of sessions initiated by SIP. Rather, it provides
397: * additional optional information which can further enhance the application
398: * using SIP. The mid-session information can be communicated in either an
399: * INFO message header or as part of a message body. There are no specific
400: * semantics associated with INFO. The semantics are derived from the body
401: * or new headers defined for usage in INFO. JAIN SIP provides the
402: * facility to send {@link javax.sip.header.ExtensionHeader} in messages.
403: * The INFO request MAY contain a message body. Bodies which imply a change
404: * in the SIP call state or the sessions initiated by SIP MUST NOT be sent
405: * in an INFO message.
406: *
407: */
408: public static final String INFO = "INFO";
409:
410: /**
411: * PRACK is an extension method that plays the same role as ACK, but for
412: * provisional responses. PRACK is a normal SIP message, like BYE. As such,
413: * its own reliability is ensured hop-by-hop through each stateful
414: * proxy. Also like BYE, but unlike ACK, PRACK has its own response.
415: * In order to achieve reliability of provisional responses, in a similiar
416: * manner to 2xx final responses to INVITE, reliable provisional responses
417: * are retransmitted with an exponential backoff, which cease when a PRACK
418: * message is received. The PRACK messages contain an RAck header field,
419: * which indicates the sequence number of the provisional response that is
420: * being acknowledged.
421: * <p>
422: * PRACK is like any other request within a dialog, and is treated likewise.
423: * In particular, a UAC SHOULD NOT retransmit the PRACK request when it
424: * receives a retransmission of the provisional response being acknowledged,
425: * although doing so does not create a protocol error. A matching PRACK is
426: * defined as one within the same dialog as the response, and whose
427: * method, CSeq-num, and RSeq-num in the RAck header field match,
428: * respectively, the method and sequence number from the CSeq and the
429: * sequence number from the RSeq header of the reliable provisional response.
430: * PRACK requests MAY contain bodies, which are interpreted according to
431: * their type and disposition.
432: *
433: */
434: public static final String PRACK = "PRACK";
435:
436: /**
437: * UPDATE is an extension method that allows a client to update parameters
438: * of a session (such as the set of media streams and their codecs) but has
439: * no impact on the state of a dialog. In that sense, it is like a re-INVITE,
440: * but unlike re-INVITE, it can be sent before the initial INVITE has been
441: * completed. This makes it very useful for updating session parameters
442: * within early dialogs. Operation of this extension is straightforward, the
443: * caller begins with an INVITE transaction, which proceeds normally. Once a
444: * dialog is established, the caller can generate an UPDATE method that
445: * contains an SDP offer for the purposes of updating the session. The
446: * response to the UPDATE method contains the answer. The Allow header
447: * field is used to indicate support for the UPDATE method. There are
448: * additional constraints on when UPDATE can be used, based on the
449: * restrictions of the offer/answer model. Although UPDATE can be used on
450: * confirmed dialogs, it is RECOMMENDED that a re-INVITE be used instead.
451: * This is because an UPDATE needs to be answered immediately, ruling out
452: * the possibility of user approval. Such approval will frequently be needed,
453: * and is possible with a re-INVITE.
454: *
455: */
456: public static final String UPDATE = "UPDATE";
457:
458: /**
459: * PUBLISH is an extension method that allows a client to publish event state
460: * (such as presence information). It is sent outside of any dialog, and is not
461: * dialog creating. PUBLISH is similar to REGISTER in that it allows a user
462: * to create, modify, and remove state in another entity which manages this
463: * state on behalf of the user. Addressing a PUBLISH request is identical
464: * to addressing a SUBSCRIBE request. The Request-URI of a PUBLISH request
465: * is populated with the address of the resource for which the user wishes
466: * to publish event state. The user may in turn have multiple User Agents
467: * or endpoints that publish event state. Each endpoint may publish its own
468: * unique state, out of which the event state compositor generates the
469: * composite event state of the resource. In addition to a particular
470: * resource, all published event state is associated with a specific event
471: * package. Through a subscription to that event package, the user is able
472: * to discover the composite event state of all of the active publications.
473: *<p>
474: * PUBLISH requests create soft state in the event state compositor. This
475: * event soft state has a defined lifetime and will expire after a
476: * negotiated amount of time, requiring the publication to be refreshed
477: * by subsequent PUBLISH requests. There may also be event hard state
478: * provisioned for each resource for a particular event package. This event
479: * state represents the resource state that is present at all times, and
480: * does not expire.The event state compositor may use event hard state in
481: * the absence of, or in addition to, event soft state provided through
482: * the PUBLISH mechanism.
483: * <p>
484: * Clients may probe for the support of PUBLISH using theOPTIONS request.
485: * The presence of "PUBLISH" in the "Allow" header field in a response to
486: * an OPTIONS request indicates support for the PUBLISH method. In addition,
487: * the "Allow-Events" header field indicates the supported event packages.
488: * <p>
489: * A PUBLISH request does not establish a dialog. A UAC MAY include a
490: * Route header field in a PUBLISH request based on a pre-existing route set.
491: * The Record-Route header field has no meaning in PUBLISH requests or
492: * responses, and MUST be ignored if present. In particular, the UAC MUST
493: * NOT create a new route set based on the presence or absence of a
494: * Record-Route header field in any response to a PUBLISH request. The
495: * PUBLISH request MAY contain a Contact header field, but including
496: * one in a PUBLISH request has no meaning in the event publication
497: * context and will be ignored. A PUBLISH request may be sent within an
498: * existing dialog. In that case, the request is received in the context
499: * of any media session or sessions associated with that dialog. A new
500: * PUBLISH should not be sent (not a re-transmission) for the same
501: * Request-URI, until they have received a final response for the previous
502: * one or the previous PUBLISH request has timed out.
503: *
504: * @since v1.2
505: */
506: public static final String PUBLISH = "PUBLISH";
507: }
|