CUBE behavior with local (SCCP not LTI) Transcoding

[gauravpurohit]

Hi,

I currently have a CUBE running on 15.2(2)T (so basically can not do LTI) which has some transcoding resources registered to itself using SCCP. It has 2 physical interfaces and a loopback1. The loopback1 is the main voice related interface used for SIP bindings and to enable ccm to register transcoding.

The CUCM also points to this interface on the trunk.

CUCM-------SIP TRUNK(talk 711 ONLY)-----CUBE(with local Xcoding)-------SIP(729)---ITSP.

<<Due to bandwidth constraints we have to move away from using voice-class where CUBE can better negotiate the two legs with codec filtering>>

We have a requirement to change the SIP bindings on dial-peer pointing to CUCM to use a new interface (along with other changes on CUCM side). My question is:

1) When the CUBE is going to invoke transcoding resources (which it is going to when talking to phones on CUCM) is there going to be an IP address change from loopback2 to loopback1 from CUCM's perspective? or is this transparent to the CUCM and CUBE will only talk to CUCM on the loopback2 it is configured to use?

2) Will this behavior change if LTI is used? as there will be no CCM registrations and media negotiations between CUBE and phones will be based on loopback2 address?

Hope the question is clear.

[Rajan]

Hi Gaurav,

AFAIK, the IP used for sip binding is used for all communications with the CUCM and the IP binded for media resources registration is  used for media resources registration and communication between them and the media resource in this case the transcoder. This wont interfere with the SIP communication between CUCM and Cube via SIP binded IP address.

The transcoder invoked will have that binded IP address (used in sccp to register transcoder) and any transcoder communication with CUCM happens with this. 

HTH

Rajan

[gauravpurohit]

Thanks Rajan,

I believe I have you confused.CUCM leg on CUBE is only doing 711 explicitly. CUCM is not the one invoking the transcoder here, CUBE is.

"The transcoder invoked will have that binded IP address (used in sccp to register transcoder) and any transcoder communication with CUCM happens with this."

This might be wrong and I believe SIP bindings will be used for CUCM communication and CUCM should be always seen to communicate with that address.

The purpose for registering Transcoding on the CUBE to the CUBE itself was so CUBE can invoke it inherently (as it is meant to talk only 711 to CUCM and 729 elsewhere).

Now that i keep thinking about it, it seems that CUBE will use loopback 2 to CUCM only. Even if it invokes the transcoder.

[Rajan]

Once transcoder is invoked for the call the media streaming will be between the endpoints and it goes through transcoder: Hence I guess the transcoder IP (binded in the config) will be used.

IP Phone (endpoint in CUCM) --> Transcoder IP --> ITSP

[Ayodeji Okanlawon]

Whatever IP address is defined during your sccp configuration for the local trancscoder on the CUBE is what will be used to terminate media when the xcoder is invoked. This will also be the case when using LTI. 

[gauravpurohit]

Thanks Rajan and Ayodeji,

I was under the impression that since CUBE had the SCCP server (telephony service) process started the flow would be like:

IP Phone (endpoint in CUCM) --> CUBE Loopback2(because of SIP media Bindings) ----> Transcoder IP(SCCP) ------->Loopback1 (existing global SIP binding)--> ITSP.

so CUCM side will only see the new loopback2 (and that LTI might be a different situation).

I will certainly do some tests before blocking the loopback1 through firewall.