Dual forking with Cisco ISR G2

[shanee420]

Hi,

I am looking for some help to confirm if dual forking of calls is supported on Cisco ISR G2 gateways.

This is required as we are trying to explore if we can use Cisco gateways for a parallel run of CUCM and Lync in the migration phase in a way that both systems can operate in parallel with Lync clients and PBX phones having the same DN, while the gateway forks an incoming call to both systems providing users with option of picking up the call on either endpoint.

There are other vendor products such as NET UX1000/UX2000 gateways that support this parallel run/dual forking.

I am wondering if Cisco 2900/3900 series gateways support this? and how can this be setup?

Regards,

Zeeshan

[skilambi]

That's a question that you need to ask MSFT. IMHO dual forking is a bad design. You need to take care of routing loops and frankly I don't see the point because that's just a strategy for MSFT to displace the PBX. Otherwise why would you advocate dual forking. Case in point back in the OCS days MSFT only tested dual forking with Nortel

http://technet.microsoft.com/en-us/office/ocs/bb735838.aspx

With Lync there is no such solution that is tested so basically you will be in untested waters.

http://social.technet.microsoft.com/Forums/ta/ocsvoice/thread/eb0ff7ce-0476-41a1-a96e-73544b233178

You can even see here on concerns with this approach on a MSFT forum of all places

Cisco has tested direct SIP integration and you can do SNR but you will have to use a different number for Lync. Stick with tried and tested scenarios to save yourself a whole lot of trouble with routing loops, calls not being teared down correctly etc.

Srini

[shanee420]

Thanks Srini,

Agree with you that its a strategy by MSFT to displace PBXs but it can be used other way around as well.

Anyway, I think i should have clarified a bit more. I am not looking to explore setting up dual forking on PBX side.

The whole reason for this parallel run scenario is to avoid having to do complex SIP or RCC integration, merely for the migration phase. All that's required is to fork incoming PSTN calls to multiple destinations at the Gateway level to avoid integration efforts and complexities.

I know NET gateways can do that. We are just exploring whether we can do the same with Cisco gateways.

Regards,

Zeeshan

[skilambi]

I agree on the integration needs but honestly sip will be any day easier than dual forking

Not saying sip is easy but at least there is a tested guide from Cisco

Honestly in the old days when we would migrate any pbx to Cisco it would be the same thing we would never need the same extension just move the users in a phased manner even if they have different extensions

I would follow that tried and tested approach even with lync

Keep it simple

Thanks

Srini

[tbanuelo]

Hi Zeeshan,

The best approach would be to allow CUCM to be the termination point of the incoming call and enable "simultaneous ring" configuration on CUCM with a direct SIP trunk to Lync. This way you can use Cisco ISR gateway as the PSTN termination and allow CUCM to do the forking via SIP.

Please take a look http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns784/1048876.pdf

Regards

Tony Banuelos

[shanee420]

Thanks Tony,

I am already aware of this approach. However, I am trying to explore dual forking at gateway level so we dont need to do any configurations on PBXs. It should be so much simpler to extend the same call to two destinations/PBXs (with same DN) at the gateway level, if this is configurable in some way. And thats what I am trying to explore.

Regards,

Zeeshan

[tbanuelo]

Hi Zeeshan,

Our IOS gateways do not have this functionality (SIP trunks dual-forking). We do support load-balancing and redundant SIP dial-peers to separate call agents, but not the feature you would require for simultaneous ringing

Regards

Tony

[shanee420]

Thanks Tony,

Thats what i was looking for. A 'yes' or a 'no'.

Really appreciate your help and of all others who have been involved in the discussion.

Regards,

Zeeshan.