[reSIProcate] I have a suggestion on the Docs, and even can guide the efforts.
Hi,
As usual, every Tuesday, I go back to the WIKI and try to figure out
what new things are added.... See my previous post on this issue.
So, as I look at the USE OVERVIEW, I see some things we
really need to add to it... the current material is WAY TOO
SPECIFIC, and give us novice users NO CLUE how the overall
design works, so I propose the addition of another topic
at the very beginning...
Resipricate Parts and typical ways it can be used...
SIPPhone
=========
Cover the construct of the important parts needed for implementation
of a SIP phone. It should specify...
a) How many of the key objects are needed... IE: one SipStack,
one DUM, one AuthManager, one AppDialogSet for each ongoing call,
etc (I might be wrong here - because I STILL don't know). Also
typical methods or data items each is supposed to handle like state
flags, and other important info is all left out.
b) What happens and what gets constructed when a SIP call is made?
Is this when I'm to construct my AppDialogSet, Factories, and such?
Is the AppDialogSet the best place to keep my state flags? What
kinds of things am I going to need when I get a sucessful INVITE...
Obviously I'm going to need the IP/port, protocol, the best Codec
to use, whether or not they want encryption, what kind of encryption,
etc... Where do I get this data?
c) RE-INVITE - I presume this is when I want to call someone else?
or is it when I want to try and re-establish a call to the same user.
c) What happens when the call needs to be ended. Which of the
objects we don't need anymore.
e) What happens when the call is busy, no answer, or no such user...
what Callbacks get called for each of these, their names, their main
handler subclasses that handle it.
f) What objects need to be created when the SipPhone starts up
g) What happens when the call is "connected" and what kind of
information needs to be passed to the RTP stack like IP/Port/Protocol,
and how to extract the remote client's information, like what codecs
are available, protocols, IP/port... and how to get this information
from the
response I get back from the initial sucessful Invite.
h) What happens when I want to Log into another SIP server?
How do I "break off relationship" with one server, and get a clean
relationship with another one.... Which objects do I create?
Do I ditch the old AuthManager and make a new one, or can
I keep the old one and give it new parameters? I've already
looked at every object in the resip stack... lots have setter
functions, some dont... some are const and can't be changed,
others aren't and because of this, I can make educated
guesses, but that's all they are - just guesses.. and when
compile times take more then 15 mins, guessing is just NOT
a very fast way to develop a SIP phone for the Mac.
So far, none of this is covered or included in the Overview docs in the
WIKI
and it SHOULD be... also what's there is very very specific, it's
like trying
to find the forest through the trees... All I see is a closeup of a
tree, I
don't see the forest... My vision is not wide enough... Sure it is
important to
deal with Headers and HeaderTypes, parameters and contents or whatever.
but how is this used? I'm sure a lot of this is beyond the scope of the
resip,
but some more xamples are really needed. It doesn't have to be buildable
sample code ALL the time, but more sample code is always needed, and
it just has to identify typical use.
Let me give you another example... lets look at "Body" section... we have
all of these things... like RequestLine, StatusLine, Auth... lets take
Dataparamter for instance...
DataParameter
RFC name:
token
Description:
Quoted or unquoted. Unquoted must be single word.
Example:
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Parts:
accessor reSIP type settable
------------------------------------------------
value() Data yes
isQuoted() bool no
setQuoted(bool) void yes
So - lets assume I have a "Message" - then if I want to see the value of
the dataparameter, would I do...
myMessagePtr.dataParameter->value(); or would
I do myMessagePtr->header(h_ DataParameter).value(); or would I do
something
else? I think the latter and I'm just using this as an example.
There is NO example in ANY of the illustrated body parts that tell
me how to construct the proper syntax, so they should also have
for each of these....
example: assuming myMessagePtr is a pointer to my message, then
to get this, I would:
myDataParamValue = myMessagePtr->header(h_ DataParameter).value();
(assuming I did this right - STILL not sure of course)...
I'm having to guess most of these, and I discovered I'm often led astray and
usually wind up picking the WRONG object, because each Object often has
multiple methods of same name (but with different arguments and returned
values), although the compiler can catch these early, compiler errors are
often ambigious, and lead me in the wrong direction and very often
choose the
wrong one and can spend days and days
trying different things (with each try costing me 15 mins to
edit-compile-link),
when all I really need is a single line of example code for each one...
and for the most part - none of my earlier questions have been answered
(I hope
my mailer is not broken), and I wind up posting 3 or 4 times over several
weeks.... Obviously, this is a non issue to most in the list, because
they've
been on the ground floor for the initial design, and know exactly what to
choose. I dont... I've been working on this now for ONE MONTH and still
don't have INVITE working, nor do I know how to extract data from the
response from the invite... It's no WONDER nobody wants to write a
SIP phone for the Mac...
How many are working on a sip phone for the Mac? Out of those, how
many are willing to share their code? I'm still waiting for a response
on some feedback from some code I sent to Alan.... that was a few
weeks ago... I know everyone is super busy, just asking for someone
to spend 10 - 20 mins taking a look at some code I wrote just so
they can guide me on proper use of the stack, is taking nothing less
then an Act of God... At least until someone gets around to completing
the WIKI and making a Guildeline for Dummies, I'm pretty much
stuck in a quagmire... making very slow progress...
I remain...
John