Hi Alex,
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.