As someone who as started from nothing and ended up with a working system I would totally agree with Paul.

If we describe a working scenario, i.e. the IP addresses of gateways, Asterisk etc and then describe a ser.cfg then most users will take this and learn how to deploy in their scenario.

I'm happy to pull this together.

Simon

-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: 20 February 2005 13:13 To: Greger V. Teigre; serusers@lists.iptel.org Subject: Re: [Serusers] "Best practice" document,was Warning: sl_send_reply: I won't send a reply for ACK!!

Greg,

How do you think it would be best to start a "best practices" document? My feelings are that to make the most impact a fully functional ser.cfg for a real world SIP proxy should be the basis because most folks on serusers are just looking for a quick "how do I" answer.

I'd like to think that if I just posted my ser.cfg then the ball would be rolling on this, however, I doubt that would happen for several reasons:

* I'm not 100% convinced that my ser.cfg is error free.

* I doubt I've done things exactly correct (ie, I'm sure there are better way to do some things I've done).

* I've got many inline comments, but a much deeper explaination of key areas of my configuration are needed.

* My ser.cfg is deeply dependent on external factors, such as our slightly modified version of Asterisk, which we only use for voicemail. So I don't think just seeing the ser.cfg would answer too many questions regarding how MWI works without including Asterisk integration documentation.

Anyhow, that said I believe that an initial "best practices" document would need to focus on these key areas:

* Basic ser.cfg structure * Database usage (enabling/using MySQL) * NAT traversal * PSTN integration (ie, gateways) * Asterisk integration for voicemail only (no call routing logic)

I think that this would solve many of the postings that appear on serusers frequently.

Regards, Paul

On Sun, 20 Feb 2005 11:46:58 +0100, Greger V. Teigre greger@teigre.com wrote:

Thanks for your initiative, Paul.

I suggested in a previous post that a simple FAQ list could be created

on the iptel.org site pointing to posts on mail.iptel.org that addressed commonly asked questions. Seeing the initiative now on TLS,

I realize that maybe the only way to get something going is to do something, submit it in some way, and then people will start to relate

to it.

Thus, I suggest that you, if you have the capacity to do so, 

submit a starting point for a such a best practice document. I will promise to review and contribute where I can add value. If people fancy the document, it will be in the interest of the core developers to submit their input ("priority by relevance").

My company has decided to offer to host a "best practice site" (if

it is of interest to the community) where the document, reference ser.cfgs, as well as links to posts, resources, other people's non-cvs

modules etc can be presented. I find voip-info.org to be a good resource, but picture a more structured and edited approach to complement and provide easy access to resources. Ser is an excellent open source software, but IMHO the project has

not yet matured enough to be taken seriously for large service providers (without somebody like us presenting . Those of us who make

a living that includes ser should really collaborate to make ser as best as possible and (an even more) viable alternative to commercial software. We can and should compete on other things than who can make

the ser.cfg work...

The core developers are doing an excellent job, and I believe the 

best way we can help them out is to start initiatives and see if they catch on. I think it's in everybody's interest to build a large and stable community around ser. I see several initiatives now that point in the right direction, as well as areas where work is needed:

• "Best practice" initiative from Paul
• My initiative suggesting a new website in this post
• Andreas' work on scalability (discussed recently on this list)
• The TLS initiative
• Need for a viable, scalable voicemail implementation
• Need for a scalability/redundancy reference design including load

balancing/multiple server centers

• Need for database support beyond open-source DBs (ODBC/JDBC/LDAP)
• Need for access to a repository of modules (beyond those in CVS).

Can be addressed on my suggested website

• Need for more application level integration/capabilities (SIP

Servlets, JAIN, etc)

• and probably many more

Well, let's start small. There is a lot of activity and implementations that are being done, partially exposed here on serusers/serdev. By exposing and coordinating these efforts publicly, people can concentrate on new and even more exciting things than just figuring out how to handle NAT... g-)

Java Rockx wrote:

...

Guys,

Since I just made very substantial changes to my ser.cfg I'd like to

...

test my full feature set before sharing it. I'm going to put a new post on serusers_at_iptel.org in a day or two seeking comments on establishing a "best practices" document for ser.cfg and in that post I'll attach my ser.cfg which perhaps could be used as a basis for beginning a dialog on this subject.

At a minimum I'd like to see a more complete and complex ser.cfg for

...

which other can base their work.

The problem with this is that it would require take some feedback from the ser core team to ensure the "best practices" are correct and properly reflect the designers intent. The reason I think this could be a problem is that Andrei, Jiri, Jan, and company are more than busy already.

The bottom line is that as great as ser is, coding practices are mostly a mystry to developers seeking to install ser and when you get in to complex functionality such as call forwarding confusion stumps many users.

Regards, Paul

On Sat, 19 Feb 2005 19:59:31 +0100 (CET), Medve Istvan imedve@ew.hu wrote:

...

...

Perhaps I'll post my entire ser.cfg this week for anyone that wants it.

Please send it to me.

Thanks, imedve

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

_______________________________________________ Serusers mailing list serusers@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 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

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@isc.upenn.edu wrote:

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@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@upenn.edu

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Guys,

this discussion faded away. Is it still hot but carried out somewhere else?

Anyway, I am committed to put my business support system in the open source. We use it both in projects at Royal Institue of Technology (KTH), Stockholm, as well as commercially (www.xtrafone.com). The BSS handles order, customers, accounts, rating, billing (pre-paid), customer My Pages, etc. The lot!

KTH use SER as its proxies wheras we use the Asterisk in www.xtrafone.com. As long as there are CDRs placed in a MySql tables, the BSS can pick that up and rate, charge.

I have also written a couple of How-To (install ser, mysql etc).

All this I'd like to add to the pot. I am all for to create a complete package for a commercial or non-commercial VoIP operator that includes a proxy, gateway and BSS. And also the docs describing best practices (ser.cfg, logging, NAT traversal, etc). Just add marketing and customers and you roll.

For the BSS I don't really know where to place the code. Beside the ser? sourceforge? It is written in /bin/sh, awk, SQL and php (no, nothing to compile!). Runs on any Linux, MacOSX and FreeBSD system.

Can we get this discussion thread going again and get started putting our stuff into a shared pool where we can get going to change the world (I just could not hold back :-).

/hans

2005-02-21 kl. 14.28 skrev Iqbal Gandham:

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@isc.upenn.edu wrote:

...

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@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@upenn.edu

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers .

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Iqbal is right. We are putting in quite a lot of effort these days to write a Best Practice document. A contribution like yours would be excellent! g-)

Iqbal wrote:

There are a few people on the list working on it, Java (aka Paul) , Simon, and Greg, the first draft of the doc has almost been done, so I guess it would be useful to add to that.

iqbal

On 3/7/2005, "Hans Eriksson" hans@hecc.se wrote:

...

Guys,

this discussion faded away. Is it still hot but carried out somewhere else?

Anyway, I am committed to put my business support system in the open source. We use it both in projects at Royal Institue of Technology (KTH), Stockholm, as well as commercially (www.xtrafone.com). The BSS handles order, customers, accounts, rating, billing (pre-paid), customer My Pages, etc. The lot!

KTH use SER as its proxies wheras we use the Asterisk in www.xtrafone.com. As long as there are CDRs placed in a MySql tables, the BSS can pick that up and rate, charge.

I have also written a couple of How-To (install ser, mysql etc).

All this I'd like to add to the pot. I am all for to create a complete package for a commercial or non-commercial VoIP operator that includes a proxy, gateway and BSS. And also the docs describing best practices (ser.cfg, logging, NAT traversal, etc). Just add marketing and customers and you roll.

For the BSS I don't really know where to place the code. Beside the ser? sourceforge? It is written in /bin/sh, awk, SQL and php (no, nothing to compile!). Runs on any Linux, MacOSX and FreeBSD system.

Can we get this discussion thread going again and get started putting our stuff into a shared pool where we can get going to change the world (I just could not hold back :-).

/hans

2005-02-21 kl. 14.28 skrev Iqbal Gandham:

...

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@isc.upenn.edu wrote:

...

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@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@upenn.edu

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers .

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Hi Hans,

This is a great thing. Can't we place this BSS code at berlios? And then may be put a link from iptel.org site under 3rd party software. As Alexey willing to set up a SER community site may be you can place the docs there as well.

By the way are you involved in Yxa and the minisip developments at KTH?

Regards,

Lakmal

--- Hans Eriksson hans@hecc.se wrote:

Guys,

this discussion faded away. Is it still hot but carried out somewhere else?

Anyway, I am committed to put my business support system in the open source. We use it both in projects at Royal Institue of Technology (KTH), Stockholm, as well as commercially (www.xtrafone.com). The BSS handles order, customers, accounts, rating, billing (pre-paid), customer My Pages, etc. The lot!

KTH use SER as its proxies wheras we use the Asterisk in www.xtrafone.com. As long as there are CDRs placed in a MySql tables, the BSS can pick that up and rate, charge.

I have also written a couple of How-To (install ser, mysql etc).

All this I'd like to add to the pot. I am all for to create a complete package for a commercial or non-commercial VoIP operator that includes a proxy, gateway and BSS. And also the docs describing best practices (ser.cfg, logging, NAT traversal, etc). Just add marketing and customers and you roll.

For the BSS I don't really know where to place the code. Beside the ser? sourceforge? It is written in /bin/sh, awk, SQL and php (no, nothing to compile!). Runs on any Linux, MacOSX and FreeBSD system.

Can we get this discussion thread going again and get started putting our stuff into a shared pool where we can get going to change the world (I just could not hold back :-).

/hans

2005-02-21 kl. 14.28 skrev Iqbal Gandham:

...

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@isc.upenn.edu wrote:

...

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

=== message truncated ===

__________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/

Greg,

I full agree with you. I see that we've taken different approachs to NAT. We do not use STUN because:

* the two opensource STUN projects are really not written well,no offense to the authors :) * it adds a new layer of complexity to support * it forces the SIP users to have additional settings on their SIP phones/UAs

Instead we do 100% transparent RTP proxying with mediaproxy. However, we did not want all that RTP traffic to pass through our servers so we __only__ proxy RTP streams when one or both SIP clients are behind a NAT __or__ when a client is accessing the voicemail system (see my other posts on how I have Asterisk on a 10.x IP network)

The benefit of doing NAT traversal this way is that we believe it scales very well and is the most simple to maintain and support. We've always taken the approach that we're going to put a million customers on our VoIP platform and RTP is a show stopper if you can't keep up with load demands.

We avoid this by making sure customers connect their IAD up as follows:

INTERNET ----- Broadband Router ----- IAD ----- PC

We can do this because we only support IADs that are routers, such as the UTstarcom iAN-02EX or the Grandstream 486. We also ship the IADs locked down so that customers cannot modify their settings. The UTstarcom allows us to remotely change the configuration. All this translates to users having their IADs with public IPs and therefore, RTP doesn't hit our servers.

P

On Mon, 21 Feb 2005 09:43:26 +0100, Greger V. Teigre greger@teigre.com 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 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

See my inline comments:

On Mon, 21 Feb 2005 15:06:42 +0100, Greger V. Teigre greger@teigre.com wrote:

Java Rockx wrote:

...

I full agree with you. I see that we've taken different approachs to NAT. We do not use STUN because:

• the two opensource STUN projects are really not written well,no

offense to the authors :)

That is interesting. We use vovida stun and have not experienced any problems at all. What exactly are you referring to?

MyStun is terrible, IMHO, and VOCAL is a dead project, so neither are good choices for our company.

...

• it adds a new layer of complexity to support

That's true.

...

• it forces the SIP users to have additional settings on their SIP

phones/UAs

Ditto.

...

Instead we do 100% transparent RTP proxying with mediaproxy. However, we did not want all that RTP traffic to pass through our servers so we __only__ proxy RTP streams when one or both SIP clients are behind a NAT __or__ when a client is accessing the voicemail system (see my other posts on how I have Asterisk on a 10.x IP network)

The benefit of doing NAT traversal this way is that we believe it scales very well and is the most simple to maintain and support. We've always taken the approach that we're going to put a million customers on our VoIP platform and RTP is a show stopper if you can't keep up with load demands.

We avoid this by making sure customers connect their IAD up as follows:

INTERNET ----- Broadband Router ----- IAD ----- PC

We can do this because we only support IADs that are routers, such as the UTstarcom iAN-02EX or the Grandstream 486. We also ship the IADs locked down so that customers cannot modify their settings. The UTstarcom allows us to remotely change the configuration. All this translates to users having their IADs with public IPs and therefore, RTP doesn't hit our servers.

Exactly! And that's the problem. If you are to support (like us), regular SIP phones hooked up on a router somewhere, you cannot do this. Either you proxy everything (which as you say, is very bad, indeed) or you use STUN...

If a customer hooks up their IAD as follows, then they'd be RTP proxied for all calls, but since they are signing up with our service we send them instructions on how to hook up their IAD.

INTERNET --- Broadband Router ---- Switch/Hub --- IAD

In either case they fully function __without__ STUN, but like I said before, if they read the "installation instructions" that we include with the IAD then 9 out of 10 will hook up their IAD as noted before and therefore they'll have a public IP and they'll not have any RTP streams proxied, except for the voicemail access, which is always proxied because our Asterisk is not directly accessible to the internet.

But hey, we have now started to detail the reference design. What kind of UAs should we support? ;-)

We should support any RFC3261 compliant IAD. Our company prefers IADs that have router capabilities such as a UTstarcom iAN-02EX because the previously mentioned installation confuration is possible.

g-)

My opinion about STUN (put it in your book:)

When it works - it really good, save your bandwith and not loading your rtpproxy

But when UAs implementation of STUN client is bad or NAT server is weird and STUN client take wrong decisions it really annoying and because it happening quite often if you offer service to customers with different UAs and NAT routers and providers - we decided not to use it for our company,

-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Monday, February 21, 2005 9:22 AM To: Greger V. Teigre Cc: serusers@lists.iptel.org Subject: Re: [Serusers] "Best practice" document,was Warning: sl_send_reply: I won't send a reply for ACK!!

See my inline comments:

On Mon, 21 Feb 2005 15:06:42 +0100, Greger V. Teigre greger@teigre.com wrote:

Java Rockx wrote:

...

I full agree with you. I see that we've taken different approachs to NAT. We do not use STUN because:

• the two opensource STUN projects are really not written well,no

offense to the authors :)

That is interesting. We use vovida stun and have not experienced any problems at all. What exactly are you referring to?

MyStun is terrible, IMHO, and VOCAL is a dead project, so neither are good choices for our company.

...

• it adds a new layer of complexity to support

That's true.

...

• it forces the SIP users to have additional settings on their SIP

phones/UAs

Ditto.

...

Instead we do 100% transparent RTP proxying with mediaproxy. However, we did not want all that RTP traffic to pass through our servers so we __only__ proxy RTP streams when one or both SIP clients are behind a NAT __or__ when a client is accessing the voicemail system (see my other posts on how I have Asterisk on a 10.x IP network)

The benefit of doing NAT traversal this way is that we believe it scales very well and is the most simple to maintain and support. We've always taken the approach that we're going to put a million customers on our VoIP platform and RTP is a show stopper if you can't keep up with load demands.

We avoid this by making sure customers connect their IAD up as follows:

INTERNET ----- Broadband Router ----- IAD ----- PC

We can do this because we only support IADs that are routers, such as the UTstarcom iAN-02EX or the Grandstream 486. We also ship the IADs locked down so that customers cannot modify their settings. The UTstarcom allows us to remotely change the configuration. All this translates to users having their IADs with public IPs and therefore, RTP doesn't hit our servers.

Exactly! And that's the problem. If you are to support (like us), regular SIP phones hooked up on a router somewhere, you cannot do this. Either you proxy everything (which as you say, is very bad, indeed) or you use

STUN...

If a customer hooks up their IAD as follows, then they'd be RTP proxied for all calls, but since they are signing up with our service we send them instructions on how to hook up their IAD.

INTERNET --- Broadband Router ---- Switch/Hub --- IAD

In either case they fully function __without__ STUN, but like I said before, if they read the "installation instructions" that we include with the IAD then 9 out of 10 will hook up their IAD as noted before and therefore they'll have a public IP and they'll not have any RTP streams proxied, except for the voicemail access, which is always proxied because our Asterisk is not directly accessible to the internet.

But hey, we have now started to detail the reference design. What kind of UAs should we support? ;-)

We should support any RFC3261 compliant IAD. Our company prefers IADs that have router capabilities such as a UTstarcom iAN-02EX because the previously mentioned installation confuration is possible.

g-)

_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Chris wrote:

Do you propose different dial plans e.g. EU vs US vs ... ?

You correctly point out the problem with one all encompassing configuration. I think it would be better to have illustrated examples of core functions and leave the site specific tailoring of the config file to each site.

again $0.02

-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: 21 February 2005 01:05 To: Simon Miles Cc: serusers@lists.iptel.org Subject: Re: [Serusers] "Best practice" document,was Warning: sl_send_reply: I won't send a reply for ACK!!

Guys,

If I might suggest emailing a ser.cfg to everyone privately so make sure it is rock solid before sharing with the serusers list.

The reason is that others my immediately use the ser.cfg verbatim and when blast us with questions. So by having a known "good" ser.cfg on the mailing list we could mitigate other users questions for problems that would have otherwise been fixed.

Also, we should come to an agreement of what the overall system should do - you know, a kind of reference for others to build upon.

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 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).

The ser.cfg we present should also show how to use MySQL for accounting, usrloc, etc.

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.

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.

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.

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.

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.

So basically this is a whole sip proxy, except for the redundancy part.

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.

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!

Regards, Paul Hazlett Celebration, FL USA

I would disagree with serweb, I think its very googd, especially the newer version which implements domain based system, hence if you are supporting several virtual sip providers it provides a good base platform on which to add things/features.

You mentioned that you only use the mediaproxy when one or both are behind NAT, if this is the case (and a good one :-)), then how do you handel the billing or is that done at the gateway i.e cisco , since if the media stream is not passing through, then its a bit hard to control the call...which is why I originally went with asterisk, and passed the calls through there, but am now moving more towards your suggestion of using asterisk just for the conf calling/voicemail type of things. Although its did have a nice rate engine built in :-)

Iqbal

Java Rockx wrote:

Dial plans must be covered. This is a basic requirement for nearly all SER implementations.

Regards, Paul

On Mon, 21 Feb 2005 09:44:43 -0000, Chris ser@cannes.f9.co.uk wrote:

...

Do you propose different dial plans e.g. EU vs US vs ... ?

-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: 21 February 2005 01:05 To: Simon Miles Cc: serusers@lists.iptel.org Subject: Re: [Serusers] "Best practice" document,was Warning: sl_send_reply: I won't send a reply for ACK!!

Guys,

If I might suggest emailing a ser.cfg to everyone privately so make sure it is rock solid before sharing with the serusers list.

The reason is that others my immediately use the ser.cfg verbatim and when blast us with questions. So by having a known "good" ser.cfg on the mailing list we could mitigate other users questions for problems that would have otherwise been fixed.

Also, we should come to an agreement of what the overall system should do - you know, a kind of reference for others to build upon.

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 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).

The ser.cfg we present should also show how to use MySQL for accounting, usrloc, etc.

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.

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.

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.

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.

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.

So basically this is a whole sip proxy, except for the redundancy part.

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.

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!

Regards, Paul Hazlett Celebration, FL USA

-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.1.0 - Release Date: 18/02/2005

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

.

The fifo part is where i was coming unstuck also, however someone mentioned something about fifo_relay which might help, since I need to put it on my web cluser as opposed to on SER box. I agree it is good as a base especially if you dont have the time to write your own.

In regards to the billing, this would be fine for postpaid, since we can get the mins, and then just do the maths for various destinations etc using a rate table, however for postpaid wont you have to disconnect the call somewhere, if so how do you (if you do) send the BYE message to the gateway once the timer has run out

Iqbal

Java Rockx wrote:

We do billing from the SER acc module by recording INVITE and BYE messages. We do not worry about accounting at the PSTN gateway. Fraud detection and billing must be handled outside of the scope of the SIP proxy if scaleablity is important.

The reason I say this is that the RTP streams have the most impact on systems and we do not believe that a VoIP platform can afford to route all RTP traffic for the sake of accounting at the PSTN gateway.

On the serweb note, we concluded that serweb is nothing more than a "good" reference at best. Our decision to scrap serweb in favor of a 100% homegrown interface was based on the fact that serweb is nowhere near optimized for large installations. The way it hits the database repetitively for the same data is crazy. And that smarty stuff is too expensive, IMHO.

Our homegrown PHP system fully supports multiple domains, as does our SIP proxy, and we don't have nearly the amount of code to maintain. We have all the functionality of serweb, except for the Instant Messaging because we don't use the Jabber module in ser.

Another major problem with serweb, and perhaps this is the most important, is that serweb uses the FIFO in ser, which forces serweb to live on the same box as the sip proxy. This is very very very bad. Our web application has zero ties to the sip proxy, and we fully support Click2Dial, voicemail, etc, etc, and we fully scale just like any good Apache installation.

Just my US$0.02 worth.

Regards, Paul

On Mon, 21 Feb 2005 13:22:38 +0000, Iqbal Gandham iqbal@gigo.co.uk wrote:

...

I would disagree with serweb, I think its very googd, especially the newer version which implements domain based system, hence if you are supporting several virtual sip providers it provides a good base platform on which to add things/features.

You mentioned that you only use the mediaproxy when one or both are behind NAT, if this is the case (and a good one :-)), then how do you handel the billing or is that done at the gateway i.e cisco , since if the media stream is not passing through, then its a bit hard to control the call...which is why I originally went with asterisk, and passed the calls through there, but am now moving more towards your suggestion of using asterisk just for the conf calling/voicemail type of things. Although its did have a nice rate engine built in :-)

Iqbal

Java Rockx wrote:

...

Dial plans must be covered. This is a basic requirement for nearly all SER implementations.

Regards, Paul

On Mon, 21 Feb 2005 09:44:43 -0000, Chris ser@cannes.f9.co.uk wrote:

...

Do you propose different dial plans e.g. EU vs US vs ... ?

-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: 21 February 2005 01:05 To: Simon Miles Cc: serusers@lists.iptel.org Subject: Re: [Serusers] "Best practice" document,was Warning: sl_send_reply: I won't send a reply for ACK!!

Guys,

If I might suggest emailing a ser.cfg to everyone privately so make sure it is rock solid before sharing with the serusers list.

The reason is that others my immediately use the ser.cfg verbatim and when blast us with questions. So by having a known "good" ser.cfg on the mailing list we could mitigate other users questions for problems that would have otherwise been fixed.

Also, we should come to an agreement of what the overall system should do - you know, a kind of reference for others to build upon.

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 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).

The ser.cfg we present should also show how to use MySQL for accounting, usrloc, etc.

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.

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.

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.

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.

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.

So basically this is a whole sip proxy, except for the redundancy part.

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.

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!

Regards, Paul Hazlett Celebration, FL USA

-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.1.0 - Release Date: 18/02/2005

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

.

.

I'm saying this is okay if the caller/callee hangs up but what happens if you are running prepaid, and they run out of credits, how do you a) know when they have run out, since you only record INVITES/BYE and b) if you do know when, how do you force a tear-down

Also in you setup (previous posts), your setup is to place the UA in such a way so that they all have public IP's, which means sip to sip calling on your own network you can avoid the RTP stream which is great,

but is there anyone else who cannot force a hardware control, and has worked out a scalable way of soing sip to sip calling, when they are behind NAT, since I dont need to do billing on it, I would much rather not take care of the media stream either, and use my mediaproxy to take care of more $$ productive calls like those for pstn

Iqbal

Java Rockx wrote:

I'm not sure I follow. When the SIP client hangs up the BYE is record-routed to SER which then records the BYE. Any downstream or upstream PSTN gateways would also be record-routed so they would tear down the call properly.

regards, Paul

On Mon, 21 Feb 2005 13:51:05 +0000, Iqbal Gandham iqbal@gigo.co.uk wrote:

...

The fifo part is where i was coming unstuck also, however someone mentioned something about fifo_relay which might help, since I need to put it on my web cluser as opposed to on SER box. I agree it is good as a base especially if you dont have the time to write your own.

In regards to the billing, this would be fine for postpaid, since we can get the mins, and then just do the maths for various destinations etc using a rate table, however for postpaid wont you have to disconnect the call somewhere, if so how do you (if you do) send the BYE message to the gateway once the timer has run out

Iqbal

Java Rockx wrote:

...

We do billing from the SER acc module by recording INVITE and BYE messages. We do not worry about accounting at the PSTN gateway. Fraud detection and billing must be handled outside of the scope of the SIP proxy if scaleablity is important.

The reason I say this is that the RTP streams have the most impact on systems and we do not believe that a VoIP platform can afford to route all RTP traffic for the sake of accounting at the PSTN gateway.

On the serweb note, we concluded that serweb is nothing more than a "good" reference at best. Our decision to scrap serweb in favor of a 100% homegrown interface was based on the fact that serweb is nowhere near optimized for large installations. The way it hits the database repetitively for the same data is crazy. And that smarty stuff is too expensive, IMHO.

Our homegrown PHP system fully supports multiple domains, as does our SIP proxy, and we don't have nearly the amount of code to maintain. We have all the functionality of serweb, except for the Instant Messaging because we don't use the Jabber module in ser.

Another major problem with serweb, and perhaps this is the most important, is that serweb uses the FIFO in ser, which forces serweb to live on the same box as the sip proxy. This is very very very bad. Our web application has zero ties to the sip proxy, and we fully support Click2Dial, voicemail, etc, etc, and we fully scale just like any good Apache installation.

Just my US$0.02 worth.

Regards, Paul

On Mon, 21 Feb 2005 13:22:38 +0000, Iqbal Gandham iqbal@gigo.co.uk wrote:

...

I would disagree with serweb, I think its very googd, especially the newer version which implements domain based system, hence if you are supporting several virtual sip providers it provides a good base platform on which to add things/features.

You mentioned that you only use the mediaproxy when one or both are behind NAT, if this is the case (and a good one :-)), then how do you handel the billing or is that done at the gateway i.e cisco , since if the media stream is not passing through, then its a bit hard to control the call...which is why I originally went with asterisk, and passed the calls through there, but am now moving more towards your suggestion of using asterisk just for the conf calling/voicemail type of things. Although its did have a nice rate engine built in :-)

Iqbal

Java Rockx wrote:

...

Dial plans must be covered. This is a basic requirement for nearly all SER implementations.

Regards, Paul

On Mon, 21 Feb 2005 09:44:43 -0000, Chris ser@cannes.f9.co.uk wrote:

...

Do you propose different dial plans e.g. EU vs US vs ... ?

-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: 21 February 2005 01:05 To: Simon Miles Cc: serusers@lists.iptel.org Subject: Re: [Serusers] "Best practice" document,was Warning: sl_send_reply: I won't send a reply for ACK!!

Guys,

If I might suggest emailing a ser.cfg to everyone privately so make sure it is rock solid before sharing with the serusers list.

The reason is that others my immediately use the ser.cfg verbatim and when blast us with questions. So by having a known "good" ser.cfg on the mailing list we could mitigate other users questions for problems that would have otherwise been fixed.

Also, we should come to an agreement of what the overall system should do - you know, a kind of reference for others to build upon.

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 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).

The ser.cfg we present should also show how to use MySQL for accounting, usrloc, etc.

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.

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.

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.

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.

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.

So basically this is a whole sip proxy, except for the redundancy part.

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.

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!

Regards, Paul Hazlett Celebration, FL USA

-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.1.0 - Release Date: 18/02/2005

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

.

.

.

:-), I was thinking of making a semi-prepaid feature :-).

If a user connects, I guess on the connect a simple exec could be called which see how many mins are left from the acc module taking into account the rate for that call, if that is stored in a db would it not be possible (in theory) to trigger an event from the DB after that time has elapsed.

I know a better way is simply to use a B2BUA like asterisk, but surely there must be a way to send a BYE prpoerly formattted to both parties if we can trigger if we know how much time is left..

Iqbal

Java Rockx wrote:

I see now. Sorry.

The short answer is we don't do prepaid. I know this isn't a good answer, but it's all I've got. :-(

I assume the best way to address this is to do it after the fact as an advanced feature.

P

On Mon, 21 Feb 2005 15:05:10 +0000, Iqbal Gandham iqbal@gigo.co.uk wrote:

...

I'm saying this is okay if the caller/callee hangs up but what happens if you are running prepaid, and they run out of credits, how do you a) know when they have run out, since you only record INVITES/BYE and b) if you do know when, how do you force a tear-down

Also in you setup (previous posts), your setup is to place the UA in such a way so that they all have public IP's, which means sip to sip calling on your own network you can avoid the RTP stream which is great,

but is there anyone else who cannot force a hardware control, and has worked out a scalable way of soing sip to sip calling, when they are behind NAT, since I dont need to do billing on it, I would much rather not take care of the media stream either, and use my mediaproxy to take care of more $$ productive calls like those for pstn

Iqbal

Java Rockx wrote:

...

I'm not sure I follow. When the SIP client hangs up the BYE is record-routed to SER which then records the BYE. Any downstream or upstream PSTN gateways would also be record-routed so they would tear down the call properly.

regards, Paul

On Mon, 21 Feb 2005 13:51:05 +0000, Iqbal Gandham iqbal@gigo.co.uk wrote:

...

The fifo part is where i was coming unstuck also, however someone mentioned something about fifo_relay which might help, since I need to put it on my web cluser as opposed to on SER box. I agree it is good as a base especially if you dont have the time to write your own.

In regards to the billing, this would be fine for postpaid, since we can get the mins, and then just do the maths for various destinations etc using a rate table, however for postpaid wont you have to disconnect the call somewhere, if so how do you (if you do) send the BYE message to the gateway once the timer has run out

Iqbal

Java Rockx wrote:

...

We do billing from the SER acc module by recording INVITE and BYE messages. We do not worry about accounting at the PSTN gateway. Fraud detection and billing must be handled outside of the scope of the SIP proxy if scaleablity is important.

The reason I say this is that the RTP streams have the most impact on systems and we do not believe that a VoIP platform can afford to route all RTP traffic for the sake of accounting at the PSTN gateway.

On the serweb note, we concluded that serweb is nothing more than a "good" reference at best. Our decision to scrap serweb in favor of a 100% homegrown interface was based on the fact that serweb is nowhere near optimized for large installations. The way it hits the database repetitively for the same data is crazy. And that smarty stuff is too expensive, IMHO.

Our homegrown PHP system fully supports multiple domains, as does our SIP proxy, and we don't have nearly the amount of code to maintain. We have all the functionality of serweb, except for the Instant Messaging because we don't use the Jabber module in ser.

Another major problem with serweb, and perhaps this is the most important, is that serweb uses the FIFO in ser, which forces serweb to live on the same box as the sip proxy. This is very very very bad. Our web application has zero ties to the sip proxy, and we fully support Click2Dial, voicemail, etc, etc, and we fully scale just like any good Apache installation.

Just my US$0.02 worth.

Regards, Paul

On Mon, 21 Feb 2005 13:22:38 +0000, Iqbal Gandham iqbal@gigo.co.uk wrote:

...

I would disagree with serweb, I think its very googd, especially the newer version which implements domain based system, hence if you are supporting several virtual sip providers it provides a good base platform on which to add things/features.

You mentioned that you only use the mediaproxy when one or both are behind NAT, if this is the case (and a good one :-)), then how do you handel the billing or is that done at the gateway i.e cisco , since if the media stream is not passing through, then its a bit hard to control the call...which is why I originally went with asterisk, and passed the calls through there, but am now moving more towards your suggestion of using asterisk just for the conf calling/voicemail type of things. Although its did have a nice rate engine built in :-)

Iqbal

Java Rockx wrote:

>Dial plans must be covered. This is a basic requirement for nearly all >SER implementations. > >Regards, >Paul > > >On Mon, 21 Feb 2005 09:44:43 -0000, Chris ser@cannes.f9.co.uk wrote: > > > > >>Do you propose different dial plans >>e.g. EU vs US vs ... ? >> >>-----Original Message----- >>From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On >>Behalf Of Java Rockx >>Sent: 21 February 2005 01:05 >>To: Simon Miles >>Cc: serusers@lists.iptel.org >>Subject: Re: [Serusers] "Best practice" document,was Warning: sl_send_reply: >>I won't send a reply for ACK!! >> >>Guys, >> >>If I might suggest emailing a ser.cfg to everyone privately so make >>sure it is rock solid before sharing with the serusers list. >> >>The reason is that others my immediately use the ser.cfg verbatim and >>when blast us with questions. So by having a known "good" ser.cfg on >>the mailing list we could mitigate other users questions for problems >>that would have otherwise been fixed. >> >>Also, we should come to an agreement of what the overall system should >>do - you know, a kind of reference for others to build upon. >> >>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 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). >> >>The ser.cfg we present should also show how to use MySQL for >>accounting, usrloc, etc. >> >>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. >> >>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. >> >>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. >> >>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. >> >>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. >> >>So basically this is a whole sip proxy, except for the redundancy part. >> >>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. >> >>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! >> >>Regards, >>Paul Hazlett >>Celebration, FL USA >> >>-- >>No virus found in this outgoing message. >>Checked by AVG Anti-Virus. >>Version: 7.0.300 / Virus Database: 266.1.0 - Release Date: 18/02/2005 >> >> > > >_______________________________________________ >Serusers mailing list >serusers@lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers > >. >

.

.

.

I was trying to avoid simply because I didnt want to work out the scaling problems :-), but since then i.e 2 days ago I have accepted my fate, and since I am running asterisk I might as well use that, but will see if I can use ser to do the clever routing part, since I will have postpaid and prepaid account, hence users will need to be dropped into a prepay/postpay group, those in postpay will use ser and go outbound to pstn from there and not touch asterisk, and mediaproxy will only be used if natting, which again I would love to do Java's setup, but here they want it all....without spending :-), as for those marked as prepay I will take them to asterisk, and then pstn....unless u have any better suggestion....please say you do :-)

Iqbal

On 2/22/2005, "Vitaly Nikolaev" vitaly@voipsonic.com wrote:

Hi,

Sooner or later you will come to idea that you need b2bua :)

It helps with a lot of things:

Prepaid UA-UA compatibility All kind of SIP fields manipulation that can not be done in SER or it hard/weird Accounting Carrier failover/balancing Reinvite keep-alives Etc Etc

-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Iqbal Gandham Sent: Monday, February 21, 2005 12:23 PM To: Java Rockx Cc: serusers@lists.iptel.org Subject: Re: [Serusers] "Best practice" document, was Warning: sl_send_reply:I won't send a reply for ACK!!

:-), I was thinking of making a semi-prepaid feature :-).

If a user connects, I guess on the connect a simple exec could be called which see how many mins are left from the acc module taking into account the rate for that call, if that is stored in a db would it not be possible (in theory) to trigger an event from the DB after that time has elapsed.

I know a better way is simply to use a B2BUA like asterisk, but surely there must be a way to send a BYE prpoerly formattted to both parties if we can trigger if we know how much time is left..

Iqbal

Java Rockx wrote:

...

I see now. Sorry.

The short answer is we don't do prepaid. I know this isn't a good answer, but it's all I've got. :-(

I assume the best way to address this is to do it after the fact as an advanced feature.

P

On Mon, 21 Feb 2005 15:05:10 +0000, Iqbal Gandham iqbal@gigo.co.uk

wrote:

...

...

I'm saying this is okay if the caller/callee hangs up but what happens if you are running prepaid, and they run out of credits, how do you a) know when they have run out, since you only record INVITES/BYE and b) if you do know when, how do you force a tear-down

Also in you setup (previous posts), your setup is to place the UA in such a way so that they all have public IP's, which means sip to sip calling on your own network you can avoid the RTP stream which is great,

but is there anyone else who cannot force a hardware control, and has worked out a scalable way of soing sip to sip calling, when they are behind NAT, since I dont need to do billing on it, I would much rather not take care of the media stream either, and use my mediaproxy to take care of more $$ productive calls like those for pstn

Iqbal

Java Rockx wrote:

...

I'm not sure I follow. When the SIP client hangs up the BYE is record-routed to SER which then records the BYE. Any downstream or upstream PSTN gateways would also be record-routed so they would tear down the call properly.

regards, Paul

On Mon, 21 Feb 2005 13:51:05 +0000, Iqbal Gandham iqbal@gigo.co.uk

wrote:

...

...

...

...

The fifo part is where i was coming unstuck also, however someone mentioned something about fifo_relay which might help, since I need to put it on my web cluser as opposed to on SER box. I agree it is good as a base especially if you dont have the time to write your own.

In regards to the billing, this would be fine for postpaid, since we can get the mins, and then just do the maths for various destinations etc using a rate table, however for postpaid wont you have to disconnect the call somewhere, if so how do you (if you do) send the BYE message to the gateway once the timer has run out

Iqbal

Java Rockx wrote:

...

We do billing from the SER acc module by recording INVITE and BYE messages. We do not worry about accounting at the PSTN gateway. Fraud detection and billing must be handled outside of the scope of the SIP proxy if scaleablity is important.

The reason I say this is that the RTP streams have the most impact on systems and we do not believe that a VoIP platform can afford to route all RTP traffic for the sake of accounting at the PSTN gateway.

On the serweb note, we concluded that serweb is nothing more than a "good" reference at best. Our decision to scrap serweb in favor of a 100% homegrown interface was based on the fact that serweb is nowhere near optimized for large installations. The way it hits the database repetitively for the same data is crazy. And that smarty stuff is too expensive, IMHO.

Our homegrown PHP system fully supports multiple domains, as does our SIP proxy, and we don't have nearly the amount of code to maintain. We have all the functionality of serweb, except for the Instant Messaging because we don't use the Jabber module in ser.

Another major problem with serweb, and perhaps this is the most important, is that serweb uses the FIFO in ser, which forces serweb to live on the same box as the sip proxy. This is very very very bad. Our web application has zero ties to the sip proxy, and we fully support Click2Dial, voicemail, etc, etc, and we fully scale just like any good Apache installation.

Just my US$0.02 worth.

Regards, Paul

On Mon, 21 Feb 2005 13:22:38 +0000, Iqbal Gandham iqbal@gigo.co.uk

wrote:

...

...

...

...

...

>I would disagree with serweb, I think its very googd, especially the >newer version which implements domain based system, hence if you are >supporting several virtual sip providers it provides a good base >platform on which to add things/features. > >You mentioned that you only use the mediaproxy when one or both are >behind NAT, if this is the case (and a good one :-)), then how do you >handel the billing or is that done at the gateway i.e cisco , since if >the media stream is not passing through, then its a bit hard to

control

...

...

...

...

...

>the call...which is why I originally went with asterisk, and passed

the

...

...

...

...

...

>calls through there, but am now moving more towards your suggestion of >using asterisk just for the conf calling/voicemail type of things. >Although its did have a nice rate engine built in :-) > >Iqbal > >Java Rockx wrote: > > > >>Dial plans must be covered. This is a basic requirement for nearly

all

...

...

...

...

...

>>SER implementations. >> >>Regards, >>Paul >> >> >>On Mon, 21 Feb 2005 09:44:43 -0000, Chris ser@cannes.f9.co.uk

wrote:

...

...

...

...

...

>> >> >> >> >>>Do you propose different dial plans >>>e.g. EU vs US vs ... ? >>> >>>-----Original Message----- >>>From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org]

On

...

...

...

...

...

>>>Behalf Of Java Rockx >>>Sent: 21 February 2005 01:05 >>>To: Simon Miles >>>Cc: serusers@lists.iptel.org >>>Subject: Re: [Serusers] "Best practice" document,was Warning:

sl_send_reply:

...

...

...

...

...

>>>I won't send a reply for ACK!! >>> >>>Guys, >>> >>>If I might suggest emailing a ser.cfg to everyone privately so make >>>sure it is rock solid before sharing with the serusers list. >>> >>>The reason is that others my immediately use the ser.cfg verbatim

and

...

...

...

...

...

>>>when blast us with questions. So by having a known "good" ser.cfg on >>>the mailing list we could mitigate other users questions for

problems

...

...

...

...

...

>>>that would have otherwise been fixed. >>> >>>Also, we should come to an agreement of what the overall system

should

...

...

...

...

...

>>>do - you know, a kind of reference for others to build upon. >>> >>>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 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). >>> >>>The ser.cfg we present should also show how to use MySQL for >>>accounting, usrloc, etc. >>> >>>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. >>> >>>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. >>> >>>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. >>> >>>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.

...

...

...

...

...

>>> >>>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. >>> >>>So basically this is a whole sip proxy, except for the redundancy

part.

...

...

...

...

...

>>> >>>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. >>> >>>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! >>> >>>Regards, >>>Paul Hazlett >>>Celebration, FL USA >>> >>>-- >>>No virus found in this outgoing message. >>>Checked by AVG Anti-Virus. >>>Version: 7.0.300 / Virus Database: 266.1.0 - Release Date:

18/02/2005

...

...

...

...

...

>>> >>> >> >> >>_______________________________________________ >>Serusers mailing list >>serusers@lists.iptel.org >>http://lists.iptel.org/mailman/listinfo/serusers >> >>. >> > .

.

.

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers