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

[Greger V. Teigre]

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