IMSDroid/doubango architectural limitations

```
This is not a defect report, more like a request for comments on the
IMSDroid/doubango architecture.
First of all, I would like to explain the problem I am facing, then I will give
couple possible solutions, and, after that, ask the questions that I already
have.
Problem: I need to know the exact production limits of the IMSDroid application
on several devices currently present on the market, and how many simultaneous
conference conversations they are able to have. I mean, we can possibly handle
one encoder/decoder pair for h.263 video and pcmu audio encoder/decoder pair,
but what if a user makes one more connection to another sip server and makes a
video call there, will there be enough CPU/mem/etc to handle that one as well?
Solution: There are two possible ways to check that. One - to make changes to
the core itself, creating dummy encoder/decoder pair for audio and video, and
making calculations there just to eat the CPU time and memory and see how it
affects the overall performance. Another way is to establish a double sip
connection, make a double video call and check the performance.
Questions: Since the code does not compile in the given version ( see issue 30
), I was only able to try the second way. Everything went smooth at the
beginning - I've created another MyAvSession object, given another registry
information, was able to register and make a call with a given interface
without any problems, but all tries to setup a double video sending/receiving
failed. It seemed like there could not be two instances of VideoProducer
class, as soon as I made the MyAvSession's VideoProducer non-static (it was
required to have two separate sessions), I had faced the non-working program.
Further studying of the code revealed its source - the ProxyProducer.cxx code
inside bindings/common library, which is used for libtinyWRAP component
building. There, the method setActive, which is being used during
Proxy(Video/Audio)(Producer/Consumer) initialization, a static variable
instance is being used. It means, we cannot have two video producers or two
video consumers with the given architecture, am I right? Does that mean we
cannot process and show two separate video streams from the different sources
at the same time unless we rewrite the code library itself, or I am just
confused and missing something inside program's structure? Please, shed some
light. Thank you in advance.
```

Original issue reported on code.google.com by `volkov.r...@gmail.com` on 18 Aug 2010 at 9:54