SIP User Documentation Chapter 4
PREVIOUS CHAPTER | TOC | NEXT CHAPTER
HPE SIMULAP SIP plugin allows you to handle dialog IDs and transaction IDs locally in a logical manner. Logical IDs are mapped to the real IDs that are created by the stack.
The following parameters are the most important for dialog management and transaction identification in this plug-in:
-
Dialog ID
The unique identifier of a SIP dialog, which consist of the Call-Id, the remote tag, and the local tag values. The logical dialog ID used in this plug-in is mapped to the real IDs that are sent through the network. -
Transaction ID
The unique identifier of a SIP transaction, which is identical to the branch parameter value in the Via header field. The logical transaction ID used in this plug-in is mapped to the real ID value that is sent through the network. -
Session max life time
The SIP node parameter that determines the maximum SIP dialog lifetime for SIP messages. It is used mainly in performance mode. As soon as a dialog is created (either because the SIP node receives or sends an appropriate request), a timer is started to limit the dialog duration. If the timer expires before the dialog is not ended, aCANCELis automatically sent by the SIP node. This allows avoiding local dialog leakage in case of a remote issue.
See Interaction between SIP nodes, samplers, and peer nodes page.
A SIP node configuration element is responsible for creating and configuring the connection to the SIP network.
The SIP messages of concurrent dialogs are differentiated by their dialog IDs. Each SIP message is associated with a dialog ID to indicate which SIP dialog they belong to.
At SIP stack level, the dialog is identified at each User Agent (UA) with a dialog ID, which consists of the following values:
-
Call-IDheader value -
Local tag of the
Fromheader -
Remote tag of the
Toheader
The dialog ID at each UA involved in the dialog is not the same. Specifically, the local tag at one UA is identical to the remote tag at the peer UA. The tags are opaque tokens that facilitate the generation of unique dialog IDs.
You can use the Apache JMeter GUI to specify the Call-ID header value and the From and To headers tags for an INVITE request manually. If they are not specified manually, they are automatically generated by the stack.
This plug-in allows creating and using five dialog IDs to manage dialog identification in a logical manner:
Dial1Dial2Dial3Dial4Dial5
These dialog IDs are created and used locally at application level without knowing the real IDs that are transferred though the network.
IMPORTANT: The dialog ID index is related to only one thread. If the thread group has several threads in parallel,
Dial1is mapped to a different dialog ID in each thread when the stack creates the real dialog ID that is sent through the network. In the context of the same thread, the logical dialog ID can be reused as soon as a dialog is ended.
SIP is a transactionnal protocol: interactions between components take place in a series of independent message exchanges. Concurrent transactions are differentiated by their transaction IDs. Each SIP message is associated with a transaction ID to indicate which SIP transaction they belong to.
At SIP stack level, the branch parameter in the Via header field value serves as a transaction identifier, and it is used by proxies to detect loops. You can use the Apache JMeter GUI to specify the branch parameter value manually or you can allow the stack to generate it automatically.
At application level, local transaction IDs are used and these IDs are mapped to the branch IDs throughout the message exchange. It allows creating and using the following transaction IDs:
trans1trans2trans3trans4trans5
These transaction IDs are created and used only locally to identify a request and the corresponding responses sent or received within a SIP dialog, and can be reused in a parallel dialog.
Transaction IDs can be reused within the same dialog as well. As soon as the message exchange identified with a transaction ID is complete in the context of a dialog ID, the same transaction ID can be reused for another exchange within the same dialog.
NOTE: Even though transaction IDs can be reused, it is recommended not to reuse them within a dialog. The Test Plan is easier to follow if there is a clear mapping between the logical transaction IDs and the SIP network transactions.
Intertwined dialogs with several dialog IDs can be used in functional testing, for example, if the emulated user agent initiates a dialog while, at the same time, another dialog is expected to be initiated remotely. In this case, separate logical dialog IDs (Dial1 and Dial2) are used for identifying the messages of the locally initiated dialog and the remotely initiated dialog.
Dialog ID and transaction ID management for intertwined dialogs illustrated in Figure 3 shows an example call flow where two logical dialog IDs are used to differentiate between two intertwined dialogs. The same logical transaction ID (trans1) is used for all transactions, because each transaction is closed before the next transaction is started.
NOTE: In a non-intertwined scenario, where the first dialog is closed before the next dialog is started, the
Dial1logical dialog ID can be reused in the second dialog.
An example for intertwined transactions within a dialog is the early media call flow illustrated in Figure 4.
User agent A is emulated with Apache JMeter and two logical transaction IDs are used to differentiate between the 200 OK response to the PRACK request and the 200 OK response that closes the INVITE transaction. trans1, which is the logical transaction ID for the SIP messages within the INVITE transaction, is reused after the INVITE transaction is closed.
