Troubleshooting SIP call flows
Learn how to use features within the High Performance Extensible Logging (HPEL) log and trace infrastructure to troubleshoot Session Initiation Protocol (SIP) call flows across SIP proxies and SIP containers.
About this task
When HPEL is enabled for the SIP proxy and the SIP container, all log and trace records that are related to SIP message processing for the proxy and container include the SIP call identifier extension, SIPCallId. Because the SIPCallId extension is constant across all components within a SIP call flow, you can use this extension to track the call flow between a SIP proxy and container.
Other extensions are also available for the SIP container. To learn about other extensions that are available, see the log and trace extensions documentation.
Procedure
Results
You are ready to view query results. The log viewer dumps the results of the query to the administrative console. You can choose to redirect the query results to a text file by piping the results to a specified file. If performance is not a concern, you can enable the HPEL text log and change it to the advanced format. Using the advanced format, HPEL stores the SIPCalId extensions.
Example
- Determine the SIP Call identifier in question. If you do not know
the Call identifier, you can use the following command to view all
traces for all the call identifiers in the logs:
The output of this command is in the advanced format and includes the additional information available including the SIPCallId; for example:logViewer.sh -format advance -includeExtensions SIPCallId
[10/2/12 13:23:08:634 EDT] 00000084 > UOW= source=com.ibm.ws.proxy.channel.sip.SipProxyConnection method=messageReceivedThreaded org=IBM prod=WebSphere component=Application Server thread=[UDP Thread Pool : 0] SIPCallId=[1-23304@9.37.23.235] Entry [10/2/12 13:23:08:634 EDT] 00000084 > UOW= source=com.ibm.ws.proxy.channel.sip.SipProxyConnection method=readIndication: id = 1282434117 org=IBM prod=WebSphere component=Application Server thread=[UDP Thread Pool : 0] SIPCallId=[1-23304@9.37.23.235] Entry [10/2/12 13:23:08:634 EDT] 00000084 3 UOW= source=com.ibm.ws.proxy.channel.sip.SipProxyConnection org=IBM prod=WebSphere component=Application Server thread=[UDP Thread Pool : 0] SIPCallId=[1-23304@9.37.23.235] Received Message from 9.37.23.235:10200 - [10/2/12 13:23:08:634 EDT] 00000084 3 UOW= source=com.ibm.ws.proxy.channel.sip.SipProxyConnection org=IBM prod=WebSphere component=Application Server thread=[UDP Thread Pool : 0] SIPCallId=[1-23304@9.37.23.235] Message received from CLIENT: [10/2/12 13:23:08:634 EDT] 00000084 3 UOW= source=com.ibm.ws.proxy.channel.sip.SipProxyConnection org=IBM prod=WebSphere component=Application Server thread=[UDP Thread Pool : 0] SIPCallId=[1-23304@9.37.23.235] Received Message from 9.37.23.235:10200 -
- Filter the logs that are based on a specific call identifier by
using the following command:
The results of the command are in the basic format and shows log entries typical for SIP proxy log. The output is filtered on the specified SIPCallId extension.bin/logViewer.sh -includeExtensions SIPCallId=1-23304@9.37.23.235
[10/2/12 13:23:08:634 EDT] 00000084 SipProxyConne > messageReceivedThreaded Entry [10/2/12 13:23:08:634 EDT] 00000084 SipProxyConne > readIndication: id = 1282434117 Entry [10/2/12 13:23:08:634 EDT] 00000084 SipProxyConne 3 Received Message from 9.37.23.235:10200 - [10/2/12 13:23:08:634 EDT] 00000084 SipProxyConne 3 Message received from CLIENT: [10/2/12 13:23:08:634 EDT] 00000084 SipProxyConne 3 Received Message from 9.37.23.235:10200 - [10/2/12 13:23:08:634 EDT] 00000084 SIPMessageImp > getDuplicate Entry [10/2/12 13:23:08:634 EDT] 00000084 SIPMessageFac > SipMessageFactoryImpl:getRef entry Entry [10/2/12 13:23:08:634 EDT] 00000084 SIPMessageFac < SipMessageFactoryImpl:getRef: exit: Exit