| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
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@xxxxxxxx] 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@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Justin Matthews 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@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of sachin ahire 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@xxxxxxxxxxxx> >To: 'sachin ahire' <sachinahire@xxxxxxxxxxx>,
resiprocate-devel@xxxxxxxxxxxxxxxxxxx >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_Applicatio
>n_Data_with_Dialogs/DialogSets ><http://warsaw.sjc.purplecomm.com/wiki/index.php?title=Associating_Applicati
>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@xxxxxxxxxxx] >Sent: Thursday, March 31, 2005 11:36 AM >To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx >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 > |