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

RE: [reSIProcate] The "role" of the resip objects...andmyunderstanding of them


Alexander,


thanks for the clarification. Of course you are right.

To subclass you need to implement the methods of 
InviteSessionHandler like

::onNewSession(resip::ServerInviteSessionHandle h,
        resip::InviteSession::OfferAnswerType oat,
        const resip::SipMessage& msg)

and

:onNewSession(resip::ClientInviteSessionHandle h,
        resip::InviteSession::OfferAnswerType oat,
        const resip::SipMessage& msg)

>From the type of handle (h being either Client... or
Server...) you will know if it is an incoming our outgoing 
call.

Thanks,

Matthias




> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of
> Alexander Altshuler
> Sent: Montag, 10. Oktober 2005 20:22
> To: 'Resip Devel'
> Subject: RE: [reSIProcate] The "role" of the resip
> objects...andmyunderstanding of them
> 
> 
> Hi
> 
> One thing below is incorrect:
> 
> > - ClientInviteSessionHandler
> >  (receive callbacks from outgoing calls
> 
> >- ServerInviteSessionHandler
> >  (receive callbacks from incoming calls)
> 
> Application developer must provide subclass of InviteSessionHandler to
> handle both incoming and outgoing calls.
> 
> Regards,
> Alex
> 
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On 
> Behalf Of Matthias
> Moetje
> Sent: Sunday, October 09, 2005 7:18 PM
> To: John Draper
> Cc: Resip Devel
> Subject: RE: [reSIProcate] The "role" of the resip objects...
> andmyunderstanding of them
> 
> John,
> 
> I can understand your feelings. I had the 
> same problems and you are absolutely correct
> that this stuff is really badly documented
> and you really need to dig into the stack 
> and its classes to find out how things are
> supposed to be used. Also the terms of client
> and server are used differently as in the 
> actual SIP RFC, so don't get confused by this.
> 
> Here are some of my findings/suggestions:
> 
> The main application class should contain:
> 
> - one stack object
> - one dum object
> - one dum thread object
> - one stack thread object
> 
> It should inherit from:
> 
> - ClientInviteSessionHandler
>   (receive callbacks from outgoing calls
> 
> - ServerInviteSessionHandler
>   (receive callbacks from incoming calls)
> 
> - ClientRegistrationHandler
>   (for handling registrations)
> 
> 
> You should also have a call object. An AppDialogSet
> is equivalent to a call (a call can have several
> AppDialogs = request/response). The call object
> could probably inherit from AppDialogSet.
> Though, I decided to create a class like TestAppDialogSet
> in the BasicCall example which has a pointer to
> my class object. I also create an AppDialogSet factory
> which is reponsible for creating a TestAppDialogSet
> object for incoming calls (for outgoing calls 
> you create the object yourself).
> 
> In the main app class where you receive callbacks
> you can cast the handles (like InvitSessionHandle)
> to your TestAppDialogSet object from which you 
> can get a pointer to your call object.
> 
> I think once you have understood these procedures,
> the rest is easy to find out.
> 
> Best regards,
> 
> Matthias Moetje
> 
> 
> 
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx]On 
> > Behalf Of John
> > Draper
> > Sent: Sonntag, 9. Oktober 2005 01:47
> > To: Resip Devel
> > Subject: [reSIProcate] The "role" of the resip objects... and
> > myunderstanding of them
> > 
> > 
> > Hi,
> > 
> > I'm trying to get a better understanding of the role of some 
> > of the major
> > reSIProcate objects.  Alexander pointed out something to me I just 
> > didn't know
> > about....  let me explain it here, so others may not fall 
> in the same 
> > "trap", and
> > from observing some of the questions posted, it is very clear that 
> > others may
> > need to know this as well.
> > 
> > As you know, there is an infinate number of object models one can 
> > deploy,  but
> > in my case, it's just a very simple SIP Phone.
> > 
> > The resip apparently expects developers to sub_class from a 
> number of
> > resip base classes like RegisterHandler, InviteHandler,  etc.
> > 
> > Typically, one would implement an "Application" object taking the 
> > overall role
> > of ALL of the fuctions of a program using resip,  IE:  Sip 
> Phone,  or 
> > Server.
> > In MY case, it's a SIP Phone....  It is the overall object that get 
> > instantiated
> > when the program is started up,  handles events, threads, 
> > network, audio
> > and is responsible to instantiating them where appropriate.
> > 
> > In the case of the DUM/test/BasicRegister.cxx,  they include 
> > ALL of the
> > SIP code in a single function, making it not so clear how I 
> > can relate it
> > to an "Application",  because there is nothing for it to do,  
> > so I would 
> > have
> > NO CLUE what an "Application" is supposed to do.  I know what MINE
> > needs to do,  and I've tried to explain it below.
> > 
> > Am I to assume that in MY SIP phone application, that my main 
> > application
> > is to inherit from "public AppDialog"?   Or would my main 
> > program inherit
> > from AppDialogSet?  It would seem to me that AppDialogSet would be
> > the parent for my main SipPhone Application,  right?  Because 
> > AppDialogSet
> > knows how to create AppDialogs....  NOTE:  Because the typical Mac
> > "Application" is based on Objective C,  I'm NOT attempting to
> > subclass from NSApplication (an Obj C object representing a Mac 
> > Application).
> > I'm treating the sipApplication seperately through a 
> "bridge" module.
> > 
> > In MY case of a simple SIP Phone, wouldn't I just have a single 
> > AppDialogSet?
> > and what is the persistancy of an AppDialogSet?   Does it 
> > live as long 
> > as the
> > entire program as it's running,  even when not engaged in a 
> > call?   And is
> > an AppDialog created everytime I engage in a call when using 
> > the SIP Phone,
> > which I get from "myAppDialogSetFactory"?
> > 
> > Then there are the handlers...  Most of this stuff makes 
> sense to me.
> > It's just setting up callbacks and "hooks" into the functionality of
> > what the application is supposed to do - IE:  Be a SIP Phone.
> > 
> > I got my Registration handler running - seems to work great and does
> > what it's supposed to do...  but again, what is the lifetime 
> > of the handler?
> > Do I ditch it when the call is completed,  or do I put it in 
> > an "Unused" 
> > state?
> > or does a piece of it live until the next Registration is 
> > requested.  Will
> > there be an instance where I would want to have more then one?   IE:
> > register to more then one SIP server?  In MY case,  the 
> > decision is made,
> > I'm just having one.
> > 
> > The "Invite" also uses a AppDialogSet, and it uses an 
> > "mSampleAppData".
> > Obviously for testing purposes,  but what kinds of 
> > information should I
> > want to put in here for my SIP Phone Application.  I'm 
> considering...
> > 
> >   mMySipAddress - my login'ed user ID
> >   mResponse         - my sucessful response,  from which I 
> > get more info 
> > from
> >        server
> >   mBridge             - My resip --> Obj C bridge.
> >   registered         - true of registered.
> > 
> > These would be in myAppDialogSet object.
> > 
> > I also might have references to some Objective C Objects which is
> > mostly used with the Mac GUI for updating status messages, 
> > extracing URI's from the Mac Window static_text GUI fields,
> > etc.
> > 
> > I assume that from now on,  my AppDialogSet is going to have 
> > a full life
> > ahead of it until the SIP Phone quits,   right?
> > 
> > When I INVITE to make a call,  do I use the same AppDialogSet as
> > the one I used to REGISTER?  
> > 
> > Also, in this case,  when I INVITE,  my Invite then generates a
> > AppDialog?   Is that correct?   In my case, since I'm just 
> > implementing
> > a simple SIP Phone,  I only want ONE AppDialog,   right?  
> > But,  later on,
> > if I decide to allow for conference calls,  then I can have Multiple
> > INVITES (and multiple AppDialog's),  right?   Or do I 
> > generate a single
> > AppDialog when I "register" and use it all the time?  I 
> > prefer the first
> > option of course.
> > 
> > So,  in MY case,  my subclass of an AppDialog is going to need the
> > following Information...
> > 
> >    connected       - true if connected
> >    mRemoteUser - NameAddr of the remote user
> >    mRemoteIP     - remote IP address
> >    mPortNum       - remote port
> >    mTimeStamp   - time stamp - initialized just when connected.
> >    mRTPSession   - RTP Session
> > 
> > It's also going to need to handle the following functions
> > 
> >    CreateRTPSession - upon an "OnConnected" handler callback,  the 
> > handler will call this
> > to create an RTPSesstion.
> > 
> >    DeleteRTPSession - upon call getting torn down.
> > 
> > All of these relate to a "Call" or the duration of the call.
> > 
> > Anyway,  this is my interpretation of my undeerstanding of 
> how to use 
> > the SIP Stack
> > and the relationship between the AppDialog and AppDialogSet.
> > 
> > If it is evident from reading this, that I'm full of "barnyard 
> > substance", please
> > please light up that torch and light me up....  I don't mind 
> > flamage...
> > 
> > If, I'm wrong,  example code would be greatly appreciated,  
> > It doesn't 
> > have to
> > compile of course,  just show how the arguments are inserted 
> > and the results
> > are handled.
> > 
> > And last but not least, I'm trying to figure out what code I have to
> > put in my handlers.  Some are obvious,  others are not.  Docs 
> > are still
> > not very clear on that, and since nobody has ever released an Open
> > Source SIP Phone using resip,  there is NO guidelines on where to
> > put things.
> > 
> > John
> > 
> > 
> > _______________________________________________
> > 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
>