Source Code Cross Referenced for Request.java in  » 6.0-JDK-Modules » Java-Advanced-Imaging » javax » sip » message » Java Source Code / Java DocumentationJava Source Code and Java Documentation

Java Source Code / Java Documentation
1. 6.0 JDK Core
2. 6.0 JDK Modules
3. 6.0 JDK Modules com.sun
4. 6.0 JDK Modules com.sun.java
5. 6.0 JDK Modules sun
6. 6.0 JDK Platform
7. Ajax
8. Apache Harmony Java SE
9. Aspect oriented
10. Authentication Authorization
11. Blogger System
12. Build
13. Byte Code
14. Cache
15. Chart
16. Chat
17. Code Analyzer
18. Collaboration
19. Content Management System
20. Database Client
21. Database DBMS
22. Database JDBC Connection Pool
23. Database ORM
24. Development
25. EJB Server geronimo
26. EJB Server GlassFish
27. EJB Server JBoss 4.2.1
28. EJB Server resin 3.1.5
29. ERP CRM Financial
30. ESB
31. Forum
32. GIS
33. Graphic Library
34. Groupware
35. HTML Parser
36. IDE
37. IDE Eclipse
38. IDE Netbeans
39. Installer
40. Internationalization Localization
41. Inversion of Control
42. Issue Tracking
43. J2EE
44. JBoss
45. JMS
46. JMX
47. Library
48. Mail Clients
49. Net
50. Parser
51. PDF
52. Portal
53. Profiler
54. Project Management
55. Report
56. RSS RDF
57. Rule Engine
58. Science
59. Scripting
60. Search Engine
61. Security
62. Sevlet Container
63. Source Control
64. Swing Library
65. Template Engine
66. Test Coverage
67. Testing
68. UML
69. Web Crawler
70. Web Framework
71. Web Mail
72. Web Server
73. Web Services
74. Web Services apache cxf 2.0.1
75. Web Services AXIS2
76. Wiki Engine
77. Workflow Engines
78. XML
79. XML UI
Java
Java Tutorial
Java Open Source
Jar File Download
Java Articles
Java Products
Java by API
Photoshop Tutorials
Maya Tutorials
Flash Tutorials
3ds-Max Tutorials
Illustrator Tutorials
GIMP Tutorials
C# / C Sharp
C# / CSharp Tutorial
C# / CSharp Open Source
ASP.Net
ASP.NET Tutorial
JavaScript DHTML
JavaScript Tutorial
JavaScript Reference
HTML / CSS
HTML CSS Reference
C / ANSI-C
C Tutorial
C++
C++ Tutorial
Ruby
PHP
Python
Python Tutorial
Python Open Source
SQL Server / T-SQL
SQL Server / T-SQL Tutorial
Oracle PL / SQL
Oracle PL/SQL Tutorial
PostgreSQL
SQL / MySQL
MySQL Tutorial
VB.Net
VB.Net Tutorial
Flash / Flex / ActionScript
VBA / Excel / Access / Word
XML
XML Tutorial
Microsoft Office PowerPoint 2007 Tutorial
Microsoft Office Excel 2007 Tutorial
Microsoft Office Word 2007 Tutorial
Java Source Code / Java Documentation » 6.0 JDK Modules » Java Advanced Imaging » javax.sip.message 
Source Cross Referenced  Class Diagram Java Document (Java Doc) 


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:        }
www.java2java.com | Contact Us
Copyright 2009 - 12 Demo Source and Support. All rights reserved.
All other trademarks are property of their respective owners.