ehernaez

EZ Call is making the Solegy calling card platform available for free to users of their wholesale termination services. This may be of interest to OpenSBC users because OSBC is tightly integrated with the Solegy platform. Any OSBC user can now open an account with EZ Call (at [http://sipcarrier.biz]) and start using the Solegy platform for managing prepaid and postpaid calling accounts.

Features of the Solegy Reseller/Calling Card module include:

• Fully hosted platform that requires no additional equipment or software in your premises.
• Compatible with any SIP-compatible (RFC 3261) gateway or user device
• Real-time charging of pre-paid or post-paid accounts
• Complete control of all service parameters:
• Create your own rate table and surcharges
• Create unlimited PIN accounts
• Create unlimited User accounts (for MD5 AUTH)
• Delegated administration allows you to assign specific tasks to your staff
• Online management tool for your customer service agents.
• Online reporting tools for trouble-shooting and problem diagnosis.
• Easily customizable
• Support for multiple languages and currencies.
• Customizable voice prompts allows you to create a uniquely branded service
• Support for open source SIP developers with the Solegy-sponsored Open SIP Stack project.
• Optional End-User Interface can be created by you using Solegy’s published SOAP-XML Web services

Support for features of the calling card platform will be provided from
the Solegy Support Forum at [http://forum.solegy.com].

For more informarion about the ServicePDQ platform, please download the [Setup Guide|http://www.ezcallinc.com/callincardsetup.htm] from the EZ Call website at [http://ezcallinc.com|http://ezcallinc.com/callingcardsetup.com]

There is a lot of hype about fixed mobile convergence ([FMC|http://www.solegy.com/blog/eric/?p=84] ). Almost every vendor that touts a solution in this area uses the example of seamlessly transfering a call from their mobile phone to a SIP phone when the user enters a WiFi zone. It makes for a great talking point. Who among us hasn't walked into their office from the parking lot and asked to call or be called back on a landline?

In fact, it's very hard to devise a real FMC service if you are not a mobile network operator. Doing so requires one to route the mobile leg of a call through a SIP proxy (either by forwarding your mobile phone number to a SIP DID, or by forwarding a SIP DID to your mobile phone) in order to control the signalling on the mobile leg. It's messy because it requires the mobile call to be converted and then reconverted between TDM, VoIP and GSM protocols.

That said, I am happy to report that the OpenSBC team has recently added support for FMC scenarios. It works like this:

1. Caller A dials a number that is forwarded to User B's mobile phone through a SIP PSTN gateway, and User B answers;

2. While the mobile call is in session, a SIP endpoint with the same user address as the mobile phone registers to OSBC;

3. OSBC recognizes that the new registration is a match for the ongoing session, and sends an INVITE to the newly registered endpoint;

4. When the endpoint OKs the INVITE, OSBC sends a re-INVITE to the SIP PSTN gateway containing the endpoints comtact information.

I was excited to test this scenario recently using a my Cingular mobile phone and a UTStarcom WiFi phone. As soon as the WiFi phone registered to OSBC, the mobile call was placed on hold, and the WiFi phone started ringing. Boy was I enthralled. As long as I have been in this business, it still amazes and delights me to see this stuff work. Sad... I know.

I encourage anyone else that is interested in recreating this test to give it a try. Please post your results, good or bad, to the forum.

_________________________

NOTE: The only carrier (so far) to deploy a public FMC service - [T-Mobile's @Home|http://www.t-mobile.com/promotions/hotspotathomelearnmore.aspx?WT.mc_n=HotSpotatHm_index&WT.mc_t=OnSite] - has received less than stellar feedback from users. Some of the complaints concern the less-than-smooth hand-off between the GSM and WiFi networks, and the tendency for the UMA handset to try to lock-in to a competing WiFi signal while a call is in session.