[reSIProcate] I have a suggestion on the Docs, and even can guide the efforts.

Tue Oct 25 22:07:43 CDT 2005

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