call transfer to external number not working UC560

Answered Question
May 26th, 2010
User Badges:

Hello guys!


I'm having a problem transferring a call to an external number and don't know where to start troubleshooting. We have a UC560 PBX with two SIP trunks, no analogue or digital lines. Here is what's happening - when I answer an incoming call, I can transer it to another extension wiouth problems. If I transfer to an external phone number the call drops. This is how I do it - answer the incoming call, press Transfer, dial an external number, as soon as the other party answers my call and press Transfer again and at this stage all calls drop.


If I set call forwarding to an external number - it works perfectly, it's just call transfer that it not working. I'm pretty sure I didn't have this problem in the past so I must have upgraded/changed something incorrectly, perhaps phone templates with softkeys? The phones I'm using are Cisco 521S


I would appreciate any useful advice


thanks!


victor


Inventica

http://www.inventica.co.uk

Correct Answer by Marcos Hernandez about 7 years 1 month ago

What I see is that the INVITE going out for the transfer (from the UC500) has G711alaw in the SDP, so it is the UC500 the one proposing that codec for the outbound call. This tells me that the voice class codec has a law as first on the list and the call might be failing because transcoding is NOT enabled.


Could you try changing the codec preference to do ulaw first? The SIP carrier seems to support it, since it was first on the list for the initial incoming call.


Marcos

Correct Answer by Steven DiStefano about 7 years 1 month ago

I looked at the trace.   I see the the initial call negotiates a G711U law codec.

Then you set up a call to the third party and that terminating GW insists on using PCMA law codec.   We are OK, we transcode.  As soon as you complete transfer, we are out, and the two endpoints are now mismatched.


This may be why you see the Interworking Failure case code in your BYE.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Marcos Hernandez Wed, 05/26/2010 - 04:06
User Badges:
  • Blue, 1500 points or more

Can you please provide a "debug ccsip message" and a copy of your "show run" and "show ver"? Make sure you hide the passwords and any other private information.


Thanks,


Marcos

Correct Answer
Steven DiStefano Wed, 05/26/2010 - 07:00
User Badges:
  • Blue, 1500 points or more

I looked at the trace.   I see the the initial call negotiates a G711U law codec.

Then you set up a call to the third party and that terminating GW insists on using PCMA law codec.   We are OK, we transcode.  As soon as you complete transfer, we are out, and the two endpoints are now mismatched.


This may be why you see the Interworking Failure case code in your BYE.

Correct Answer
Marcos Hernandez Wed, 05/26/2010 - 08:00
User Badges:
  • Blue, 1500 points or more

What I see is that the INVITE going out for the transfer (from the UC500) has G711alaw in the SDP, so it is the UC500 the one proposing that codec for the outbound call. This tells me that the voice class codec has a law as first on the list and the call might be failing because transcoding is NOT enabled.


Could you try changing the codec preference to do ulaw first? The SIP carrier seems to support it, since it was first on the list for the initial incoming call.


Marcos

inventica Thu, 06/03/2010 - 02:16
User Badges:

Thanks guys for pointing me in the right direction! playing with codecs fixed the problem!