Issue Transfering calls from SIP Phones

[Soporteco]

Hi. 

When a user with a Cisco 3905 tries to transfer a call to another IP Phone, the call transfers successfully; nevertheless the new recipient cannot hear anything. If he speaks, the original caller can listen to him, but the recipient cannot. 

Is there anything we are missing in our configuration in the CME router? Anything that I could do to troubleshoot this issue? 

I attach the run-config, and a debug ccsip message that I extracted with a call that had been transferred.

Anything would be appreciated. Thanks!.

[Suresh Hudda]

It seems to be issue with codec selection, can you assign 'voice class codec 100` to voice register pool and then test plz.

Suresh

[Soporteco]

Hi Suresh. Thanks for your answer. Should I assign the voice class codec 100 to all voice register pools?

Looking forward to your answer.

Thanks.

[Suresh Hudda]

Hi Dear, First assign it to two pools (e.g. 137 & 161) and then test transfer on these extension only once, if it works then you can assign to all pools.

Suresh

[Fabio Bustamante]

Hi Suresh. It didn't work. I added the voice class codec to 2 voice register pools, and tried to transfer the call, but it is still not working. The recipient cannot hear anything. What other debug command can I use in order to troubleshoot this issue? Or any other recommendations?

Thanks.

[Soporteco]

** btw, I answered with my CCO account, not with soporteco, but i'm the same person ** 

[Soporteco]

would the command " voice rtp send-recv " help? 

[Soporteco]

Just in case anyone ever runs into this issue, this is what we did in order to solve it:

voice class sip-profiles 1000

  request REINVITE sdp-header Audio-Attribute modify "sendonly" "sendrecv"

!

voice service voip

  sip

   sip-profiles 1000

!

After including that sip profile in the CME router config, calls are now transferring without any problem from SIP Phones to SCCP/SIP Phones.

[Brian Meade · Accepted solution]

Just to give more info on why this fixes the issue, some devices/carriers do not handle the call switching to sendonly back to sendrcv after a hold event and continue to stay in rcvonly.  That workaround allows the other side to think that the call is in sendrcv mode the whole time.

[Ayodeji Okanlawon]

Brian, (+5) Good explanation. This is similar to the cucm parameter:
"send-receive SDP in mid-call INVITE"

I am curious to know that rather than enabling this on CUCM which will insert MTP to send SDP for mid-call INVITE, this config should be applied on CUBE and allow CUBE negotiate this part of the call because in most cases CUBE can handle a "sendonly" from CUCM...