< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

[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.
>