Troubleshoot the SIP container session repository

When troubleshooting the SIP container session repository, we might need the SIP session details to dump to a specified trace file.

Use the SIP session memory dump utility to help debug problems related to SIP container sessions. The SIP container uses the SipContainerMBean method to perform several serviceability type operations on the SIP container, including the initiation of a server quiesce through wsadmin (command-line interface). This task describes how we can use the SipContainerMBean method to dump SIP Application Session and SIP Session information contained in the in-memory session repository for SIP containers. By configuring the SIPContainerMBean method to use various trace methods, we can specify the SIP session details to dump to the specified trace file.

When the session dump methods are started using wsadmin.sh, the requested information about the sessions prints, by default, into the SystemOut.log file or sent to a predefined source, if set through the setDumpMethod method.

If we use the succinct session dump methods, only the session IDs are printed for every dump method execution.

If we use the verbose session dump methods, the following occurs:

• Transaction user details, along with the SIP session details, if they exist, print for every dump method execution.

• The only attributes that dump to the trace file are those attributes that the JSR 289 specification permits for exposure.

• The verbose methods print the following information in the trace file: appName, callID, dialog state, creation time, attribute names.

The trace printouts occur per SIP application; therefore, the sorting of all the SIP session data structures occurs before printing. Use the SIPContainerMBean dump facility for a production server by dispatching the work to a low priority thread so that all dumps are on a separate thread and the tracing does not affect the call processing latency of the overall system.

The dump distinguishes between a transaction user that has a SIP session created versus a transaction user with no SipSession object. Also included in the dump, in a delineated fashion, are SIP sessions that no longer exist, those that are no longer valid, or those that exist at the time of the trace snapshot.

Method	Description
dumpAllSASIds()	Prints a number of all SIP application sessions and the SIP application session IDs.
dumpAllTUSipSessionIds()	Prints a number of transaction users and the SIP session IDs within the transaction user (TU), if one exists.

Method	Description
dumpAllSASDetails()	Prints a number of all SIP application sessions and the SIP application session ID details.
dumpAllTUSipSessionDetails()	Prints a number of transaction users and details of the SIP session IDs within the transaction user (TU), if one exists.
dumpSASDetails(String sasId)	Prints the details of the SIP application session specified by the sasId parameter.
dumpSipSessionDetails(String sessionId)	Prints the details of the SIP session that is specified by the sessionId parameter.

Use the following information to aid in parsing print output:

• For all print output, the first line provides an application name and a number of records.

• The delimiter between the output is a TAB.

• The delimiter between session attributes is a ; (semi-colon).

Tasks

1. Start the wsadmin scripting client.

2. Determine to use the succinct or verbose SipContainerMBean methods.

3. Set the variable, apps, to all objects in the SipContainerMBean method. For example:

   • Use Jacl:

     set apps [$AdminControl queryNames type=SipContainerMBean,*]
     

   • Use Jython:

     apps = AdminControl.queryNames('WebSphere:type=SipContainerMBean,*')
     

   This command returns the following output:

   • Use Jacl:

     wsadmin>set apps [$AdminControl queryNames type=SipContainerMBean,*]
     WebSphere:cell=cell,version=<WAS_version>,spec=1.0,name=SipContainerMBeanId,mbeanIdentifier=SipContainerMBeanId,
     type=SipContainerMBean,node=node,process=server1
     

   • Use Jython:

     wsadmin>apps = AdminControl.queryNames('WebSphere:type=SipContainerMBean,*')
     	wsadmin>print apps
     WebSphere:cell=cell,version=<WAS_version>,spec=1.0,name=SipContainerMBeanId,mbeanIdentifier=SipContainerMBeanId,
     type=SipContainerMBean,node=node,process=server1
     

4. (Optional) Use the SipContainerMBean method to specify that we want the trace output to go to a specific file. To use the SipContainerMBean method to configure an output method, call the setDumpMethod method before you call the succinct or verbose memory dump methods; for example:

   setDumpMethod(String_method, String_description) 
   

   The string_method parameter specifies to use an output method of file and the string_description parameter specifies the file path, including the file name. This method returns a string indication for success or failure. This method only supports setting a specific file for printing; for example:

   setDumpMethod("file", "/opt/IBM/output.log")
   

   The file parameter value indicates to print the trace data to a file and /opt/IBM/output.log indicates the full path to the file for printing.

   If we do not specify this optional method, the output is sent to the SystemOut.log file.

5. Start the SIP memory dump utility method we want on the SipContainerMBean method. Specify one of the succinct or verbose SipContainerMBean methods; for example:

   • Use Jacl:

     $AdminControl invoke $apps<method_name>
     

   • Use Jython:

     AdminControl.invoke (apps, "<method_name>")
     

6. (Optional) Obtain a list of all of the SipContainerMBean methods in use. For example:

   • Use Jacl:

     $Help all $apps
     

   • Use Jython:

     print Help.all(apps)
     

   This command returns the following output:

   Name: WebSphere:cell=cell,version=<WAS_version>,spec=1.0,name=SipContainerMBeanId,mbeanIdentifier=SipContainerMBeanId,type=SipContainerMBean,node=node,process=<server>
   Description: null
   Class name: javax.management.modelmbean.RequiredModelMBean
   
   Attribute Type Access 
   Operation
   void quiesce(boolean)
   void setWeight(int)
   int getWeight()
   int dumpAllSASIds()
   int dumpAllTUSipSessionIds()
   int dumpAllSASDetails()
   int dumpAllTUSipSessionDetails()
   int dumpSASDetails(java.lang.String)
   int dumpSipSessionDetails(java.lang.String)
   java.lang.String setDumpMethod(java.lang.String, java.lang.String)
   
   
   Notifications
   sip.container.overloaded 
   sip.container.overload.cleared 
   jmx.attribute.changed 
   
   Constructors
   

We have configured the SIP session memory dump utility to print the level of trace information that we want for the SIP application session and SIP session to help you troubleshoot problems with the SIP container.

Example

The following examples illustrate the wsadmin scripting commands and trace data output when we use SipContainerMBean methods in a single application server configuration.

• Use the succinct dumpAllSASIds method:

  • Use Jacl:

    $AdminControl invoke $apps dumpAllSASIds
    

  • Use Jython:

    AdminControl.invoke (apps, "dumpAllSASIds")
    

  Results in the following information in the SystemOut.log file:

  dump.ids.test.app1	2
  local.1347524282775_8
  local.1347524282775_7
  

  This information is provided in the following format:

  [SAS_ID]  
  

• Use the verbose dumpAllSASDetails method and specifying that the dump output print to the /opt/IBM/output.log file:

  • Use Jacl:

    $AdminControl invoke $apps setDumpMethod {{FILE} {/opt/IBM/output.log}}
    $AdminControl invoke $apps dumpAllSASDetails
    

  • Use Jython:

    AdminControl.invoke (apps, "setDumpMethod", ["FILE", "/opt/IBM/output.log"])
    AdminControl.invoke (apps, "dumpAllSASDetails")
    

  Results in the following verbose information in the /opt/IBM/output.log file:

  dump.ids.test.app1	1
  local.1348147884986_2	Sep 20,2012 16:31	DumpSasDetailsAttr; 
  

  This information is provided in the following format:

  [SAS_ID]  [CreationTime] [attributes]
  

• Use the succinct dumpAllTUSipSessionIds method to print the number of transaction users and the SIP session IDs within the transaction user:

  • Use Jacl:

    $AdminControl invoke $apps dumpAllTUSipSessionIds
    

  • Use Jython:

    AdminControl.invoke (apps, "dumpAllTUSipSessionIds")
    

  Results in the following information in the SystemOut.log file:

  DumpSessionsTest	1
  local.1349965420866_1_0	true	local.1349965420866_1_0_1
  

  This information is provided in the following format:

  [TU_ID] [hasSIPSession] [SipSessionId] 
  

• Use the verbose dumpAllTUSipSessionDetails method to print the of transaction users and details of the SIP session IDs within the transaction user:

  • Use Jacl:

    $AdminControl invoke $apps dumpAllTUSipSessionDetails
    

  • Use Jython:

    AdminControl.invoke (apps, "dumpAllTUSipSessionDetails")
    

  Results in the following information in the SystemOut.log file:

  DumpSessionsTest	1
  local.1349965420866_1_0	true	local.1349965420866_1_0_1	8-8548@9.148.57.128	2	false	INVITE
  	local.1349965420866_1	Jan 24,2013 14:41	TestSSAttr1; TestSSAttr2;
  

  This information is provided in the following format:

  [TU_ID] [hasSIPSession] [SipSessionId] [Call-Id] [DialogState] [hasOutgoingTransaction] [initialMethod] [SAS_ID]  [CreationTime] [attributes]
  

• Use the verbose dumpSASDetails method to print the details of the SIP application session specified by the sasID parameter:

  • Use Jacl:

    $AdminControl invoke $apps dumpSASDetails  $sasId 
    

  • Use Jython:

    AdminControl.invoke (apps, "dumpSASDetails ", "sasId")
    

  Results in the following information in the SystemOut.log file:

  local.1358950127352_20	Jan 23,2013 16:19	TestSASAttr1; TestSASAttr2; 
  

  If the requested session does not exist, an error message is given; for example:

  ERROR: Requested session <local.1358950127352_20> does not exist.
  

• Use the verbose dumpSipSessionDetails method to print the details of the SIP session specified by the sessionId parameter:

  • Use Jacl:

    $AdminControl invoke $apps dumpSipSessionDetails $sessionId
    

  • Use Jython:

    AdminControl.invoke (apps, "dumpSipSessionDetails", "sessionId")
    

  Results in the following information in the SystemOut.log file:

  local.1358950127352_21_20_1	local.1358950127352_21	Jan 23,2013 16:22	TestSSAttr1; TestSSAttr2; 
  

  If the requested session does not exist, an error message is given; for example:

  ERROR: Requested session <local.1358950127352_21_20_1> does not exist.
  

Start the wsadmin scripting client