reSIProcate

Mailing Lists

Source Code

Google Search:



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

RE: [reSIProcate] Track invite sessions

The attached email chain should help clarify a few things...

-----Original Message-----
From: Dominique Prunier [mailto:dominique.prunier@xxxxxxxxxxxxxxxxxx] 
Sent: Thursday, August 19, 2004 6:27 AM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate] Track invite sessions

Hi,

I'm a writing a SIP driver and i need to manage several simultaneous
outgoing calls (no imcoming call yet). Then, i wonder what is the best way
to track invite sessions from creation to termination (succesfull or not).
Actually, i'd like to know how to identify a session when callbacks are
called. I think it has something to do with AppDialogSet but i have no idea
how to use it and especially how to know, from an InviteSessionHandler,
which AppDialogSet it belongs to.

Thanks for your anwser.

Regards,

Dom.

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
--- Begin Message --- 
Hi Derek,

Thanks again for this reply.  I've been milling over what you said and the
code to try and understand the AppDialog stuff.  Here is my current
understanding - please correct me if I'm wrong:

1.  Our application should create classes inherited from AppDialog,
AppDialogSet and AppDialogSetFactory.  These classes can then contain any
application specific data.
2.  For the client side - when a new dialog is to be created.  We create one
our AppDialogSet inherited objects and pass it into the DUM make....
functions.
3.  For the server side - we override createAppDialogSet function from
AppDialogSetFactory so that our object (inherited from AppDialogSet) is
created instead of the base AppDialogSet object.
4.  The handlers can get at data in the AppDialog by calling getAppDialog()
and casting the result to the inherited class.

For example - In this case the user data is just a DWORD...

class TestAppDialog : public AppDialog
{
public:
        TestAppDialog(HandleManager& ham, DWORD dwAddressID) :
AppDialog(ham), m_dwAddressID(dwAddressID)
        {
                InfoLog(  << "TestAppDialogSet::TestAppDialog: " <<
m_dwAddressID);
        }

    virtual ~TestAppDialog()
        {
                InfoLog(  << "TestAppDialog::~TestAppDialog: " <<
m_dwAddressID);
        }

        DWORD m_dwAddressID;
};

class TestAppDialogSet : public AppDialogSet
{
public:
        TestAppDialogSet(DialogUsageManager& dum, DWORD dwAddressID) :
AppDialogSet(dum), m_dwAddressID(dwAddressID)
        {
                //InfoLog(  << "TestAppDialogSet::TestAppDialogSet: " <<
m_dwAddressID);
        }

    virtual ~TestAppDialogSet()
        {
                //InfoLog(  << "TestAppDialogSet::~TestAppDialogSet: " <<
m_dwAddressID);
        }

    virtual AppDialog* createAppDialog(const SipMessage& msg)
        {
                //InfoLog(  << "TestAppDialogSet::createAppDialog: " <<
m_dwAddressID << ", " << msg.brief());
            return new TestAppDialog(mDum, m_dwAddressID);
        }

        DWORD m_dwAddressID;
};


class TestAppDialogSetFactory : public AppDialogSetFactory
{
public:
        virtual AppDialogSet* createAppDialogSet(DialogUsageManager& dum,
const SipMessage& msg)
        {
                //InfoLog(  << "TestAppDialogSetFactory::createAppDialogSet:
" << msg.brief());
                return new TestAppDialogSet(dum, 1120000);
        }

};


Client side sample code:
TestAppDialogSet *tads = new TestAppDialogSet(dumUac, 1110000);
dumUac.send(dumUac.makeInviteSession(uasAor.uri(), uac.sdp, tads));

Handler Sample code:
....
 virtual void 
 onNewSession(ServerInviteSessionHandle sis, InviteSession::OfferAnswerType
oat, const SipMessage& msg)
 {
      InfoLog( << "[" << ((TestAppDialog*)sis->getAppDialog().get())-
>m_dwAddressID << "] TestUAS::onNewSession(ServerInviteSessionHandle): " <<
name << " "  << endl << msg);
      mSis = sis;  
      sis->send(sis->provisional(180));
 }

Is this the way the AppDialog stuff was intended to be used.

Thanks for taking the time to read this over.

Scott

PS.  I've attached the complete sample I've been playing with.



-----Original Message-----
From: Derek MacDonald [mailto:Derek@xxxxxxxx] 
Sent: Monday, June 28, 2004 5:45 PM
To: 'Scott Godin'
Subject: RE: [reSIProcate] DUM state & design

Hi Scott,

To start, I've been lax in updating basicall, as I've been hacking it a lot
to chase down bugs.  I'll check a more concrete version in soon(later
today).  As for a target date, I want to have basic sip functionality(calls,
transfer, redirect) hacked out in a couple of weeks.  Then the great corner
case chase will begin.  InviteSession is getting fairly solid.

Question 3 is interesting, and has ramifications about where the design of
DUM might go.  For now, there is a userdata concept.  You can(and probably
should) pass AppDialogSet obejcts to the various create events, as well as
set an AppDialogSet factory on DUM for server-side objects.  The lifespan of
the AppDialog/AppDialogSet is the same as the lifespan of the associated
DialogSet or Dialog.  So, instead of storing session handles, you should use
AppDialog objects(and the constructor and destructor) to manage your
appication data.  I'm adding convienience methods to navigate from AppDialog
objects->usages today.  In the future, we expcet that the userdata and the
handlers will merge, as I suspect you will currently just end up using the
handlers to dispatch to an object that has a one-to-one correspondance w/
the appropriate appdialog usage.

I think you can starting implementing against DUM later today if you are
just using InviteSession; later this week if you need re-invite. There will
be some API shift once enqueue enters the fray, which will affect SDP
management, but nothing to major on the client side.  It would be great to
have other ppl testing this.

--Derek

PS -- you can find me on yahoo im, my id is: can_dcm

-----Original Message-----
From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
Sent: Monday, June 28, 2004 2:02 PM
To: Derek@xxxxxxxx
Subject: RE: [reSIProcate] DUM state & design


Hi Derek!

I'm very interested in porting our current integration from the old Dialog
class to the new DUM stuff you guys have been working on.  Thanks for all
your hard work!

If you have a few seconds - I have a few questions:
1.  Is there a target date for completion?
2.  Are you guys using a different test harness (other than BasicCall) -
that is more complete?  It doesn't look like basicCall is fully functional
right now.  If so - can I get a copy to help me understand the
implementation more?  PS.  I've already read the little bit of documentation
in the doc dir.
3.  Is there a way for me to query the active sessions (ie. Invite, etc) for
a particular CallID or DialogID?  I'm trying to determine what to store in
my application - either Session pointers or CallID's/DialogID's - since we
need to manage multiple dialogs.

FYI - Our application manages multiple SIP sessions - up to a couple hundred
sessions.  It is essentially a SIP gateway imbedded into an IVR/ACD product.
We use NMS boards for the RTP streaming.  There for my main interest lies in
the InviteSession, and SDP Management.

Thanks,

Scott Godin


-----Original Message-----
From: Derek MacDonald [mailto:Derek@xxxxxxxx]
Sent: Monday, June 28, 2004 4:03 PM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate] DUM state & design

So, the basic InviteSession API's are fairly cooked and implemented,
although Enqueue/etc could change things.  The AuthManager needs some work,
but 401/407's are being handled in the basic invite/register cases.

I'm going to start hacking PUBLISH/SUBSCRIBE/NOTIFY and the design there
doesn't look particuarily cooked. I've changed the headers to more closely
reflect other API's, but opinions are welcome.

David and I were talking about it, and we think Publish is another type of
usage(def. not a sip dialog, but it has a lifespan) that looks similar to
Registration, w/out the Call-ID being re-used. It seems incorrect that a
Dialog can only have one ServerSubscription but many ClientSubscriptions, so
I'm going to change that barring a compelling reason.

On another topic, I'm adding navigation methods to the AppDialog userdata
that will allow a user to retrieve an invite or sbscription usage.  This
will do for now, but it seems likely that handlers and userdata will be
merged.

--Derek


_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel

Attachment: BasicCall.cxx
Description: Binary data


--- End Message ---