Re: [reSIProcate] I have a suggestion on the Docs, and even can guide the efforts.
- From: Alan Hawrylyshen <alan@xxxxxxxxxx>
- Date: Tue, 25 Oct 2005 21:07:43 -0600
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 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.
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.
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).
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.
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.
f) What objects need to be created when the SipPhone starts up
Depends on your application, out-of-scope.
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
See Section 10 of RFC 3261. You are quite confused about SIP and
connections.
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.
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.
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.
[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.
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.
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.
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.
One of the main reasons that people seem to gloss over your requests
is that they do not 'fit' well with SIP, VoIP or reSIProcate.
A significant component of your requests can be boiled down to:
- Help ME!
- Please help me!
- I am willing to contribute.
- I, however, demonstrate that I might not understand the
concepts well
enough to add value through my proposed contributions.
- I also demonstrate that I don't really understand some of the
philosophies
of OSS projects and communities, electing instead to be a
squeaky wheel.
Right or wrong, I think this colours people's perceptions and
willingness to engage. You would do well to read the netiquette
documents that circulate on the web, usenet and elsewhere.
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.
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.
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.
Telling you how to make a SIP phone isn't a closed task. It would be
like tossing a ping-pong ball into a room full of mousetraps, each
holding a ping-pong ball. Until you have a thorough understanding of
what SIP IS, how it works and HOW it is used to setup a session, you
will find it difficult to ask the questions that will lead to an
understanding of the software architecture decisions in resip, DUM
and repro.
Furthermore, as a specific implementation community, it is beyond our
abilities and charter to provide SIP tutorials to individuals. 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.
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...
John, to be fair, it takes more than 20 minutes to do a code review.
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).
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. 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.
JFGI man!
In my Administrator and Moderator Capacity, I too remain,
Alan Hawrylyshen
reSIProcate Project Administrator
http://sipfoundry.org/reSIProcate/
a l a n a t j a s o m i d o t c o m