[reSIProcate] The "role" of the resip objects... and my understanding 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