Re: [reSIProcate] I have a suggestion on the Docs, and even can guide the efforts.
John,
No ofense, but after reading your posts it is clear you still
did not understand the SIP terminology and principles. You continuosly
misinterpret SIP terminology (like UAServer, UAClient, Answer, etc.)
with the "daily use" of those words. I understand you want to build a
SIP phone but this is a community effort, and you must respect other
people's motivation. You cannot "demand" what you think is needed when
reSIProcate is a common effort and people is free to dedicate to
improve it in the areas they want to dedicate their effort. If you
think is important to document things to facilitate SIP phone
development using reSIProcate: do it by yourself! lead that
initiative! But first you need to understand the basics.
I recommend you to start from the begin again and a good place to
start is Henry Sinreich and Alan Johnston book "Internet
Communications using SIP" or one of the several tutorials you can
google it. Also it is worth to read "Architecture and Design
Principles of the Session Initiation Protocol" by J. Rosenberg and H.
Schulzrinne
(http://www.softarmor.com/wgdb/docs/draft-rosenberg-sipping-sip-arch-01.txt).
PS: I want to make clear this are my personal feelings and opinions.
Regards,
On 10/28/05, John Draper <lists@xxxxxxxxxxxxxxxx> wrote:
> 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
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
--
Mariano Stokle
One Protocol to rule them all,
One Protocol to find them,
One Protocol to bring them all
And in the darkness bind them