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
>