[Serusers] "Best practice" document, was Warning: sl_send_reply:I won't send a reply for ACK!!

Iqbal iqbal at gigo.co.uk
Tue Feb 22 18:07:07 CET 2005 

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 at 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 at iptel.org [mailto:serusers-bounces at lists.iptel.org] On
>Behalf Of Iqbal Gandham
>Sent: Monday, February 21, 2005 12:23 PM
>To: Java Rockx
>Cc: serusers at lists.iptel.org
>Subject: Re: [Serusers] "Best practice" document, was Warning:
>sl_send_reply:I won't send a reply for ACK!!
>
>:-), 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 at 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 at 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 at 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 at cannes.f9.co.uk>
>wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Do you propose different dial plans
>>>>>>>>>e.g. EU vs US vs ... ?
>>>>>>>>>
>>>>>>>>>-----Original Message-----
>>>>>>>>>From: serusers-bounces at iptel.org [mailto:serusers-bounces at lists.iptel.org]
>On
>>>>>>>>>Behalf Of Java Rockx
>>>>>>>>>Sent: 21 February 2005 01:05
>>>>>>>>>To: Simon Miles
>>>>>>>>>Cc: serusers at lists.iptel.org
>>>>>>>>>Subject: Re: [Serusers] "Best practice" document,was Warning:
>sl_send_reply:
>>>>>>>>>I won't send a reply for ACK!!
>>>>>>>>>
>>>>>>>>>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 at lists.iptel.org
>>>>>>>>http://lists.iptel.org/mailman/listinfo/serusers
>>>>>>>>
>>>>>>>>.
>>>>>>>>
>>>>>>>
>>>>>>.
>>>>>>
>>>>>
>>>>.
>>>>
>>>
>>
>> .
>>
>
>_______________________________________________
>Serusers mailing list
>serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>
>
>

More information about the sr-users mailing list