VoIP endpoint compatibility between SCCP and SIP

[R_Acuti]

Hi gang,

We will finally be moving from using SCCP to SIP on our VoIP endpoints. 

We expect that due to some logistical challenges, we may end up having some phones stuck on SCCP for awhile, and some new endpoints running SIP.  We'll be running UCM 11.5.

What are the incompatibilities and pitfalls of doing this?

- Will the Subscriber need to remain in the call path as the trunk/translator between a skinny phone and a SIP phone? (I'm thinking, no.)

- Is this going to place any significant extra burden on a Subscriber?

We will eventually get everything on SIP but there may be some lag, hence the questions.

I haven't dug too deeply yet but I haven't found much documentation on inter-compatibility, mostly migration from SCCP to SIP.

Thanks.

[Jaime Valencia · Accepted solution]

ALL the call signaling always go to CUCM, doesn't matter if it's SCCP, SIP, H.323, etc.

CUCM takes care of doing whatever translation is required. Only the RTP is directly between devices.

If you have a HW CFB, XCODER or MTP on an ISR, those use SCCP, and you can use them if you have a SIP endpoint, because CUCM makes sure it communicates with each endpoint in the right protocol.

[R_Acuti]

I guess I was looking for a problem where there was none. You are entirely correct.

I added a SIP endpoint to our lab call manager and successfully placed a test call to a SCCP phone. No special configurations were needed, the call worked perfectly.

Thanks!

[Jonathan Schulenberg]

The short answer is this shouldn’t be an issue. CUCM always remains in the call signaling path so I presume you meant the RTP. No, a call with Sip and SCCP endpoints would not normally require an MTP or transcoder unless you have some type of capabilities mismatch (eg IPv4 to IPv6, DTMF, etc). Most SCCP phone models support RFC2833 though so even DTMF mismatch is rare. The load is slightly higher for SIP phones in general but unless you’re already pushing the envelope or have a large environment I wouldn’t worry about it. The sizing tool is your friend if you want to be sure though:
https://cucst.cloudapps.cisco.com/landing

[R_Acuti]

Hi Jonathon,

Thanks, this is very helpful. We are aware of the extra overhead that SIP requires and that won't be a problem. Our environment ranks as "small."

We have no special conditions such as the ones you mentioned, so I expect that we won't have any issues. I'll test this out in our lab, promptly.

I am concerned that all this time, I apparently have had a fundamental misunderstanding of how Call Manager works. I thought that once the call session was initiated, the Call Manager removed itself from the path and the phones used RTP to communicate directly?

"After a call has been set up, media exchange occurs directly between the Cisco IP Phones across the IP network, using the Real-Time Transport Protocol (RTP) to carry the audio. CUCM is not involved in a call after the call has been set up. If the CUCM server were unplugged during the duration of the call, users would not notice unless they attempted to use a feature on the phone. CUCM is involved only in call setup, teardown, and features. If the CUCM server that set up the call were down during a conversation, end users would see a message indicating "CM Down, Features Disabled" on the LCD screen of the IP phone."

The above quote was taken from:

http://www.ciscopress.com/articles/article.asp?p=1216890&seqNum=2

[j.huizinga · Accepted solution]

CUCM is involved in call setup and tear down and mid call features. But is not involved in the RTP stream. This is between the phones directly