Deprecated API

Contents

• Deprecated Fields
• Deprecated Methods

Deprecated Fields

javax.servlet.sip.SipServlet.PRACK_SUPPORTED
in favor of using the "javax.servlet.sip.supported" attribute The string "javax.servlet.sip.100rel". This is the name of the ServletContext attribute whose value suggests whether the container supports the 100rel extension i.e. RFC 3262.

Deprecated Methods

javax.servlet.sip.SipFactory.createRequest(SipServletRequest, boolean)
usage of this method is deprecated. Setting the sameCallId flag to "true" actually breaks the provisions of [RFC 3261] where the Call-ID value is to be unique accross dialogs. Instead use a more general method defined on the B2buaHelper B2buaHelper.createRequest(SipServletRequest) Creates a new request object belonging to a new SipSession. The new request is similar to the specified origRequest in that the method and the majority of header fields are copied from origRequest to the new request. The SipSession created for the new request also shares the same SipApplicationSession associated with the original request. This method satisfies the following rules: The From header field of the new request has a new tag chosen by the container. The To header field of the new request has no tag. If the sameCallId argument is false, the new request (and the corresponding SipSession) is assigned a new Call-ID. Record-Route and Via header fields are not copied. As usual, the container will add its own Via header field to the request when it's actually sent outside the application server. For non-REGISTER requests, the Contact header field is not copied but is populated by the container as usual. This method provides a convenient and efficient way of constructing the second "leg" of a B2BUA application. It is used only for the initial request. Subsequent requests in either leg must be created using SipSession.createRequest(java.lang.String) as usual.

javax.servlet.sip.SipApplicationSession.encodeURI(URI)
Encodes the ID of this SipApplicationSession into the specified URI. The container must then be prepared to associate this application session with an incoming request which was triggered by activating the encoded URI. In the case of SIP and SIPS URIs, the container may also rewrite the host, port, and transport protocol components of the URI based on its knowledge of local listen points. When doing so it should take existing settings as a hint as to which listen point to select when it has more than one. This method allow applications to correlate events which would otherwise be treated as being independent, that is, as belonging to different application sessions. For example, an application might send an instant message with an HTML body to someone. The IM body may then contain a SIP URI pointing back to the SIP servlet container and the application session in which the IM was generated, thus ensuring that an INVITE triggered by the IM recipient triggering that URI is associated with this application session when received by the container. Containers are required to support rewriting of SIP and SIPS URIs.

javax.servlet.sip.Proxy.getSequentialSearchTimeout()
Returns the current value of the sequential search timeout parameter. This is measured in seconds.

javax.servlet.sip.Proxy.getStateful()
Returns true if this proxy operation is transaction stateful (the default), or false if it is stateless.

javax.servlet.sip.Proxy.setSequentialSearchTimeout(int)
Sets the sequential search timeout value for this Proxy object. This is the amount of time the container waits for a final response when proxying sequentially. When the timer expires the container CANCELs the current branch and proxies to the next element in the target set. The container is free to ignore this parameter.

javax.servlet.sip.Proxy.setStateful(boolean)
Specifies whether the server should proxy statelessly or not, that is whether it should maintain transaction state whilst the proxying operation is in progress. This proxy parameter is a hint only. Implementations may choose to maintain transaction state regardless of the value of this flag, but if so the application will not be invoked again for this transaction.