Re: [reSIProcate] Need help with Handles
I also trying to store AppDialogSet objects. The problem is that I'd like to
create pool of these objects to avoid dynamic memory allocation, but it seems
it's not possible as stack deletes it. Am I right ?
The second problem is - how to check AppDialogSet isValid from different
threads.
I understand that AppDialog is created by stack, for example for call transfer
(REFER) second AppDialog object will be created. Is it correct ?
-----Original Message-----
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jason Fischl
Sent: Tuesday, September 19, 2006 5:20 PM
To: Nicolas LEGROS
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Need help with Handles
Yes. You've got it. That is the intent. Keep in mind that anything that is a
handle can throw an exception if it has been deleted. You can also ask the
handle if it is valid.
Jason
On 9/19/06, Nicolas LEGROS <Nicolas.LEGROS@xxxxxxxxx> wrote:
> Thank you for your answer!
>
> In fact it seems there're many way to get a communication id between DUM and
> the application.
> You said previously that we can store DialogIds, InviteSessionHandle (even if
> InviteSessionHandle seems to be the simpliest way).
> Can we also store AppDialogSet?
> Isn't it also simplier?
>
> When the callback onTrying(AppDialogSetHandle..); it's easy to find the
> context.
> When onNewSession(ClientInviteSessionHandle..) is called; we just have to
> call th getAppdialogSet() method to find out the context!
>
> What do you think about it?
> Nicolas L.
>
>
> -----Message d'origine-----
> De: jason.fischl@xxxxxxxxx [mailto:jason.fischl@xxxxxxxxx] De la part
> de Jason Fischl
> Envoyé: lundi 18 septembre 2006 16:52
> À: Nicolas LEGROS
> Cc: Kovar, William (Bill); Scott Godin; Benjamin Jacob;
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Objet: Re: [reSIProcate] Need help with Handles
>
> You can call getAppDialogSet on the dereferenced handle. See
> DialogUsage.hxx which is a base class of InviteSession.
>
> On 9/18/06, Nicolas LEGROS <Nicolas.LEGROS@xxxxxxxxx> wrote:
> > Thank you for your answer!
> >
> > But I've another question/problem:
> >
> > Before my application sends an INVITE message via DUM, I'll store some
> > private information concerning the call in a private structure (in my
> > application). Each call will have its own "context" with private
> > information.
> >
> > When a 1xx response will arrive, the onNewSession() callback will be called.
> > How can my application could know which call this response is linked?
> > Consequently in which "context" can I store my InviteSessionHandle.
> > I hope you understand my question!
> > Thanks by advance!
> > Nicolas L.
> >
> > -----Message d'origine-----
> > De: Kovar, William (Bill) [mailto:bkovar@xxxxxxxxx]
> > Envoyé: lundi 18 septembre 2006 16:08
> > Ŕ: Nicolas LEGROS; Scott Godin; Benjamin Jacob;
> > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > Objet: RE: [reSIProcate] Need help with Handles
> >
> > You should wait until the OnNewSession(Client....) is called.
> >
> >
> > Bill Kovar
> > Avaya Inc.
> > (732) 852-2609
> > bkovar@xxxxxxxxx
> >
> > -----Original Message-----
> > From: Nicolas LEGROS [mailto:Nicolas.LEGROS@xxxxxxxxx]
> > Sent: Monday, September 18, 2006 8:59 AM
> > To: Kovar, William (Bill); Scott Godin; Benjamin Jacob;
> > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [reSIProcate] Need help with Handles
> >
> > Another question concerning Handles!
> >
> > When the application wants to send an INVITE message (the application is in
> > this case a UAC), the makeInviteSession() will be called:
> >
> > Here's an example:
> > dum->send(dumUac->makeInviteSession(uasAor, uac.sdp, new
> > dum->AppDialogSet(*dumUac, "UAC(INVITE)")));
> >
> >
> > When I call this method, a new AppdialogSet is created.
> > But I'd like to get and store the InviteSessionHandle...Is it possible? If
> > yes, how can I get it?
> >
> > Or should I wait for the callback onNewSession(ClientInviteSession...) to
> > get the it?
> > In other words, when the application acts as a UAC, should I wait a 1xx or
> > 2xx response before I can get the InviteSessionHandle? Or can I get the
> > InviteSessionHandle just after sending my INVITE message?
> >
> > Thanks by advance.
> > Nicolas L.
> >
> >
> > -----Message d'origine-----
> > De: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] De la part de
> > Kovar, William (Bill) Envoyé: vendredi 8 septembre 2006 16:14 Ŕ:
> > Scott Godin; Benjamin Jacob; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > Objet: Re: [reSIProcate] Need help with Handles
> >
> > The solution Scott suggested (in the earlier post) was good but there is an
> > easier way. When the session is created (constructor), use the AppDialog to
> > always tag the session as a UAC when calling makeInviteSession(). Then,
> > when a ServerSession is created, tag it as UAS in the onNewSession(sish...).
> >
> > Always store handles as InviteSessionHandle (in the map) and if the handle
> > is valid, you can reach into the AppDialog and get the handle type. At this
> > point you know if it's client of server handle and can cast accordingly.
> >
> > What I was more interested is getting straightened out was which of
> > the
> > InviteSession.isConnected()...IsEarly()...IsAccepted() state calls
> > identify when ONLY the InviteSessionHandle is valid. Obviously
> > isConnected() tells me to only use the InviteSessionHandle, but I'm not
> > totally clear on IsEarly() and isAccepted().
> >
> > Any insight??
> >
> >
> > Bill Kovar
> > Avaya Inc.
> > (732) 852-2609
> > bkovar@xxxxxxxxx
> >
> > -----Original Message-----
> > From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> > Scott Godin
> > Sent: Friday, September 08, 2006 9:41 AM
> > To: Benjamin Jacob; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [reSIProcate] Need help with Handles
> >
> > One advantage of storing InviteSessionHandle's is that using them is more
> > efficient than calling findInviteSession, since a map lookup is not needed.
> >
> > > -----Original Message-----
> > > From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > > [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf
> > > Of Benjamin Jacob
> > > Sent: Friday, September 08, 2006 1:27 AM
> > > To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > Subject: Re: [reSIProcate] Need help with Handles
> > >
> > > Wudn't it rather be better to store DialogIds? actualy, i shud
> > rephrase
> > > that question, which approach is better, storing DialogIds or
> > > sessionHandles??
> > >
> > > You are anyway passed InviteHandles in the callbacks. Also, if
> > > needed you can procure the handles using dum->findInviteSession(DialogId).
> > >
> > > Ben.
> > >
> > >
> > > Kovar, William (Bill) wrote:
> > >
> > > > All,
> > > >
> > > > In building a B2B with DUM, which manages MANY calls, I
> > > > maintain a separate list of ServerInviteSessionHandle and
> > > > ClientInviteSessionHandle. I'm trying to merge these 2 lists
> > > > into a single master list of Handles. I know I can maintain the list as:
> > > >
> > > > map<key, InviteSessionHandle> TheList
> > > >
> > > > When I go to fetch a handle I don't know whether that handle
> > > > should
> > > be
> > > > cast to ServerInviteSessionHandle, ClientInviteSessionHandle of
> > > > InviteSessionHandle because I can't figure out which type it
> > > currently is.
> > > >
> > > > Is there way to know which type of handle is currently active??
> > > >
> > > > Bill Kovar
> > > > Avaya Inc.
> > > > (732) 852-2609
> > > > bkovar@xxxxxxxxx <mailto:bkovar@xxxxxxxxx>
> > > >
> > > >
> > >
> > >-------------------------------------------------------------------
> > >---
> > > -
> > > >-
> > > >
> > > >_______________________________________________
> > > >resiprocate-devel mailing list
> > > >resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > >https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> > > >
> > > _______________________________________________
> > > resiprocate-devel mailing list
> > > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >
> >
> >
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >
>
>
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel