Survavibility with IP Centrex Solution (Call manager hosted at Serv. Provider)

[news2010a]

HI,

Imagine I have this scenario:

CLients&IP-Phones(non Cisco)---Layer2Switch-----Router2821------WANLink----Provider(IP Centrex Solution, Call Control hosted in the cloud service provider).

Let's say WAN Link goes down.

Question:

Can IP phones still make internal phone calls successfully?

I was told by competitor, that using their router, the device will act as a SIP Proxy and thus IP Phones will register with WAN-Router. Thus internal phone calls are operational. Competitor states that with Cisco routers such feature is not possible. Note that IP phones are non Cisco.

Can someone clarify that for me?

[Steven Holl]

When you say 'register with the WAN router' are you talking about the 2821?

If you're talking registration, then you'd have to run SIP SRST on the 2821 for the phones to register to it.  And I'm not sure how that's going to fare with third party SIP phones, since it's really designed for our CUCM SIP phone loads.  But if the phones are able to fail back and register via SIP to the router, then you can dial internally at that point, in theory.

If the phones don't fallback their registration and they are smart enough to just act as a SIP proxy and send a SIP INVITE to the gateway, then internal calls aren't going to work unless you have a dial-peer configured on the 2800 with a low preference for EVERY extension and the IP of the phone (which is likely to change over time, and hence not a logical solution).  The 2821 still needs an outbound route if you want PSTN calls to still work, whether that be a backup PRI, analog FXO, SIP trunk, etc.

I don't see how they're doing anything that the Cisco UC doesn't do, though.  With CUCM, we fail back to SRST (with both SCCP and SIP) and maintain both internal and external calling.

[news2010a]

Yes, the WAN router is the 2821. You understood correctly.

Here is the explanation from the competitor. Let me know if this makes sense. The router currently has an FXO port for analog line there I believe FAX (but that is not a connection to the PSTN).

The concern is to make IP phones (non Cisco) communicate internally though. I am very curious to understand how they can provide that funcionality or whether is a caveat (such as configuring the phones statically maybe?).

Let me know what you find.

Remote Survivability

The Total Access 900/900e Series can

act as a registrar and Back-to-Back User Agent

(B2BUA) or as a SIP-transparent proxy to facilitate

remote survivability and NAT traversal. In the event

of a service interruption on the wide area network or

if the carrier’s call agent were to become unavailable,

calls may continue locally at the customer premise

between IP-based or analog phones.

[Steven Holl]

Then the IP phones need to register via SIP to SRST running on the 2800, if you want internal calls to still work.  But like I mentioned, I'm not sure how well it will work, since we only test SIP SRST with our CUCM SIP loads that do extra things which a normal SIP phone doesn't do.

If the IP phones don't register to the 2800 during an outage, then the 2800 has no way of knowing how to route a call to, say extension 1005, because it won't have an extension->IP address mapping.  Hence the need for registration.

But, I'll put my sales hat on and say that they're not doing anything that we can't do with CUCM/SRST, in regards to survivability.

[Jonathan Schulenberg]

The way I read that statement is to say that the phones will always be registered to that Total Access device, not only during a WAN failure. That would be different than a SIP SRST function. Cisco CME would be a closer analogy as the competitor is attempting to replace your existing call agent. Also, I doubt SRST would work because it relies on the phone telling it about it's current configuration through a custom protocol during failover. SIP typically requires a predefined configuration for a device that is attempting to register.

[news2010a]

I think your interpretation is correct.

If so, can't we provide CME config on the 2821 thus providing similar functionality? But the question would be as previous posted, the IP Phones are non-Cisco and thas has not been tested?

[Steven Holl]

Yeah.

We don't officially support third party SIP CME phones to SIP CME, though.  But in theory, you may be able to get it to work with those phones.

Or you could just buy Cisco IP phones and run CME on the 2800 for day-to-day operation (either SCCP or SIP would work), and then you don't have to worry about WAN outages at all, nor interoperability/unsupported designs. :-P

[news2010a]

Hey, the other folks were talking about this, and some people arguing that Cisco does not care or make only Cisco IP phones work in order to force people to buy Cisco phones.

Personally I think Cisco knows better than that.

Is it still the case where SIP is not really standardized?  That is the reason why  those cheap non-Cisco IP phones may not work with the setup we are discussing here? But SIP is gaining maturity, I am surprised vendors making those IP phones still did not bring a real common standard across the board...

[Steven Holl]

Anytime we build a SIP trunk to anything, we aim our best to comply with the relevant recommendations (RFCs for SIP).  We do extra stuff on top of the SIP protocol to leverage extra call  features, though.  Take a look at a SIP packet from a SIP IP phone to CUCM or CME and you'll see what I mean.

At this time, CUCM supports third party SIP endpoint registration, but  CME doesn't at the moment.  If the third party IP phone can act as a SIP proxy though, you can configure a dial-peer (SIP trunk) to the phone, and we'll interoperate with that just fine.

-Steve