[Serusers] "Best practice" document, was Warning: sl_send_reply: I won't send a reply for ACK!!
Iqbal
iqbal at gigo.co.uk
Tue Feb 22 02:12:06 CET 2005
My $0.02 worth
If the doc discusses the use of additional modules in preference to
others eg mediaproxy as opposed to rtpproxy + nathelper, then I think a
note detailing what the diff and why pref is good, in order to allow the
user to decide which one to use...same with sems and asterisk (although
asterisk here has more features), but some users will be using ser with
sems, and would not want to branch out into asterisk setup
And since STUN is being avoided , and a bias towards transparent proxying
seems to be the choice of the day, maybe a note on that .....please :-)
Iqbal
On 2/22/2005, "Java Rockx" <javarockx at gmail.com> wrote:
>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
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
>_______________________________________________
>Serusers mailing list
>serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>
>
More information about the sr-users
mailing list