...
Signaling services such as sipXbridge are message driven finite state automata. i.e. from an external perspective they are driven by SIP signaling messages that appear at a port and they generate messages as a result of such messages. The important thing with testing such components is to send requests to and expects requests and responses from the SUT in the same order as a working test case does. The regression is a stimulus response tester which tries to maintain the same message ordering as was observed in a trace. The diagram below shows the setup : 
The regression test tool (RT) is meant to test a single component in isolation by emulating actual call flows. Emulation in this case consists of presenting the SUT with a sequence of SIP requests which are suitably re-written. It is not meant to be a system tester i.e. it does not test signaling through multiple hops. RT reads a trace of a successful interoperability test that is presented as a suitably filtered "merged.xml" file (i.e. the output of sipx-trace with appropriate flags to isolate the call Id's of interest. It then consults a second configuration file (monitored-interfaces.xml) that indicates which IP addresses and ports in the captured merged.xml are of interest. A third configuration file (testmaps.xml) specifies an address mapping between a given trace message and an emulated trace message. As each message is presented to the SUT, it is suitably re-written by consulting this configuration file. Finally, the tester address and base port are configured in tester config.xml
Trace driven Emulation SIP Call Flows
Mapping SIP Addresses
...