RE: [reSIProcate] I have a suggestion on the Docs, and even can guide the efforts.
- From: "Matthias Moetje - TERASENS GmbH" <moetje@xxxxxxxxxxx>
- Date: Wed, 26 Oct 2005 05:37:38 +0200
Alan,
just a note: The images on the page you mentioned
(http://wiki.resiprocate.org/wiki/index.php?title=Architecture_Overview)
can't be viewed. It seems that scm.sipfoundry.org
is currently down.
PS: Understanding resiprocate at first sight ain't
easy, even with existing knowledge about SIP. On
the other hand I think working hard to understand
the stack is the least one can do for getting the
benefit of such a stack.
John,
you may want to look at the sipXtapi library,
it is a much simpler API (though not as powerful as
resiprocate) and probably better suited for your goals.
Matthias
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx]On
> Behalf Of Alan
> Hawrylyshen
> Sent: Mittwoch, 26. Oktober 2005 05:08
> To: John Draper
> Cc: Resip Devel
> Subject: Re: [reSIProcate] I have a suggestion on the
> Docs,and even can
> guide the efforts.
>
>
>
> 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
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>