provided by Star2Billing S.L.

The Openser Developer hasn't become available yet, so I've been digging into Openser myself.

I now have a working model, if somewhat crude at the moment.

A very much out of the box openser.cfg file, now allows calls out via A2B unless it's local, then OpenSer(OS) handles the calls.

Users are authenticated at the OS end only. The users are validated against a view of sip buddies and card. This means simply add users as normal within A2B and they're active.

I've also resolved the issue where redirects and transfers were not accounted for. When a call is forwarded (FWDALL, FWDBUSY), a diverted from header is added to the SIP header which has the details of the phone doing the divert.

In asterisk, I examine the header for this content and then do a MYSQL select on the sip buddies table and discover the account code.

This is then set prior to A2B processing, so that the appropriate card is billed.

Once this has been thoughly tested, the ideal place for this lookup would be in A2B, but I don't want to mess with this until I'm 100% sure this is the way to go.

I've spent 4 days learning OpenSer writing complex scripts to maniplute headers to handle call divert, only to strip it all out as it's not required.

I'm not using mediaproxy at the moment, but will have to, to check NAT traversal.

The short of it is this
A really basic install of Openser.
The creation of a view within the openser DB.
A few scripts in the extensions.conf file, and that's it.

There is one major change though. When using Openser, the writing of the sip.conf files has to be surpressed for users. Having these in place will cause a double auth scenario which will fail. That said, do we really need huge sip.confs? It doesn't scale. Besides, using the above removes the need for asterisk realtime for sip peers.

Oh, and I can also load balance against multiple asterisk servers

ToDO:
Voicemail
MWI

Any comments would be appreciated.

regards

You da man.

I can't wait to start using OpenSER. Have you had the time to analyze the part where OpenSER receives the DID access numbers instead of hard wiring them to asterisk. So far, I have done this using host based authentication. So OpenSER will accept any call coming from a specific DID provider. How can that be added in your OpenSER model?

Don't quite follow you. Do you mean mapping a given DID to a card? If so, then this can be done in the DB Alias table I think. But the next phase will be to put all of the logic for call divert into openSer, such as time based routing.

regards

Nope. I was talking about DID number as access numbers.

For instance, let's says that you have a calling card service and the access number is "1 800 NOW CALLING" so people will remember it correctly. This number will be used for example to make standard calls and will not be tied to a specific card.

To date, almost everyone is configuring such access number directly in asterisk SIP.CONF or IAX.CONF depending on what is supported by the DID provider.

The only problem is that if the asterisk box tied to that DID is no longer able to accept calls (too busy, down for maintenance, ...) the whole service will seem to be down. But, if the DID number is tied to OpenSER instead, then it would be possible to do load balancing or even to use OpenSER to avoid faulty servers and so on.

That's what I meant.

Do you thinks that that kind of thing can be integrated in your model somehow?

Regards

Gotcha,

That's an absolute breeze. There's an on-failure route that lets you try multiple asterisk servers, so if one's overloaded or off-line, it'll go thru its list until it either finds one or gives up.

All you need do on each * box is define the peer address of the Openser server and set insecure=invite. That's it. However it assumes you have MYSQL available somewhere.


Regards

Excellent. I think that I will slow down my OpenSER research and let someone like your make it perfect. For the moment, I am more focused on a "real time billing" solution for A2Billing. Let us know whenever you need any help (test server, research, coding, ...).

Well, obviously I'm no OpenSer Guru after 4 days. The ONE thing that concerns me is, are there any potential holes in the system with regards to billing. To that end I would appreciate some creative thinking on how to 'break' the system/spoof calls etc.


regards

For one thing, anyone able to spoof callerid can break a callerid authentication based billing system. That has been a concern for me since the beginning.

I thought that you actually register on the SER (meaning userID + PW), and then when user dials a call destined for A2B, it passes over to one of your * boxes, and you'd set it to only accept calls from the SER box to lock it down ??

That's exactly how it works

As part of the Sip Header, an encrpted password is passed for verification as well as being tied to IP/port number

The above assumes that the traffic is via a private network. I haven't thought about sending the requests over the 'open' internet yet. In my case all my servers are on a local network.

As I mentioned previously, before I release the code I'm looking for people to hammer this with regard to fraud. Let's face it, asterisk has many billing 'holes' in my opinion,

regards

Hi

As I understand the architecture of this, you are using the User+pass to authenticate to openser, then calls are authenticated again as they go into Asterisk, by identifying and authenticating against the account code, if I am correct in my understanding, then this should make for a very secure system. particularly as Krxykat mentions in that the asterisk servers can be configured to only accept calls from one source.

In terms of the design, I take it openser could be built on a multihomed machine, with an external public IP address, and a private IP, and its co-located asterisk servers on private IP addressing. (asterisk outbound trunks permitting).



I suppose other questions to ask are:-

Is the cardalias still used to dial sip friends?

Can the card number be detected by the person receiving the call.

If the card number can be detected, should the password be of variable length and alpha-numeric to reduce the likely success of brute force attacks?

Joe

Exactly, that's what I had in mind and have done



Good point, the card alias's could be a view to the db alias table.
As outbound trunks are via asterisk, caller ID would be presented. However you raise a good point. I need to change the subscriber view to use card alias and not card number as my test machine does at the moment.

Regards

Hi middletn,

I managed to implement your tricks to make use of A2billing by creating view in openser database however i have encountered a problem when i try to add a user/subscriber by using openserctl tool, plz check the error below.

debian:/# openserctl add baba 123456 [email protected]
database engine 'MYSQL' loaded
Control engine 'FIFO' loaded
is_user: user counter=0
check_db_alias: alias counter=0
MySql password for user 'openser@localhost':
ERROR 1054 (42S22) at line 1: Unknown column 'phplib_id' in 'field list'
ERROR: introducing the new user 'baba' to the database failed

Can you please advice on how i can overcome the problem or any other alternative way of adding users/suscribers.
wbr,
lu.

You add users via a2billing, not openserctl

regards

Which Openser Version are you using?