RE: [reSIProcate] The "role" of the resip objects... andmyunderstanding of them
- From: "Alexander Altshuler" <alt@xxxxxxxxx>
- Date: Mon, 10 Oct 2005 22:22:21 +0400
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