[reSIProcate] Re: Changes to resiprocate/dum interfaces (IMPORTANT)
There are interface changes in resiprocate that you will need to read
about!! See below.
I am merging the branch b-dev-repro-20050401 back to main today. If
you have anything modified in your view in this branch, please switch
to main before checking it in.
The branch was at
https://scm.sipfoundry.org/rep/resiprocate/branches/b-dev-repro-20050401
Once the merge is checked in, you can use the following command to
switch back to main from the branch:
svn switch https://scm.sipfoundry.org/rep/resiprocate/main/sip sip
---------------------
The merge was done using the following commands: (just for reference):
// check out a clean copy of main trunk
mkdir merge
cd merge
svn co https://scm.sipfoundry.org/rep/main/sip
// merge changes from branch
svn merge -r 4155:4334
https://scm.sipfoundry.org/rep/resiprocate/branches/b-dev-repro-20050401
// edited conflicts manually
svn commit -m "merged changes from b-dev-repro r4155
On Apr 4, 2005 12:43 AM, Fischl jason <jason.fischl@xxxxxxxxx> wrote:
> In the latest work session we've done some refactoring of resiprocate
> to support having multiple Transaction Users (TU) in a resip-based
> application. There are a few implications and interface changes.
>
> - DialogUsageManager constructor now must take a SipStack&
> - UserProfile::setDigestCredential no longer takes an aor argument
> since the UserProfile is already bound to an aor
> - Applications can have multiple TransactionUsers (e.g.
> DialogUsageManager or Proxy). Each TU needs to register with the
> TransactionUserSelector using this interface
> SipStack::registerTransactionUser(TransactionUser& tu). The
> DialogUsageManager will do this for you in its constructor.
>
> Keep in mind that this means your application needs to make a SipStack
> and pass it into the DialogUsageManager. If you are creating multiple
> TUs you should share the same SipStack with each of these.
>
> Each incoming message is matched against the list of TUs that have
> been registered with the SipStack. More to follow on this topic.
>
> As a convenience, there are two classes which help you run your
> DialogUsageManager and/or SipStack in their own threads. For example,
> if you were writing a presence server or registrar, you could use the
> following approach:
>
> SipStack stack;
> StackThread stackThread(stack);
>
> DialogUsageManager dum(stack);
> DumThread dumThread(dum);
>
> stackThread.run();
> dumThread.run();
> stackThread.join();
> dumThread.join();
>
> If you are implementing a useragent such as a softphone that might
> have a gui component running the same thread as the dum, use this
> approach instead:
>
> SipStack stack;
> StackThread stackThread(stack);
>
> DialogUsageManager dum(stack);
> stackThread.run();
>
> while (!shutdown) // some local variable
> {
> while (dum.process());
> // do your gui stuff here.
> }
> stackThread.join();
>
> You can also run without a StackThread if you'd like everything to run
> in a single thread.
> SipStack stack;
> DialogUsageManager dum(stack);
> while (!shutdown) // some local variable
> {
> try
> {
> resip::FdSet fdset;
> buildFdSet(fdset);
> stack.buildFdSet(fdset);
> int ret = fdset.selectMilliSeconds(stack.getTimeTillNextProcessMS());
> if (ret >= 0)
> {
> stack.process(fdset);
> }
> }
> catch (BaseException& e)
> {
> InfoLog (<< "Unhandled exception: " << e);
> }
>
> while (dum.process());
> // do your gui stuff here.
> }
>
> There will be more to follow on how to use the new Proxy TU - as well
> as how to use the Proxy TU in conjunction with one or more User Agent
> TUs.
>