[asterisk-biz] Mobile extensions from Asterisk - HLR registration?

[Trixter aka Bret McDanel]

On Wed, 2009-05-20 at 14:11 -0400, John Todd wrote:
> I'm not particularly concerned what platform anyone currently uses for  
> their particular flavor as long as the service is available in some  
> form to Asterisk users.  Any type of flexible back-end could be used  
> for interfacing with this service; but of course I think Asterisk  
> would be the most widely used at this point because of the huge number  
> of connection methods and pre-existing platforms that are supported by  
> the project.
> 

I would argue that asterisk supports 1 platform, linux (ok, it can be on
multiple hardware platforms), and anything else is kinda "well gee it
works".  I think this has been the digium policy for quite some time to
not officially support any other platforms.  As for connection methods,
I do not know of one that exists in asterisk that doesnt exist in say
freeswitch.  Freeswitch has the bonus of actually working to port and
support multiple platforms, including telco grade hardware like
telcobridges.com.  Perhaps you meant pre-existing installations, on that
I would agree that asterisk has more.


> I'd say there is a big incentive for a small, clever mobile carrier to  
> offer this service.  They suddenly get a small roaming fee from  
> thousands of users that they would not have ordinarily, and without  
> the cost of any additional RF infrastructure.  First to market wins big.
> 

The roaming fee is the home carriers fee plus the network that you are
roaming on, so if you have provider X and you are roaming on provider Y,
X bills you, and pays Y some fee.  If the carriers dont like you very
much they can charge you higher roaming fees than they offer to a
company they do like, as a result it may not be a small roaming fee.

There is also extra overhead associated with roaming, there is the
settlement issues that come up, some risk because if a customer does not
pay their bill, you still have to pay the roaming fees, and other things
that come into it.

If you do not allow roaming but do negotiate to lease tower space in the
same way that Cingular/Tmobile do (they each have about half the US48 in
coverage, and lease space on each others towers to make it more
complete) that avoids some of the FCC fees that you would have to pay,
like frequency auction extortion er I mean fees.  You would still have
to register as a CMRS provider and that can lead you into a regulatory
quagmire.

Intercarrier compensation for terminating calls can also be problematic
since CMRS stuff is done based on the MTA and not on the ratecenter as
POTS lines are.  As a result many carriers were sending phantom traffic
rather than actually dealing with this in a grown up fashion.  You could
try to do bill and keep and avoid this, but most carriers will only do
bill and keep if the traffic is near symmetric or if they are going to
be advantaged by it, see the pacbell default interconnection agreement
for their "if we send you more traffic its bill and keep if you send us
more traffic then we charge you" type clauses.

Getting interconnected also can take months if not over a year and
honestly I do not know offhand whether or not CMRS providers are allowed
to traffic across LATAs (they should be since MTAs in many markets cross
LATAs).

The carrier side of things is by no means a trivial undertaking,
requiring federal and state filings, approval, permits, and private
contracts with every carrier you are going to talk to.  The SS7-MAP
stuff is not cheap either, afaik no one has made a cost effective
solution to that.  So its a lot of time, money, and a bit of know how,
and if you cant build the customer  base you are likely to run out of
money and leave your customers out to dry (or get bought out for
virtually no money to show for it).

> 
> PS: There are ways that this can work where dual-registration never  
> happens.  See the OpenBTS discussions of a while back - grab the  
> radio, and you by default prevent dual-registrations.

I am well aware of it, while developing my own GSM tracking, monitoring
(A5 rainbow tables do exist), and proxy software (MITM attack so the MS
is a pbx extension but can still talk to the mobile network) I came
across this, before you could officially get the code, the SF CVS web
page let you get it (and I got some of the pre-gpl code as a result :).
I personally dont like C++ though and there are some limitations in
openBTS that made it unsuitable for my needs.

The problem with this is that its not foolproof and the stock USRP radio
boards are 200mw for 900Mhz, and 100mW if you are doing 1800MHz.  This
means that larger offices or RF noisy environments will not see much
coverage without multiple $1000 units.  If they flap back and forth it
can cause some problems.  

further if you are not careful such a device would run afoul of 18 USC
1029 ("scanning receiver") and for indictment purposes intent to defraud
is assumed and you basically have to prove that isnt the case, and there
may be some FCC issues with running it as well.  Your neighbors may
experience harmful interference as a result of using this.  

under 18 USC 1029 a scanning receiver is something that can get an
access device, and an access device is anything used by itself or in
conjunction with another access device to gain access to something.
ESN/MIN pairs were mentioned because of the time it was written (analog
AMPS system), however the way that its defined the IMSI/TMSI would also
qualify, technically the way its written an email address is an access
device because when used with a password it gives access to an email
account.  Sigh.  But it is the law, and people should be really careful
if they are going to be doing this stuff on their own.  My stuff was
exempt because I was originally propositioned by a government to write
my software, and I was not in the US at that time, later it became
something else :)


-- 
Trixter http://www.0xdecafbad.com     Bret McDanel
pgp key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8AE5C721