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

[John Todd]

On May 20, 2009, at 12:48 PM, Trixter aka Bret McDanel wrote:

> On Wed, 2009-05-20 at 11:00 -0400, John Todd wrote:
>> I've posed this question in person to people with some frequency over
>> the last few years, and the answer has always been "No, I don't know
>> of such a service." but I'll try on the list and see what I get.
>>
>> I think it would be a great asset to the Asterisk community to have a
>> service provider (let's call them "SP-A") who is a mobile carrier who
>> offered the following method: if I register a SIP entity with their
>> servers, they would then register with the HLR of my mobile carrier
>> ("SP-B") and act as if I was roaming into a mobile network operated
>> by  SP-A.
>
> so similar to truphone.com except that you have to get the number from
> them (or port in) and they become your carrier, when you have GSM
> service you use that, when you have SIP it goes that way, and they  
> even
> do a hot handoff of a live call or something.  I havent used them just
> heard about them.

I'm looking for something that doesn't require porting or obtaining a  
new number - it "just works" with existing devices after a quick one- 
time authentication/authorization step.  TruPhone does this as a  
bundled solution, which is I'm sure quite nice for their customer base  
who is looking for an all-in-one product.  I'd like to see people un- 
bundle the components to allow more innovation and creation of new  
services by clever developers and administrators.

> truphone may bring some "bad blood" into the discussion since it uses
> freeswitch.org and there are some on this list that get livid when  
> that
> is mentioned, but they have been doing this for several years now on a
> freeswitch platform.

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.

> As for registering the roaming stuff, that becomes more difficult, you
> have to have SS7 connectivity with a SS7 stack with the MAP  
> extensions.
> You also have to have a roaming agreement and honestly there is no
> incentive for the mobile carriers to allow this, so its a hard  
> sell.  It
> also screws up their fraud detection algorithms in that you have
> multiple phones registered on the same account, sure they could change
> this, but why change it to allow competition? Its easier to do it the
> other way around, which is what truphone does.

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.

> truphone is geared more towards a mobile phone, use sip when its
> available otherwise use the GSM network, and not "give priority to a  
> sip
> registered device otherwise failover to the mobile phone".
>
>
>> This would, I believe, quickly make Asterisk a roaming-capable
>> solution for mobile devices.
>
> except that without realtime routing updates it can get into a  
> confused
> state.  What if your expire time is 3600 seconds, which seems common  
> for
> many devices, although NAT can lower that to 20 seconds if the device
> does keepalives in a way that works.

The service provider could reject expire times over a minimum number  
of seconds.  Users would have to understand that registration  
intervals would be shorter due to potential conflict.  Just part of  
the technical terms and conditions.  Plus, Asterisk can be man-in-the- 
middle, as usual.  Whatever local authentication/notification  
(bluetooth?) is used to trigger a registration can have extremely  
short keepalives - 5 seconds? 20 seconds?  and then the upstream  
service provider can get an un-register at the moment the local device  
vanishes.   Remember that SIP can proactively remove a registration as  
well as time one out.  Anyway, this is getting really into the  
details.  I'm certain that many of the issues have a technical  
solution.  The business and political issues are just as big, as you  
note below.

> you could also make it 'roaming' by giving out 1 number that goes to
> your asterisk box that then concurrently rings your sip device and  
> your
> mobile and whomever answers first gets the call.  The trick is that  
> your
> outbound caller id would be wrong if you did not first call your
> asterisk box to place the call, although GSM uses a modified Q.931  
> stack
> which might allow a clever person a way around this.

Yes, that's been done many times, including by TalkPlus (which many of  
you are getting tired of hearing that I co-founded.)  The net result  
is that it's a hack that apparently is not that popular, or everyone  
would be doing it.  Only with the most mighty marketing (Google) will  
this become even marginally acceptable.  Customer resistance to  
porting or getting a new number is extremely high.  Perhaps people in  
Europe are less whiny about this because their roaming costs and  
mobile costs are so unrealistically prohibitively high.  But in North  
America the savings vs. hassle value doesn't justify customers to go  
through the headaches.

>> I have faith that Asterisk
>> developers and administrators would descend upon this type of service
>> like locusts.
>
> do you have faith in the mobile carriers to allow this?  To  
> interconnect
> their SS7 networks when they dont have to?  To modify their fraud
> detection algorithms to not freak out and lock the account when there
> are 2 registered devices?

I have no faith in mobile carriers as a population; they tend to be a  
sluggish and closed-minded bunch (though they talk a good game.)   
However, if it is possible for a single mobile carrier to innovate  
with this service and capture the market, then I think someone might  
consider it.  The fraud issue may be a deal-breaker; it may not.   
Don't know until someone tries and builds a compatibility list.  I'm  
trying to encourage new services delivered via IP, not come up with  
reasons they won't work.

>> Potential problems: what if my mobile phone is registered with SP-A  
>> or
>> some other provider already?  Who gets the messages?  How do HLRs
>> manage multi-registration conflicts?
>>
> generally they say "ut oh this cant happen so it must be a cloned  
> phone"
> and a trigger is fired off to lock the account.  Many HLR
> implementations also do not allow for multiple registrations by
> different devices since in theory that should never happen.  How
> companies like tmobile that does a sip handoff deal with it is to do  
> it
> in the routing part and not in the HLR part, so that when a call is
> placed to your number they see that you are registered via SIP and  
> give
> that priority, failing over to the actual mobile.


Yes, I've considered the fraud issue, but I have no direct  
experimental evidence to say how carriers implement that kind of  
blocking.  Certianly, the existing dual-mode carriers (T-mobile, for  
instance) are trying desperately to keep users locked inside the garden.

Even in the worst case:  This would work for, as an example, people  
who live outside of normal cell phone coverage.  Or oil rigs.  Or  
entire populations that live outside of normal cell phone coverage  
areas.  Still a pretty big market, even if the dual-registration block  
exists.

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.

JT


---
John Todd                       email:jtodd at digium.com
Digium, Inc. | Asterisk Open Source Community Director
445 Jan Davis Drive NW -  Huntsville AL 35806  -   USA
direct: +1-256-428-6083         http://www.digium.com/