Tip:
Highlight text to annotate it
X
This presentation describes the serviceability enhancements to Session Initiation Protocol
(commonly called SIP for short) for WebSphere Application Server V8.5.5.
This slide shows the subtopics you will cover as part of this presentation.
The SIP serviceability enhancements introduced in WebSphere Application Server V8.5.5
include new PMI counters, extended logging, the Session
Dumping Utility and the new UnmatchedMessageListener API.
The new PMI monitors for the SIP container add twenty
new queue statistics counters, six new container counters and 24 proxy counters.
The queue statistics counters mainly focus on tracking the SIP
container and application task durations, and provide an insight into the SIP message queue.
These counters can be used to trigger alarms caused by
SIP congestion issues in the container, identify application thread
congestion issues, and monitor total message processing of the system.
The new container counters provide counters for the number of
replicated and not replicated SIP application sessions and SIP sessions
at the SIP container, the number of rejected requests
received at the SIP container, and the number of SIP timers invocations at the SIP container.
These counters can be used to trigger alarms caused by
cluster replication issues, possible network issues, and invalid
SIP messages received at the SIP container.
Examples include denial-of-service attempts and configuration issues.
The new PMI counters in the SIP proxy monitor total
messages processed, provide SIP container and load balancer status, and list SIP messages received.
These counters can be used to trigger alarms based on
SIP environment changes, like a missing load balancer or SIP container.
They can also be used to trigger alarms when invalid
SIP messages are received at the SIP proxy, such
as those messages caused by denial-of-service attempts and configuration issues.
The queue statistics counters mainly focus on tracking the SIP
container and application task durations and provide an insight into the SIP message queue.
These counters can be used to trigger alarms due to
SIP congestion issues in the container, identify application thread
congestion issues, and monitor total message processing of the system.
The new container counters provide counters for the number of
replicated and non replicated SIP application sessions and SIP sessions
at the SIP container, the number of rejected requests
received at the SIP container, and the number of SIP timers invocations at the SIP container.
These counters can be used to trigger alarms caused by
cluster replication issues, possible network issues, and invalid
SIP messages received at the SIP container.
The new PMI counters in the SIP proxy monitors total
messages processed, provide SIP container and load balancer status,
and lists SIP messages received.
These counters can be used to trigger alarms due to
SIP environment changes and trigger alarms caused by invalid SIP messages at the SIP proxy.
Next are examples to illustrate ways these new SIP PMI counters can be used.
In scenario one, a company deploying WebSphere SIP application
servers and proxies must monitor these processes for indicators that
system performance is degrading.
By enabling the new queue monitoring features at the container
and proxy, increasingly active queue activity can be used
to trigger SNMP alarms before a system failure occurs.
Excessive queue activity can also indicate other problems in the
network like traffic burst, problems at the load balancer, or a denial-of-service attack.
In scenario two, a developer who is testing a
new application under load discovers that the application is not
performing up the specified requirements.
By enabling the new application task duration task monitors,
you can identify if performance issues are caused by excessive thread activity at the application.
In scenario three, a company is deploying WebSphere SIP
application servers, SIP proxies, and load balancers in
a clustered environment and must monitor these processes to determine if they are communicating.
By enabling the new monitoring feature at the SIP proxy,
they can determine if these components are communicating.
By enabling the new replication monitoring PMI counters, they
can monitor the exact number of replicated SIP application sessions,
thus being aware to the impact of a failover event.
In scenario four, a company deploying WebSphere SIP environment
with SIP proxies wants to determine if clients are misusing their SIP environment.
By enabling the new monitoring feature at the SIP proxy
and the rejected messages at the container they can monitor
the number of invalid SIP messages received from clients.
This can help determine if a denial-of-service attack is occurring,
or if clients are not complying with the SIP protocol.
To improve serviceability of the SIP proxy and container,
several new enhancements to logging were added.
New logging extensions for the High Performance Extensible Logging (
HPEL) mode were added to provide the ability to
correlate trace entries by SIP call ID, SIP session ID and SIP application ID.
These are added to the SIP proxy and the container .
For the SIP proxy, the ability to log complete
SIP messages (in contrast to a limited header)
when access logging is available by way of a custom property.
Additionally, the SIP proxy can now log in trace
mode the reason and Call ID for messages rejected by the SIP proxy.
Next a discussion of the new SIP logging extensions for High Performance Extensible logging.
SIP includes unique identifiers related to messages that pass over a SIP dialog.
The SIP call ID is common across the SIP clients; the SIP proxy and SIP container.
The SIP session ID and SIP application session ID are common inside the SIP container.
These IDs are the context under which many actions and
subsequent trace messages are written to the trace logs by the SIP proxy and the SIP container.
The extension labels are listed here.
To improve serviceability, if a WebSphere Application Server is
operating with HPEL logging enabled, these IDs are logged with the trace messages.
Now you can follow trace messages generated while processing a
particular call ID, session ID or application session ID using standard HPEL filtering techniques.
Additional information about the IDs is available in the Information Center at the provided link.
In order to see the new extensions in the trace and log files, enable HPEL logging.
This is done under 'Logging and Tracing' for the SIP proxy server and the SIP container server.
The trace context setting that allows you to observe detailed
activity for the proxy and container is provided here.
There are several 'best practices' when using HPEL with SIP to be aware of.
HPEL offers a text logging mode that is akin to
the classic text trace logs, however it poses significant
performance degradation to the environment when used.
However HPEL logs in binary mode have been shown to
improve performance but since they are binary they require the
logviewer command to output the files into text.
These are a few suggestions on using the logviewer command.
To tail the trace log, use the "logviewer monitor" command.
The trace log can be output as text using the logviewer outLog command.
To see the LogRecordExtensions (to see the SIPCallId, and so on ) use the advanced format.
To filter on multiple extensions use the includeExtensions and provide
the extensions (comma separated) as in the example provided here.
In a typical usage scenario, the goal is to
associate the log messages within the SIP container to an application session ID and session ID.
The SIP Container receives a message and establishes a dialog
that can be long running inside an application session and session.
It can be processing THOUSANDS of these at any moment.
Using the new HPEL feature, the container log can
be filtered by SIPASId, SIPSessionId or SIPCallId and simplify
the log messages to just see a single dialog in the container.
The figure in this slide demonstrates three different Application Sessions
each containing several sessions that in turn, contain a few different call ids.
The new log extensions enable filtering on any of these parameters.
In this example, a SIP UAC sends a SIP
message with a SIPCallId to a SIP environment containing a SIP proxy and SIP container.
For all processing done by the SIP Proxy for that
message, log and trace messages will contain the SIPCallId.
The SIP container receives a message that also has the same SIPCallId.
All processing, provided by the SIP container, on
the message will also result in log messages with the SIPCallId.
This slide shows an example of using the logViewer command to filter on SIPCallId
The first logViewer output shows the advanced format for any entries that also contain a SIPCallID
The second output shows the trace messages in basic format for a specific SIPCallId.
Support has also been added for two additional serviceability scenarios in the SIP proxy.
In the first case, SIP proxy call logging is enhanced to enable logging of complete messages.
This enables you to troubleshoot messages passing through the SIP proxy.
Use a new custom property called 'logCompleteHeaders' to view
complete messages (rather than partial messages) passing through
the SIP proxy for problem determination and call flow analysis.
In the second case, messages that are rejected by the SIP proxy are now logged.
You need to know what call IDs are associated with
messages rejected by the SIP proxy and the reason for the rejection.
New messages and associated trace specifications are added to enable
the logging of messages rejected due to; the container
being overloaded, the message containing a not valid partition
ID, the container's application server being unavailable, the
SIP message not being compliant, and a network connection being lost.
You can now track call IDs of rejected messages for troubleshooting call problems.
Logging of complete messages is enabled through a custom SIP
proxy property called 'logCompleteMessages' .
To enable this, first enable 'Access Logging' in
the SIP proxy, then create a custom property called
'logCompleteMessages' and set the Value to true.
After doing this, restart the SIP proxy.
Trace specifications are used to log the rejected messages.
It can either be all encompassing with:
com.ibm.ws.proxy.*=all
Or more granular.
This slide shows the specific trace specifications that can be
set to log specific rejected message categories.
This slide shows the format of a rejected message on the SIP Proxy.
These can be viewed in the 'trace.log' or using the logViewer command in HPEL mode.
Next you will learn more about the Session Dumping utility.
The SIP container session dumping utility is a serviceability enhancement
to enable the ability to access detailed application and session
data while the SIP container is running, even in a production environment.
Using this utility, it is possible to debug problems related to SIP container sessions.
For instance, issues with resolving session cleanup or when
trying to identify specific call failures.
This feature is always enabled and sessions can be dumped
to a text file by way of the command line using WSADMIN scripting.
The sip container dumping utility is accessed by way of
the WSADMIN client by use of the SipContainerMBean.
This slide shows the specific methods that are invoked and the information they provide.
The methods can list all application sessions and their IDs,
the number of transaction users and session IDs and details for the information requested.
More detailed information is available in the information center.
To use the session dumping utility start the wsadmin scripting client.
Next, set the 'apps' variable as demonstrated here.
By default the output is sent to the SystemOut.log file.
You can change this behavior by use of the setDumpMethod command.
Finally, choose the method to execute.
Here is an example of some of the data that is output by various dump methods.
This data is useful in many ways.
Example, if you need to dump a single session
or all session details when trying to debug a session
leak, you run a test to completion and wait long enough for all sessions to be quiesced.
Then you dump the remaining sessions to determine details on what is leaking and why.
As another example, you notice from a call detail
record that a particular call never completed cleanly.
Session dumping provides information about the session.
You first extract the faulty SIP application session ID from
the call detail record and then the ID is used to dump a single session from the SIP container.
A new programming interface for the SIP Container provides a
way for applications to handle unexpected in-dialog requests and responses.
This new interface is called UnmatchedMessageListener.
It provides an API that enables an application to receive
all incoming request or response messages that cannot be matched to existing dialogs.
You can use the UnmatchedMessageListener API to act on these unmatched messages in order to: 1.
clean up call detail records associated with calls that have failed over from another geography, 2.
recognize denial-of-service (DoS) attacks and 3.
discover misbehaving network components.
An Unmatched Request is a request that has 'To'
and 'From' tags (meaning that request belongs to
a dialog), but the related dialog is not found in the SIP container.
These can occur because the dialog was never created in
this SIP container or has already ended and has been invalidated.
When an incoming, unmatched request is received by the
SIP container, the SIP container responds with a 481
"Call/Transaction does not exist" and forwards a UnmatchedRequestEvent
to the UnmatchedMessageListener class.
An unmatched response is a response that cannot be matched
to any outgoing requests or transactions.
When an unmatched response is received, the SIP container
forwards the request as a UnmatchedResponseEvent to the UmatchedMessageListener class
and discards the response.
UnmatchedRequestEvent and UnmatchedResponseEvent are defined in the com.ibm.websphere.sip.unmatchedMessages.events package.
These events contain an interface to get the incoming unmatched
request or response and the ServletContext related to the application.
The application can use the ServletContext to create new SIP
activity but the unmatched request or response is not an active SIPMessage.
The application cannot create a response for the received unmatched request or proxy it.
Trying to do so will result in an IllegalStateException in the SIP container.
This slide discusses several details about the API implementation.
The UnmatchedMessageListener API is defined in the com.ibm.ws.sip.interface.jar file that
is located in the com.ibm.websphere.sip.unmatchedMessages package.
Multiple listeners can be defined.
Once defined they are started independent of each other.
If they exist on the same application server, they are started in a random order.
Any point in time during the routing that the SIP
Container determines there is unmatched request or response, all
of the UnmatchedMessageListener listeners on the server are activated.
Unmatched requests and unmatched responses are counted by WebSphere Performance
Monitoring Infrastructure (PMI) as dropped messages.
This slide shows the flow of how an incoming SIP
request is processed of both: when it matches and does not match outgoing requests or transactions.
This slide shows how to define a listener either by
way of the deployment descriptor or by using annotations.
This slide shows the UnmatchedMessageListener API definition.
This slide contains links to useful information.
You can help improve the quality of IBM Education Assistant content by providing feedback.