[Serusers] "Best practice" document, was Warning: sl_send_reply: I won't send a reply for ACK!!

[Steve Blair]

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