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

Paul, I fully support the approach: Make one reference design with a complete ser.cfg. This will give us a Getting Started. We can later add sections on the more advanced stuff like redundancy, radius, etc. Thanks for your review of the components in such a reference design (I'll relate to those further below). I believe there are two hurdles to get on top of ser: Get a first working config up and running and then understanding the concepts good enough to start tweaking. Many will not have all the components of the full reference system you describe, Paul, so a starting point with a minimum system is probably needed. I.e. Get a UA registered without auth, etc (I see some questions on this too)

I thus see the following things that must be addressed: - How to read the basic ser.cfg - The basic ser.cfg, what does it do, what is the reference design (is the ser.cfg in cvs appropriate?) - A description of the reference design with a "component list" - The complete ser.cfg - Conceptual explanations of each logical part of the ser.cfg - External systems (Asterisk, mediaproxy/nathelper), configs, etc See my inline comments with regards to a reference design. > My setup uses SER v0.9 and Asterisk-1.0.2. The Asterisk server is > used > __ONLY__ for voicemail because - well lets face it, Asterisk sucks > as > a SIP router because it just isn't designed to be one. > > So all users are managed by SER and Asterisk only comes into play > for > voicemail and for playing recordings such as "the party you are > calling has blocked your call" when a call block is enabled. We also use 0.9, but does not yet support voicemail. I think we should concentrate on 0.9 capabilities and forget about 0.8.14. Most people starting up now will probably use 0.9, at least shortly when it is released as stable. Voicemail adds a layer of complexity in terms of scalability and redundancy. IMHO we should leave out voicemail from the reference design, not because it is something most people would not want, but because it introduces an external component and complexity that is better added later in the document (like redundancy). That being said, I think we should include voicemail and voiceprompts as part of the initial work on this document, just not leave it as the main reference design. Sems is a bit less complex than Asterisk and uses the same style config, could it be an alternativ in the reference design? > We should leave redundancy out of the picture for now because fault > tolerant SER is still something many users don't use and it's > something that is still maturing in SER. Besides, my opinion on > this > matter is that a "ser clustering" should be a product of the Linux > HA > technologies (expect for registration functionality). Yes, I agree that we should leave redundancy out. Using Linux HA does not necessary make it simpler... Also, in order to get network redundancy when you have distributed users, you need geographic distribution of ser servers. But, again, the complex stuff should be left until later. > The ser.cfg we present should also show how to use MySQL for > accounting, usrloc, etc. Agree. We use RADIUS-based authentication and authorization with distributed RADIUS servers. Only usrloc is stored in mysql (we use avp_radius_load), but we do accounting to mysql. I can maybe volunteer to do a RADIUS-section later, covering auth, uri, avps etc, but we should concentre on the basics first. > serweb should be avoided altogether because this is nothing more > than > a reference implementation that I believe not a primetime offering, > again, just my humble opinion. Agree. But, maybe somebody will volunteer to add an add-on section on serweb? > Failover PSTN gateways must be covered as well as NAT traversal. > The > NAT traversal I use is mediaproxy because it seems to just work > better, especially in distributed deployments. NAT Traversal, I agree. Failover PSTN GW is a more advanced option. Especially if that means introducing the new lcr module from cvs head. :-) > On this NAT note, my ser.cfg only proxies RTP streams when one or > more > SIP clients is behind a NAT firewall. The exception to this is > when a > SIP client needs to hit the Asterisk server. The reason for this is > that the Asterisk server is physically a differenet machine that > does > not have direct access to the internet. Instead I use the SER > server > with two (2) ethernet interfaces, whereby eth0 is the public > interface > and eth1 is a 10.0.0.0 private network and I use a crossover cable > to > the Asterisk server, which has only one private 10.0.0.0 interface. We use rtpproxy where ser is located on one server and the rtpproxy on another. They communicate across udp (inside an ipsec tunnel). I.e. they are geographically distributed to keep the rtpproxy server as close as possible to the subscribers. Our UAs are configured with STUN and the RTP streams are only run through our proxy server if an UA is behind a symmetric NAT and gets an incoming conversation (or both are behind symmetric NAT). Calls where both UAs are behind the same NAT will always be forced through the rtpproxy (to avoid hairpin problem). > Since almost all serusers seem to be interested in voicemail I'd > suggest detail instructions on the Asterisk integration. I use the > ast_data patch, which is kindly provided by bwsys because this > makes > managing Asterisk mailboxes a function of the MySQL database. And > the > only other real hard part to Asterisk integration is the Message > Waiting Indicator, which I have modifed the app_voicemail.c file in > Asterisk to handing SUBSCRIBE messages a bit differently and I use > sipsak to send NOTIFY messages back to SER, which then proxies the > NOTIFY message to registered SIP clients to turn their MWI on or > off. IMHO, this is not a basic reference design, but rather advanced... ;-) Of course, there are many people who would love to see this design described. > Call features should also be covered in the ser.cfg. Things like > call > blocking, speed dialing, click2dial, etc. Things like 3-way > calling, > call waiting, etc should not be covered because they are functions > usually implemented as IAD features. Agree. > Our company has a full tcp/ip networking patch that we plan to > release > to the ser project. This tcp/ip patch gives us full FIFO > functionality > as a TCP socket, and this is something we hope would be commited to > CVS and maintained in the core. As far as we can tell the > networking > patch is stable, but we need to prove this further. Good news! You have probably seen Andreas' effort in this same direction using XMLRPC. I guess you have patched the core like Juha suggested in the XMLRPC dialogue? This is an area where a lot of parallel work can be avoided. > So in closing, if anyone things we're better off coming up with a > ser.cfg in private, then let me know. If everyone things that the > serusers list is the place to do this then lets start for the > benefit > of everyone! If you start out by making an initial draft by dumping in you config and making some headers, you can send it to us for adding content. If you submit it on the list with a call to submit suggestions and wishes, we can either rotate the document edit privilege or work on different parts of it?! Best regards, g-) aka Greger V. Teigre AxxessAnywhere, Oslo, Norway _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Steve, I fully agree - and this is the exact reason that this cannot be a single person endeavor. Regards, Paul On Mon, 21 Feb 2005 07:28:02 -0500, Steve Blair <blairs(a)isc.upenn.edu> wrote: > Greger V. Teigre wrote: > > >> 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(a)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(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers .

Do you propose different dial plans e.g. EU vs US vs ... ? -----Original Message----- From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: 21 February 2005 01:05 To: Simon Miles Cc: serusers(a)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

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(a)cannes.f9.co.uk> wrote: > > > >>Do you propose different dial plans >>e.g. EU vs US vs ... ? >> >>-----Original Message----- >>From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On >>Behalf Of Java Rockx >>Sent: 21 February 2005 01:05 >>To: Simon Miles >>Cc: serusers(a)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(a)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(a)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(a)cannes.f9.co.uk> wrote: >>> >>> >>> >>> >>>>Do you propose different dial plans >>>>e.g. EU vs US vs ... ? >>>> >>>>-----Original Message----- >>>>From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On >>>>Behalf Of Java Rockx >>>>Sent: 21 February 2005 01:05 >>>>To: Simon Miles >>>>Cc: serusers(a)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(a)lists.iptel.org >>>http://lists.iptel.org/mailman/listinfo/serusers >>> >>>. >>> >> >. >

>>>>> >>>>> >>>> >>>> >>>>_______________________________________________ >>>>Serusers mailing list >>>>serusers(a)lists.iptel.org >>>>http://lists.iptel.org/mailman/listinfo/serusers >>>> >>>>. >>>> >>> >>. >> > .