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

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