Great - I'll try and knock something together tonight ( in word ! ! ) Simon -----Original Message----- From: Java Rockx [mailto:javarockx@gmail.com] Sent: 21 February 2005 18:48 To: Simon Miles Cc: Greger V. Teigre Subject: Re: [Serusers] "Best practice" document,was Warning: sl_send_reply: I won't send a reply for ACK!! I can agree to this. We can tweak our direction as things progress. As for MS Word --- there's no Windoz here so Open Office will have to be good enough. :-) On Mon, 21 Feb 2005 18:24:17 -0000, Simon Miles &lt;simon(a)systemsrm.co.uk&gt; wrote: > Paul, Greger, > > I think we are all about on the same page. I do prefer the approach > for a 'getting started' document to start simple and lead to a more > complex environment. > > So based upon Greger's ToC, can I suggest the following for the > sections > :- > > 1. Getting Started - what is ser and how does it work > > 2. Reference Design > I would like to see here a picture of the complex design > that we will > build to, but then have a picture that shows the simple > design > of a > UA <> NAT <> ser / mediaproxy > > 3. Ser.cfg > A config file with line numbers that describe each section > and > why we have it > and what it does. > > 4. Ser in Action > * Based upon the above ser.cfg, describe how it

> registration / INVITEs > * Handling of NAT > Describe a brief summary of the options and why we > use > mediaproxy > * Basic Call Features > * On Failure Handling > * Billing / Accounting > > 5. Adding Multiple Domains > Describe how to configure multiple SIP servers > > 6. Adding Asterisk Support for voice messages > > 7. Adding RADIUS Support > > 8. Controlling ser with XML / Web Services / serweb > > Appendix A The complete ser.cfg > > Appendix ? Other php etc support files > > Appendix ? How to download the latest version of ser ( from the dev > tree ?? ) > > How does this look. > > I agree about using Microsoft word format ( I use Office as I > haven't bitten the bullet about OpenOffice yet ! ) > > If we agree I'll start a word document off. > > > Simon > -----Original Message----- > From: Java Rockx [mailto:javarockx@gmail.com] > Sent: 21 February 2005 14:49 > To: Greger V. Teigre > Cc: Simon Miles > Subject: Re: [Serusers] "Best practice" document,was Warning: > sl_send_reply: I won't send a reply for ACK!! > > Hi All. > > Let me toss out this idea as a way to keep us from loosing site of > the > ultimate outcome - which I believe is this; > > A novice/newbie must be able to read our documentation and get a > complete (and complex) SIP proxy with voicemail and NAT traversal. > Not > to mention call features, etc. > > So my idea is for us to begin with a complete > ser.cfg/Asterisk/mediaproxy SIP proxy and remove parts to get to the

> "Getting Started" ser.cfg which is super simple. Then do a step by > step guide to reconstruct the full SIP proxy. > > This way novices/newbies can follow along and we can document > features > as we use additional bits of functionality. > > We can also postpone the more advanced aspects until later in the > documentation. > > Thoughts?? > > Paul > > On Mon, 21 Feb 2005 15:34:32 +0100, Greger V. Teigre > &lt;greger(a)teigre.com&gt; > wrote: > > Simon, > > I agree. I suggest that we use Paul's previous email with > > components as a starting point. We can also save some time by > > starting out with Paul's config and strip it down to where we want

> > it. I vote for making > > > the reference design as simple as possible in the beginning and > > then > > rathe elements one-by-one. > > > > Diagram suggestion: > > > > UA > > | > > NAT > > | > > ser --- mediaproxy > > | > > (asterisk) > > > > I suggest adding asterisk as an addon and not as part of the > > initial > > reference ser.cfg. Getting Paul's asterisk config to work is far > > too > > big a hurdle. > > > > Rough suggested table of contents: > > 1. Getting started, how to read ser.cfg, ser architecture (very > > short) > > > 2. Reference design, functionality overview 3. ser.cfg reference > > config file indexed with line numbers and sections 4. Basic > > message routing and structure of ser.cfg (incl. record routing and > > loose_route) > > 5. Registration and INVITE authentication (incl. spoof control, > > external > > INVITEs) > > 6. Handling of NAT > > 7. Basic call features (call fwd, etc) > > 8. On failure handling > > 9. Handling local vs. PSTN calls (forwarding) > > Appendices > > 1. Voicemail > > 2. RADIUS > > 3. serweb > > > > Do we work in word? > > g-) > > > > > > Simon Miles wrote: > > > Can I suggest that the three of us start this off and produce > > > this > > > Getting Started guide. > > > > > > I don't think that designing this committee of the masses will > > > be a benefit. > > > > > > So we first need to agree the reference design and then > > > construct a ser.cfg to support it. > > > > > > If this is correct then maybe we should just list the basic > > > concepts > > > > of the design and then draw a diagram that we agree on. > > > > > > > > > Simon > > > > > > -----Original Message----- > > > From: Greger V. Teigre [mailto:greger@teigre.com] > > > Sent: 21 February 2005 08:43 > > > To: Java Rockx; Simon Miles > > > Cc: serusers(a)lists.iptel.org > > > Subject: Re: [Serusers] "Best practice" document,was Warning: > > > sl_send_reply: I won't send a reply for ACK!! > > > > > > > > > Paul, I fully support the approach: Make one reference design > > > with > > > a > > > > complete ser.cfg. This will give us a Getting Started. We can > > > later add sections on the more advanced stuff like redundancy, > > > radius, etc. Thanks for your review of the components in such a > > > reference design (I'll > relate > > > to > > > > > > those further below). > > > > > > I believe there are two hurdles to get on top of ser: Get a > > > first > > > > working config up and running and then understanding the > > > concepts good enough to start tweaking. Many will not have all > > > the components of the full reference system you describe, Paul, > > > so a starting point with a minimum system is probably needed. > > > I.e. Get > > > a > > > > UA registered without auth, etc (I > > > see some questions on this too) > > > > > > I thus see the following things that must be addressed: > > > - How to read the basic ser.cfg > > > - The basic ser.cfg, what does it do, what is the reference > > > design > > > (is the ser.cfg in cvs appropriate?) > > > - A description of the reference design with a "component list" > > > - The complete ser.cfg > > > - Conceptual explanations of each logical part of the ser.cfg > > > - External systems (Asterisk, mediaproxy/nathelper), configs, > > > etc > > > > > > See my inline comments with regards to a reference design. > > > > > >> My setup uses SER v0.9 and Asterisk-1.0.2. The Asterisk server > > >> is > > >> used > > > > > >> __ONLY__ for voicemail because - well lets face it, Asterisk > > >> sucks as a SIP router because it just isn't designed to be one. > > >> > > >> So all users are managed by SER and Asterisk only comes into > > >> play > > >> for voicemail and for playing recordings such as "the party you

> > >> are > > > >> calling has blocked your call" when a call block is enabled. > > > > > > > > > We also use 0.9, but does not yet support voicemail. I think we

> > > should concentrate on 0.9 capabilities and forget about 0.8.14. > > > Most people starting up now will probably use 0.9, at least > > > shortly when it is released as stable. > > > > > > Voicemail adds a layer of complexity in terms of scalability > > > and redundancy. IMHO we should leave out voicemail from the > > > reference design, not because it is something most people would > > > not want, but because it introduces an external component and > > > complexity that is better added later in the document (like > > > redundancy). That being said, I think we > should > > > include voicemail and voiceprompts as part of the initial work > > > on > this > > > document, just not leave it as the main reference design. > > > Sems is a bit less complex than Asterisk and uses the same > > > style config, could it be an alternativ in the reference design? > > > > > >> We should leave redundancy out of the picture for now because > > >> fault > > > >> tolerant SER is still something many users don't use and it's > > >> something that is still maturing in SER. Besides, my opinion on

> > >> this matter is that a "ser clustering" should be a product of > > >> the > > >> Linux HA technologies (expect for registration functionality). > > > > > > Yes, I agree that we should leave redundancy out. Using Linux HA

> > > does not necessary make it simpler... Also, in order to get > > > network > > > > redundancy when > > > you have distributed users, you need geographic distribution of > > > ser servers. But, again, the complex stuff should be left until > > > later. > > > > > >> The ser.cfg we present should also show how to use MySQL for > > >> accounting, usrloc, etc. > > > > > > Agree. We use RADIUS-based authentication and authorization with

> > > distributed RADIUS servers. Only usrloc is stored in mysql (we > > > use > > > avp_radius_load), but we do accounting to mysql. I can maybe > > > volunteer to do a RADIUS-section > > > > > > later, covering auth, uri, avps etc, but we should concentre on > > > the basics first. > > > > > >> serweb should be avoided altogether because this is nothing > > >> more than a reference implementation that I believe not a > > >> primetime offering, again, just my humble opinion. > > > > > > Agree. But, maybe somebody will volunteer to add an add-on > > > section > > > on serweb? > > > > > >> Failover PSTN gateways must be covered as well as NAT > > >> traversal. The NAT traversal I use is mediaproxy because it > > >> seems to just work > > > >> better, especially in distributed deployments. > > > > > > NAT Traversal, I agree. Failover PSTN GW is a more advanced > > > option. Especially if that means introducing the new lcr module > > > from cvs head. > > > :-) > > > > > >> On this NAT note, my ser.cfg only proxies RTP streams when one > > >> or > > >> more > > > > > >> SIP clients is behind a NAT firewall. The exception to this is > > >> when > > > >> a SIP client needs to hit the Asterisk server. The reason for > > >> this is that the Asterisk server is physically a differenet > > >> machine that > > > >> does not have direct access to the internet. Instead I use the > > >> SER server with two (2) ethernet interfaces, whereby eth0 is > > >> the public > > > >> interface > > > > > >> and eth1 is a 10.0.0.0 private network and I use a crossover > > >> cable to the Asterisk server, which has only one private > > >> 10.0.0.0 > > >> interface. > > > > > > We use rtpproxy where ser is located on one server and the > > > rtpproxy on another. They communicate across udp (inside an > > > ipsec > > > tunnel). I.e. they are geographically distributed to keep the > > > rtpproxy server > > > > as close as possible to the subscribers. > > > Our UAs are configured with STUN and the RTP streams are only

> > > run through our proxy server if an UA is behind a symmetric NAT > > > and gets an incoming conversation (or both are behind symmetric NAT). > > > Calls where both UAs are behind the same NAT will always be > forced > > > through the rtpproxy (to avoid hairpin problem). > > > > > >> Since almost all serusers seem to be interested in voicemail > > >> I'd suggest detail instructions on the Asterisk integration. I > > >> use the ast_data patch, which is kindly provided by bwsys > > >> because this makes managing Asterisk mailboxes a function of > > >> the MySQL database. > > > >> And the only other real hard part to Asterisk integration is > > >> the Message Waiting Indicator, which I have modifed the > > >> app_voicemail.c > > > >> file in Asterisk to handing SUBSCRIBE messages a bit > > >> differently and I use sipsak to send NOTIFY messages back to > > >> SER, which then proxies the NOTIFY message to registered SIP > > >> clients to turn their MWI on or off. > > > > > > IMHO, this is not a basic reference design, but rather > > > advanced... > > > ;-) Of course, there are many people who would love to see this > > > design described. > > > > > >> Call features should also be covered in the ser.cfg. Things > > >> like call blocking, speed dialing, click2dial, etc. Things like

> > >> 3-way calling, call waiting, etc should not be covered because > > >> they are > > >> functions usually implemented as IAD features. > > > > > > Agree. > > > > > >> Our company has a full tcp/ip networking patch that we plan to > > >> release > > > > > >> to the ser project. This tcp/ip patch gives us full FIFO > > >> functionality > > > > > >> as a TCP socket, and this is something we hope would be > > >> commited to > > > >> CVS and maintained in the core. As far as we can tell the > > >> networking patch is stable, but we need to prove this further. > > > > > > Good news! You have probably seen Andreas' effort in this same > > > direction > > > > > > using XMLRPC. I guess you have patched the core like Juha > > > suggested in the XMLRPC dialogue? This is an area where a lot of

> > > parallel work > > > > can be avoided. > > > > > >> So in closing, if anyone things we're better off coming up with

> > >> a > > >> ser.cfg in private, then let me know. If everyone things that > > >> the > > >> serusers list is the place to do this then lets start for the > > >> benefit of everyone! > > > > > > If you start out by making an initial draft by dumping in you > > > config > > > > and > > > > > > making some headers, you can send it to us for adding content. > > > If > > > you submit it on the list with a call to submit suggestions and > > > wishes, we can either rotate the document edit privilege or work

> > > on different parts of it?! > > > > > > Best regards, > > > g-) aka > > > Greger V. Teigre > > > AxxessAnywhere, Oslo, Norway > > > > > >