Mobiity Connect - Circuit Requirements - PRI Only?

[r.stockton]

I have read a couple of documents regarding Mobility Connect that states PRI is required (well, no BRI, CAS-T1, FXO) but none appear to be official documents from Cisco.  Additionally, the SRNDs and Feature Guides don't cough anything up that is convincing.  Is there anything from Cisco at all to clarify?

In this case, the customer has POTS lines and would like me to enable this feature.

Thanks!

[William Bell]

In production, I have always used T1-PRI in conjunction with this feature but that is simply because I have very few customers who use POTS lines for anything other than SRST and last resort call path. I have not researched this to see if there is a restriction, but I would be surprised if there were.  In my lab I use POTS lines to for testing the Mobile Connect feature and it works as designed.  I have no reason to believe it would be a problem.

HTH.

Regards,
Bill

Message was edited by: William Bell Removed reference to MVA and Enterprise Feature Access. I didn't test these until after I installed a PRI in my lab.

[r.stockton]

Here is the link I found that contains a .pdf stating "Mobile Connect Features are not supported for T1 CAS, FXO, FXS and BRI"

https://supportforums.cisco.com/docs/DOC-8454

So, I guess I have two conflicting statements (unfortunately, I don't have the ability to test in my lab - no POTS )

[r.stockton]

Ok, I contacted the PDI Helpdesk on this one and received a fantastic response.  I will trim this a tiny bit but, for the most part, it's the guts of the information:

**** Begin Copied Text ****

I'm afraid there is No support for other than PRI. =(

Unfortunately the documents you have read (such as SRND and Feature and Services Guide are accurate and correct): "Mobile Connect features are not supported for T1 CAS, FXO, FXS, and BRI."

Here's a snippet from an internal discussion we had not so long ago about this topic, I hope it clarifies a little bit the scenario and helps you understand our support constraints:

==============================================
In a nutshell, the limitation is related to connect/disconnect supervision. Without a PRI, CUCM has no ability to determine whether the Remote Destination has answered or terminated the call. CUCM must have the ability to determine this in order to stop ringing the desk phone and/or other configured Remote Destinations as well as to take a call back from the PSTN if the Remote Destination answers too soon.

The latter is necessary for Single Enterprise Voicemail Box feature and is based on the Answer Too Soon Timer, such that should a Remote Destination mobile phone be out of range or turned off, we don't want the call rolling to mobile VM - instead we take the call back and continue to only ring the desk phone until it rolls to enterprise VM.

Furthermore we also need connect/disconnect supervision in order to support the Desk Phone Pickup feature, such that the user can move an in-progress Mobile Connect at their mobile phone to their desk phone. In addition, PRIs provide callerID support which is required for Mobile Voice Access and Enterprise Feature Access 2-Stage Dialing features because these features depend on inbound callerID matching for Remote Destination phones to function.

All of that said, if you are just testing/demoing functionality and don't require official support, then you can use FXOs for PSTN connectivity.

As an example, you can use the following commands under the analog port to enable connect/disconnect supervision:

voice-port 1/0/0
timeouts call-disconnect 2
timeouts wait-release 1
supervisory disconnect dualtone mid-call supervisory answer
dualtone no battery-reversal signal groundStart

Now, you may think that using a BRI, CUCM can determine whether the Remote Destination has answered or terminated the call and Called ID is also provided.

Well, the problem with BRI is there is no guarantee that answer/disconnect indication can be provided in a timely manner.

Certainly there are configurations that can be used get this working (as mentioned above), but the configuration varies widely from IOS version to IOS version as well as based on provider network. PRI is the only type of TDM connection that provides consistent answer/disconnect indication across all versions of IOS and all provider networks.

The alternative to PRI TDM connection would be SIP trunk IP PSTN connection with CUBE serving as the demarcation point between the provider and Unified CM SIP trunks.

**** End Copied Text ****

I hope this helps out all those who search

-Robert

[Adrian Saavedra]

Hello,

Like Bill, I tested a couple of times (in lab environment) that feature with FXO and worked as expected, although in production environments where I have configured Mobile Connect has PRI connection to PSTN.

Then, althought that feature seems to work with FXO, if you're going to deploy it in a production environment it will be better to follow Cisco's recommendation to avoid any kind of issue in the future

Hope it helps, please rate if it does.

Kind regards,

- Adrian.

[paolo bevilacqua]

Now, you may think that using a BRI, CUCM can determine whether the  Remote Destination has answered or terminated the call and Called ID is  also provided.

Well, the problem with BRI is there is no guarantee that answer/disconnect indication can be provided in a timely manner.

As already discussed in the other discussion.

The statements above are incorrect.

BRI provides reliable answer/disconnect just as PRI does. This is a well know fact. Now, if Cisco doesn't want or care to recognise that in the SRND, is something I personally don't care, as is not me providing incorrect information.