You should consider certain product runtime behaviors when you
are writing Session Initiation Protocol (SIP) applications.
Container may accept non-SIP URI schemes
The
SIP container will not reject a message if it doesn't recognize the scheme
in the request URI because the container cannot know which URI schemes are
supported by the applications. SIP elements may support a request URI with
a scheme other than sip or sips, for example,
the pres: scheme has a particular meaning for presence servers,
but the container does not recognize it. It is up to the application to determine
whether to accept or to reject a specific scheme. SIP elements may translate
non-SIP URIs using any mechanism available, resulting in SIP URIs, SIPS URIs,
or other schemes, like the tel URI scheme of RFC 2806 [9].
Invoking session listener events
SipSessionListener
and SipApplicationSessionListener events are invoked only if an application
requests the corresponding session object. You do this by using in your application
the method shown in
Methods that invoke session listener events.
Table 1. Methods that invoke session listener events
Event |
Method |
SipSessionListener |
getSession() |
SipApplicationSessionListener |
getApplicationSession() |
Session activation and passivation
During normal operation,
this product never migrates a session from one server to another. Session
migration occurs only as a result of a server failure. Therefore the SipSessionActivationListener
method's passivation callback is never invoked. However, the activation callback
is invoked when a failure forces session failover to a different server.