[Serusers] "Best practice" document, was Warning: sl_send_reply: I won't send a reply for ACK!!
Java Rockx
javarockx at gmail.com
Tue Feb 22 01:49:24 CET 2005
Perhaps, but I think we really need to focus on ser-0.9 rather than
the unstable cvs code. The exception might be the LCR module because
it is an extremely important piece of functionality which can in many
cases make a CLEC / VoIP player profitable or not.
Anyhow, to remain focused I think we should focus on ser-0.9 only.
P
On Mon, 21 Feb 2005 22:29:14 -0000, Simon Miles <simon at systemsrm.co.uk> wrote:
> What I have struggled with recently is the introduction of new modules
> into the code - such as avp. Even now I'm not sure if I should be using
> it and for what reason.
>
> So a description of the modules as we have them today would be useful.
>
> Can we assume that what is in the dev tree at the moment is what will be
> released soon? I did see some emails about this topic.
>
>
> Simon
>
> -----Original Message-----
> From: Java Rockx [mailto:javarockx at gmail.com]
> Sent: 21 February 2005 19:59
> 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!!
>
> Outstanding.
>
> If you guys give me a few days I'll put together a rough document of my
> ser.cfg, Asterisk setup, patches, etc, etc and then we can start
> stripping it apart to generate something useful.
>
> P.S. - have you guys tried gmail? It absoutely kicks ass when dealing
> with long threaded conversations such as these. Anyone wants a gmail
> invitation just let me know. I have about 200 I can give out.
>
> On Mon, 21 Feb 2005 19:28:07 -0000, Simon Miles <simon at systemsrm.co.uk>
> wrote:
> > Great - I'll try and knock something together tonight ( in word ! ! )
> >
> >
> > Simon
> >
> > -----Original Message-----
> > From: Java Rockx [mailto:javarockx at 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
> > <simon at systemsrm.co.uk>
> > 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
> handles
> > > 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 at 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
> > > <greger at teigre.com>
> > > 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 at teigre.com]
> > > > > Sent: 21 February 2005 08:43
> > > > > To: Java Rockx; Simon Miles
> > > > > Cc: serusers at 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
> > > >
> > > >
> > >
> > >
> >
> >
>
>
More information about the sr-users
mailing list