the use case for which I wrote the module is the following. Suppose that your service is mobile oriented and thus you are using "push" (APN, GCM or custom one) mechanism to reach your customers' devices. The devices are not registered most of the time, they do after receiving a push triggered by an incoming INVITE.

In a real scenario a user could have some "traditional" SIP devices always registered, some Android devices and some iOS devices. You don't know how many devices the customer has, you don't know how many devices are reachable by push at the moment you send it, you don't know how much time it will take for each device to register and maybe some will never receive the push. So, in the traditional way the lookup is done, you have to wait for all the devices to register or take some arbitrary decision on when stop waiting and sending out the INVITE. 

This is the use case I wrote the module for: as soon as the first device registers you send out the INVITE and when other devices for the same AOR register you keep adding branches to the transaction previously stored with ts_store().

It seemed to me that this was the simplest and more effective way to manage this scenario. At the beginning I though that it would be enough to write a function for the tmx module but then things got too complicated with the dependencies from the TM and the REGISTRAR module, so it was decided to have a dedicated module. Maybe some other use cases can be addressed by it.

Hope I have been clear enough, maybe I should write a tutorial to better explain this.

Regards,

Federico