Oracle Server E10293-02 Benutzerhandbuch
The SIP Container
SIP Servlets 2-3
SIP Application Sessions
While an application may involve several types of servlet sessions (for example, SIP
and HTTP), these sessions must be related to the same application. This is done
through a SIP Application Session. The SIP Application Session can hold multiple
protocol sessions; the protocol sessions can be of the same type or different types (SIP,
HTTP).
and HTTP), these sessions must be related to the same application. This is done
through a SIP Application Session. The SIP Application Session can hold multiple
protocol sessions; the protocol sessions can be of the same type or different types (SIP,
HTTP).
A SIP Application Session can hold attributes available to all protocol sessions related
to that application session. A SIP Application Session can hold multiple protocol
sessions. For example, B2BUA creates two sessions that are located in the same SIP
Application Session.
to that application session. A SIP Application Session can hold multiple protocol
sessions. For example, B2BUA creates two sessions that are located in the same SIP
Application Session.
A SIP Application Session exists until it times out or when the application explicitly
calls the invalidate method. A well-behaved application should always invalidate a
session when it does not need it anymore. If the SIP Application Session is invalidated,
all Protocol Session objects are invalidated together with it. The timeout value of a
session is set with the <session-timeout> parameter in the sip.xml file. If no
timeout value is defined within this element, then the default value for the container is
used (the default is 15 minutes).
calls the invalidate method. A well-behaved application should always invalidate a
session when it does not need it anymore. If the SIP Application Session is invalidated,
all Protocol Session objects are invalidated together with it. The timeout value of a
session is set with the <session-timeout> parameter in the sip.xml file. If no
timeout value is defined within this element, then the default value for the container is
used (the default is 15 minutes).
If a subsequent request arrives after a session has been invalidated, then the server will
respond with a 481 "Call transaction does not exist" message. Requests and responses
that correspond to a SIP application session can be retrieved with the
getApplicationSession()
respond with a 481 "Call transaction does not exist" message. Requests and responses
that correspond to a SIP application session can be retrieved with the
getApplicationSession()
method on the request (SipServletRequest) or the
response (SipServletResponse) object.
Protocol Sessions
A Protocol Session is a session for a certain protocol. If an application involves several
protocols, the SIP application session would then hold several protocol sessions.
protocols, the SIP application session would then hold several protocol sessions.
A SipSession object can represent a point-to-point SIP relationship, an established
SIP dialog, or an initial state SIP dialog. The initial state is described as a request that
has been received or created with the createRequest method in the sipFactory
class. The SIP session object is created by the container when an initial request has
invoked one servlet.
SIP dialog, or an initial state SIP dialog. The initial state is described as a request that
has been received or created with the createRequest method in the sipFactory
class. The SIP session object is created by the container when an initial request has
invoked one servlet.
A request or a response corresponding a SIP session can be retrieved with the
getSession()
getSession()
method on the request (SipServletRequest) or the response
(SipServletResponse) object. All of the protocol sessions in an application session
can be retrieved with the getSessions() method on the
SipApplicationSession
can be retrieved with the getSessions() method on the
SipApplicationSession
object.
Transactions
A SIP transaction consists of a single SIP request and all responses to that request,
including the provisional responses and a final response.
including the provisional responses and a final response.
A SipServletRequest and a SipServletResponse always belong to a SIP
transaction. If a servlet tries to send a message that violates the SIP transaction state
model, the container throws an IllegalStateException. The SIP Servlet API is
designed in such a way that a developer does not need to consider transactions, only
requests and responses.
transaction. If a servlet tries to send a message that violates the SIP transaction state
model, the container throws an IllegalStateException. The SIP Servlet API is
designed in such a way that a developer does not need to consider transactions, only
requests and responses.