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

Vitaly Nikolaev vitaly at voipsonic.com
Tue Feb 22 16:58:19 CET 2005


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