[reSIProcate] Dum multi-call design

Thu May 12 13:35:10 CDT 2005

Thanks for the AppDialogSet::end() tip.  

The only comment I have on doing this is that there is no way to use the
same resip information to when mapping a user-defined key for a particular
invite session call.  If I am the UAS, then I handle onNewSession and can
map my key to the actual invite session.  If I am the UAC, I map my key to
the AppDialogSet, which allows me to call end() for the call if necessary.
If I am the UAC and want to modify the session for example, I still need
access to the actual InviteSession.  To do this as the UAC, I would have to
also wait for onNewSession and build the key to InviteSession mapping and
possibly delete the key-to-AppDialogSet as it is not needed anymore.

In the original e-mail thread the suggestion was to always map application
defined keys to AppDialogSet or AppDialog pointers, but I don't see how it
is easily possible to get at the AppDialog (for getInviteSession).

In either of the UAC or UAS scenarios, the AppDialogSet is always
accessible.  It would be nice to have a method to get the InviteSession
directly from the AppDialogSet (AppDialogSet::getInviteSession()).  I am a
novice on the library so this probably is not a valid suggestion.

Most likely if the DUM doesn't change, I will end up implementing this using
the AppDialogSet pointer temporarily until the onNewSession handler is
called for a UAC call.  Does anyone see any problems with this method?

Thanks.

-Justin

  _____  

From: Derek MacDonald [mailto:derek at xten.com] 
Sent: Thursday, May 12, 2005 1:58 PM
To: 'Justin Matthews'; 'sachin ahire'; slgodin at icescape.com;
resiprocate-devel at list.sipfoundry.org
Subject: RE: [reSIProcate] Dum multi-call design

If you are canceling an outgoing call where there hasn't been a prov.
response you should call AppDialogSet::end().  If there have been
provisional responses and you wish to cancel a particular dialog, using the
InviteSession is the way to go.

AppDialogs are created and destroyed when a SIP dialog is created and
destroyed; you should use AppDialogSet::createAppDialog.  There is no
destroy() method as there is no use case yet for sharing AppDialogs.

--Derek

CONFIDENTIALITY NOTICE

This email and any files transmitted with it contains proprietary
information and, unless expressly stated otherwise, all contents and
attachments are confidential. This email is intended for the addressee(s)
only and access by anyone else is unauthorized. If you are not an addressee,
any disclosure, distribution, printing or copying of the contents of this
email or its attachments, or any action taken in reliance on it, is
unauthorized and may be unlawful. If you are not an addressee, please inform
the sender immediately and then delete this email and any copies of it.
Thank you for your co-operation.

  _____  

From: resiprocate-devel-bounces at list.sipfoundry.org
[mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of Justin
Matthews
Sent: Thursday, May 12, 2005 10:24 AM
To: 'sachin ahire'; slgodin at icescape.com;
resiprocate-devel at list.sipfoundry.org
Subject: RE: [reSIProcate] Dum multi-call design

Hi,

I have been thinking about this implementation and am confused on exactly
how to manage the AppDialogSet and AppDialog pointers.

The ultimate goal is to be able to cancel an outbound invite if there is no
response from the UAS.  When creating an Invite with
DUM::makeInviteSession(.,myAppDialogSet), I clearly have a way of mapping a
user-defined key (integer or whatever) to myAppDialogSet.  I can use this
user-defined key to get a pointer to myAppDialogSet for this call.  Where I
am confused is what I really want is a myAppDialog pointer to call
myAppDialog->getInviteSession().  To do this I need a pointer to
myAppDialog.  I suppose this could be done in
myAppDialogSet::createAppDialog() (maybe this won't work; when does a
AppDialog get created?) by adding another mapping from a user-defined key to
myAppDialog.  If I do this, how do I know when myAppDialog is deleted by
resip?  AppDialogSet gives a virtual destroy() method, but AppDialog does
not.

Thanks,

-Justin

  _____  

From: resiprocate-devel-bounces at list.sipfoundry.org
[mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of sachin
ahire
Sent: Friday, April 01, 2005 4:11 PM
To: slgodin at icescape.com; resiprocate-devel at list.sipfoundry.org
Subject: RE: [reSIProcate] Dum multi-call design

Hi Scott,

Thanks for the pointers. The website link was helpful since that site
contains quite a lot of other useful documentation also. 

i also understand what you meant by not getting response from the UAS side.
i was expecting to get the OnFailure or OnTerminated Callback since my uas
wasnt setup to send any response, but never got it. i guess the app needs to
maintain the timer for such cases and send the cancel. 

Sachin

>From: Scott Godin <slgodin at icescape.com> 

>To: 'sachin ahire' <sachinahire at hotmail.com>,
resiprocate-devel at list.sipfoundry.org 

>Subject: RE: [reSIProcate] Dum multi-call design 

>Date: Thu, 31 Mar 2005 14:53:35 -0500 

> 

>That will probably work - but you won't know the Invite Session Handle on 

>placed calls until a dialog is created.  I store an array of AppDialog and 

>AppDialogSet pointers.  This allows you to end/cancel a call if you don't 

>receive any response from the far end.  You can get at the InviteSession 

>from these pointers. 

> 

> 

> 

>Check out: 

>http://warsaw.sjc.purplecomm.com/wiki/index.php?title=Associating_Applicati
o 

>n_Data_with_Dialogs/DialogSets 

><http://warsaw.sjc.purplecomm.com/wiki/index.php?title=Associating_Applicat
i 

>on_Data_with_Dialogs/DialogSets> 

> 

> 

> 

>Just be careful to remove references from your array before the Dialogs are

>destroyed - since DUM will delete the AppDialog/AppDialogSet objects. 

> 

> 

> 

>   _____ 

> 

>From: sachin ahire [mailto:sachinahire at hotmail.com] 

>Sent: Thursday, March 31, 2005 11:36 AM 

>To: resiprocate-devel at list.sipfoundry.org 

>Subject: [reSIProcate] Dum multi-call design 

> 

> 

> 

> 

>Hi, 

> 

>I want to develop an application based on basiccall.cpp  in the dum/test to

>enable sending multiple calls/invites and also an ability to receive 

>multiple calls. 

> 

>The way i was going to do it was to have an array of lines that contains a 

>pointer to the InviteSessionHandler and everytime the app receives a 

>OnNewsession i grab one of the "unallocated" lines and copy the handle and 

>use it to keep track of invitesessions. 

> 

>Is this a right way to do it or if not, can somebody give me some pointers 

>as to how it can be done. Thanks. 

> 

>Sachin 

> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20050512/39527b06/attachment.htm>