[Serusers] "Best practice" document, Business system open source

[Greger V. Teigre]

Iqbal is right. We are putting in quite a lot of effort these days to write 
a Best Practice document.
A contribution like yours would be excellent!
g-)

Iqbal wrote:
> There are a few people on the list working on it, Java (aka Paul) ,
> Simon, and Greg, the first draft of the doc has almost been done, so I
> guess it would be useful to add to that.
>
> iqbal
>
> On 3/7/2005, "Hans Eriksson" <hans at hecc.se> wrote:
>
>> Guys,
>>
>> this discussion faded away. Is it still hot but carried out somewhere
>> else?
>>
>> Anyway, I am committed to put my business support system in the open
>> source. We use it both in projects at Royal Institue of Technology
>> (KTH), Stockholm, as well as commercially (www.xtrafone.com). The BSS
>> handles order, customers, accounts, rating, billing (pre-paid),
>> customer My Pages, etc. The lot!
>>
>> KTH use SER as its proxies wheras we use the Asterisk in
>> www.xtrafone.com. As long as there are CDRs placed in a MySql tables,
>> the BSS can pick that up and rate, charge.
>>
>> I have also written a couple of How-To (install ser, mysql etc).
>>
>> All this I'd like to add to the pot. I am all for to create a
>> complete package for a commercial or non-commercial VoIP operator
>> that includes a proxy, gateway and BSS. And also the docs describing
>> best practices (ser.cfg, logging, NAT traversal, etc). Just add
>> marketing and customers and you roll.
>>
>> For the BSS I don't really know where to place the code. Beside the
>> ser? sourceforge? It is written in /bin/sh, awk, SQL and php (no,
>> nothing to compile!). Runs on any Linux, MacOSX and FreeBSD system.
>>
>> Can we get this discussion thread going again and get started putting
>> our stuff into a shared pool where we can get going to change the
>> world (I just could not hold back :-).
>>
>> /hans
>>
>>
>>
>>
>> 2005-02-21 kl. 14.28 skrev Iqbal Gandham:
>>
>>> Great idea, can I also suggest, and I can help out if needs (simply
>>> because I am one of them struggling users :-)) is a debug guide, all
>>> devices seem to have a few quirks to the setup, and they all seem to
>>> have different setting, eg some support only STUN, some use the
>>> proxying, others you can dela with at the server end etc etc, what I
>>> think owuld be useful is a guide to what its supposed to look like,
>>> i.e the debug log.
>>>
>>> I have been through the entire sip syntax , to figure out where the
>>> messages go/come from, but with the contact headers, From, and c= I
>>> can see how it can get a little confusing
>>>
>>> Iqbal
>>>
>>> PS 0.10 works quite nicely
>>>
>>> Java Rockx wrote:
>>>> Steve,
>>>> I fully agree - and this is the exact reason that this cannot be a
>>>> single person endeavor.
>>>> Regards,
>>>> Paul
>>>> On Mon, 21 Feb 2005 07:28:02 -0500, Steve Blair
>>>> <blairs at isc.upenn.edu> wrote:
>>>>> Greger V. Teigre wrote:
>>>>>
>>>>>
>>>>>> 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'd like to add a third hurdle, keeping this or any documentation
>>>>> up-to-date. One of the biggest issues
>>>>> I've faced is keeping a working, production supporting,
>>>>> configuration "correct" across release changes.
>>>>> The situation doesn't get better if there is alot of out dated
>>>>> documentation.
>>>>>
>>>>> In addition to a few core examples I'd suggest a clearly worded
>>>>> changelog. The changelog needs to
>>>>> be clearly show what has changed and what is impacted by the
>>>>> change on a
>>>>> release by release basis.
>>>>>
>>>>> $0.02
>>>>>
>>>>>
>>>>>>   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
>>>>>> _______________________________________________
>>>>>> Serusers mailing list
>>>>>> serusers at lists.iptel.org
>>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>>
>>>>> --
>>>>>
>>>>> ISC Network Engineering
>>>>> The University of Pennsylvania
>>>>> 3401 Walnut Street, Suite 221A
>>>>> Philadelphia, PA 19104
>>>>>
>>>>> voice: 215-573-8396
>>>>>
>>>>>       215-746-8001
>>>>>
>>>>> fax: 215-898-9348
>>>>>
>>>>> sip:blairs at upenn.edu
>>>>>
>>>>> _______________________________________________
>>>>> Serusers mailing list
>>>>> serusers at lists.iptel.org
>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>>
>>>> _______________________________________________
>>>> Serusers mailing list
>>>> serusers at lists.iptel.org
>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>> .
>>>
>>> _______________________________________________
>>> Serusers mailing list
>>> serusers at lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>
>>
>> _______________________________________________
>> Serusers mailing list
>> serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>>
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers