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

Iqbal iqbal at gigo.co.uk
Tue Mar 8 01:33:19 CET 2005 

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
>
>

More information about the sr-users mailing list