22 Feb
2005
22 Feb
'05
12:28 a.m.
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(a)isc.upenn.edu> wrote:
Greger V. Teigre wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
.
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.
--
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@upenn.edu
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers