#3 Transaction dictionary sometimes applied to the wrong trans

[nnp]

There is currently no link between the transactions stored by the transaction manager and the transaction dictionaries that describe the transaction.

As a result when sip_agent processes a transaction dictionary it is possible that an update for an unexpected transaction could occur and sip_agent will attempt to apply the current transaction dictionary to it. This will either result in a failure (if the unexpected response is of the wrong type) or (if the response is of the right type) a response will be generated for that transaction and the transaction the dictionary was intended for will be ignored.

Code should be added to store a copy of the transaction dictionary with the transaction itself in the transaction manager. In this case, the transaction could be processed whenever a response arrives as opposed to putting the response on a queue and waiting for the sip_agent to deal with it.

Other changes would have to be made to how a transaction is processed though. For example, in the current system the fuzzer tells the sip_agent what it expects and the sip_agent then reads off a queue from the transaction manager and attempts to match this to what the fuzzer is expecting. If the transaction manager is now automatically responding based on a transaction dictionary the sip_agent is going to have to be able to request the status of a transaction from the transaction manager and *then* act.

It will also be necessary for sulley to be able to initiate a transaction (e.g via an fuzzed invite) and have the transaction id variables made available so the transaction can later be identified in the post_send methods but this is less important for now as the focus is on testing servers which don't really require an INVITE transaction to be CANCELed and any other SIP verbs don't require a follow up of a fuzzed initial request