Re: [reSIProcate] I have a suggestion on the Docs, and even can guide the efforts.
Alan Hawrylyshen wrote:
On Oct 25, 2005, at 15:39, John Draper wrote:
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...
The design of the stack is covered fairly well in the architectural
overview diagram at:
http://ln-s.net/8X2
I looked at this diagram and commented on it a long time ago ... I
recalled mentioning
the "blocks" in the diagram has very little relationship between the
resip "objects"
and the "Blocks" in the diagram.... but what would it look like of
these blocks
were replaced with "AppDialogSet", "AppDialog", and other resip objects
ommitted from the list. If they are all there, then "my bad" -
because they
have been given possibly different names, offering me no information on any
of the relationships... but the blocks in this diagram indicate
"function", but in
no way (with the exception of TransactionController, DialogUsageManagr, etc.
is it mentioned or indicated.
but is the block titled... "Application/DialogUsageManager" the same as
an AppDialogSet? On the other hand, in the diagram we have a
"transaction timer queue", and I don't see any associated source/header
files relating to that "object". If it relates to any other portion of the
code, then it should be mentioned in the diagram, but to be consistant,
i think we should use the SAME EXACT NAMES for the blocks.
What I would like to see, are several common usage diagrams, like SipPhone
SipProxy, whatever, but showing the "exact object names" indicated in the
source/header files, and lines connected to them, showing more then one
instances of some (where appropriate). NOW, THAT would be a really
important diagram for us "users".
I am positive that this has been mentioned several times before.
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...
John; asking for specific implementation details is not in good
taste, especially for a pet project.
They would make for more reasonable examples.... and more attuned to
what people would
really want to use it for. I'm just saying a "general" sip phone
implementation would be a
very excellent example program. I also believe the very best way to
document such a complex
system as a SIP stack is to have examples, and so called "implementation
details" one can use
as a guide, and I totally disagree with you and good or bad taste
should never enter the
equation....
There is an example application (Boston Bridge) implementation that
shows how to plug media into reSIProcate to get a simple conference
server. This is an interesting application and should serve as a good
conceptual guide for building a simple phone.
Care to divulge the URL? Google just has links to the Charles river
(obviously not talking about the
same thing).
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.
The reINVITE requests are simply in dialog INVITEs. If this doesn't
mean anything to you, then you need to read more about SIP. (See
below).
I read the RFC's several times. Yes...
c) What happens when the call needs to be ended. Which of the
objects we don't need anymore.
This is taken care of for you in DUM. There is some application
specific data possibly in your user space, but that would depend on
how you implemented and/or sub-classed the various parts of DUM.
Right - the end() method should do this, right?
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.
This is self explanatory in the code. See all the onFoo methods.
There are some I'm confused about - for instance, this one comes to mind...
In "InviteSessionHandler.hxx"...
/// called when an SDP answer is received - has nothing to do with
user
/// answering the call
virtual void onAnswer(InviteSessionHandle, const SipMessage& msg,
const SdpContents&)=0;
Ok, so what callback DO I get when the remote party answers the call.
I distinctly rmember asking this qestion to the group before, but
never got an answer...
f) What objects need to be created when the SipPhone starts up
Depends on your application, out-of-scope.
I clearly stated my application is a SIP Phone. As any windowing type
of application, there is usually an Initialization phase, and then there
are events that take place that do things... but ONLY as far as
resip/DUM are concerned, then what objects do I need to create,
and when do I create them?
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.
No Comments on this one? Darn, I really want to know the answer to
this one.
Can't ANYONE answer this one?
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
See Section 10 of RFC 3261. You are quite confused about SIP and
connections.
I did read it... it wasn't explained very well.
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.
Compile time is seldom (to never) the limiting factor in SW development.
It is with my G3 laptop.... not ALL of us has or is provided the latest
and greatest iron.
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...
The forest can be found in RFC3261-3265.
I'll look at 3265... I read 3261 at least 3 times. I keep a printout
in the
"Loo" so I'm forced fed it each morning. Suggestions on where to look
is always welcome... Have hilight in hand.
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.
Basic software development and software engineering practices, along
with design patterns are out of scope for the resiprocate devel list.
No - but providing adequate examples of use certainly is.... every
question I've asked has
been related to resip stack, sure I asked one or two C++ related
questions but they
directly related to resip and it's use of C++.
[snip]
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....
See the test programs. Last time I looked they were helpful.
Could you point me to a place in the test program where I would
extract an IP and port of a remote client after they answer
the call? ALL I see are "log" outputs saying we reached
the specific callback. Please indicate line numbers as well.
As these test modules been modified in the last 2 weeks?
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
Software isn't trial and error. You either understand the paradigm or
need to do more research.
Which is what I'm doing... but if it's not mentioned how to do
something, I can only guess
what it could be, only from looking at the 'test" modules.
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...
See bbridge or ANY of the sample programs.
URL for bbridge please?
It's no WONDER nobody wants to write a
SIP phone for the Mac...
John; you are clearly confused, your complaint is illogical. Your
inability to concoct a sample program on a Mac computer in no way
affects others working with the Mac. Many of the reSIProcate
developers use and/or develop on Macs.
I sure wish they would share some tips....
You might benefit from doing some further independent research to get
a better idea about how SIP works. For example, UAs don't have
'connections' to their 'server'. They may, however, have a connection
oriented protocol connection (L3) to an outbound proxy or proxy. This
may or may not be the registrar. When your questions are
significantly off-base from how the protocol is designed to work,
people who are working on the protocol itself might assume it is too
great a task, for too little reward, to undertake your education. As
is customary in many open-source projects, the onus of understanding
the basic architecture of the 'problem space' and the various
approaches to implementing solutions are 'must haves' prior to
engaging a community.
All I am asking for are a little more robust examples on resip usage,
and the completion of the docs.
I got some people telling me the WIKI server was down, but when I go to
a blank topic... for
instance, when I go here..
http://warsaw.sjc.purplecomm.com/wiki/index.php?title=Application_vs_Stack_Responsibilities&action=edit
I get "You have to login to edit pages.
Return to Main Page"
on most of the ones I need to look at... how does this relate to any
possible inexperience I might have
with resip, c++, or whatever?... if I know what the Application Vs
Stack responsibilities were,
I would not have to ask at least 80% of the questions I have asked.
I won't go bother the LISP people to help me implement a distributed
behavioral animation modelling system (nothing to do with LISP, per-
se) unless I'm fairly sure I can tell my CDR from my CAR.
If you have specific questions that show an understanding of the
basic SIP principles, then there are a ton of people in this
community who can help you with answers. When your questions conflate
protocol issues with basic software design and technique problems,
people don't have the time to unravel your issues.
I think there is a very hazy line between understanding basic SIP and
not knowing
"design principles"... All of my questions have beed derived from lack
of information
in the manual, and I took the time to very carefully point out where. I
was hoping
I was contributing to the group as a whole by pointing out places where
better
explanations would make resip easier to use by us "Not so educated" folks.
And most of MY questions are same as others.
That is a task that you must undertake yourself.
I recognize that there are people on the list that post minimal
useful information and ask for help. Sometimes, due to repetition or
recognition of the underlying problem, they can be given a quick
answer. Your questions have not fallen into this category and thus,
it might appear that we are ignoring you. More likely, however, is
that we don't have time to take up your 'context' and debug your
problems when you appear unwilling to do so yourself.
I'm not even at the debugging stage... All I'm saying is "See - what
I've done, is this right?"
Furthermore, as a specific implementation community, it is beyond our
abilities and charter to provide SIP tutorials to individuals.
I'm not asking for SIP tutorials, I just want to know how to use resip
and get access to better examples
on how to use it, and at least have a more complete manual. This has
nothing to do with learning SIP,
but everything to do with learning resip.
That's not to say it isn't a worthy cause, but since almost all the
resiprocate contributors have senior positions at day-jobs in the
VOIP industry, it would only be in our (precious and scarce) free
time that it would make sense to assist you.
Is 15 minutes to look at some draft code too much to ask?
John, to be fair, it takes more than 20 minutes to do a code review.
Perhaps an Audit... but my interpretation of a review might be a brief look
to see if I have all the objects interconnected, and write a paragraph on
corrections to my approach.
Code reviews take hours.
I review code professionally, daily, 20 minutes is about enough time
to sketch out the approach. (Assuming I can read it in under 10).
Ok - so I'm off by 5 mins... is 20 mins enough time? How much would
that cost me?
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...
My best suggestion is to read the SIP architecture draft, and RFC
3261-3265 IN FULL.
Ok, I'll get 3262, 3263, 3264, and 3265 and read them again.
Then you can ask questions using concepts and language that we all
understand. You might also want to read the sip implementors mailing
list back archives.
Ok,
JOhn