Skype for Business 2016 and CUCM 11.5 Integration Issues.

[bwolf]

CUCM System version: 11.5.1.14900-11

Skype for Business 2016

We're integrating Skype for Business with our CUCM 11.5 cluster.  We have a trunk setup between SFB and CUCM, it's up and fine. 

I am able to dial the SFB extension we have set up (7779) from the skype client and we get the conference welcome as expected.

Now that we have it set up, I should be able to dial my desk phone extension from Skype and have it call my desk phone.  Which, it does.  My desk phone rings and shows  the correct caller ID info for the call, but when I answer my desk phone, the call immediately drops and the skype client says "The server cannot forward the call. Please try again" with a Retry button.

I have attached the document I followed for the set up. I think it's pretty much the standard guide based on what I've been found online.

I'm stuck at this point because I don't know where the forwarding it's referring to is.  I assume it's somewhere in CUCM, but I can't find any reference to it in any support documents.  I also don't know where to go to get support for this...Cisco? Microsoft? Both? Neither?

I'm also not sure what logs would be helpful or how to go about using wireshark to try and get an idea of where this is failing.

Has anyone else seen/had this issue before?  I feel like it might have something to do with the dial plan, but I don't know how to be sure.  It's really weird that it places the call, lets me answer, and then the call just disconnects immediately.

Any help/starting points for troubleshooting would be greatly appreciated.

Thanks

[Maren Mahoney · Accepted solution]

The behavior you describe - dial call, it rings, called party picks up, call disconnects - is most often caused by codec negotiation issues. I have not done a Skype integration recently, but the documentation is pretty good so if you followed the instructions you should be ok.

The question, if I'm right about the codec problem, will be figuring out where the negotiations are occurring and what is being sent. I would suggest that you gather SIP debugs/traces from the devices in the flow of the call and analyze the SDP information to see who is sending what requests and what the replies are. The problem may stem from early offer vs delayed offer, an unavailable or incorrectly-configured transcoder, or simple equipment incompatibility.

If you gather the information and either don't know how to analyze it or can't figure it out, you can post it here and we may be able to help.

Maren

[bwolf]

Hello Maren, thank you for your reply.  We confirmed codecs on SFB and CUCM side are both G.711 and G.722.  But, I could only verify this based on the settings for SFB and CUCM, if they're actually playing nice, I have no idea.  So, I'm going to look into figuring out how to collect SIP debugs/traces.  This is all pretty new territory for me, so it will probably be a slow process getting that figured out today.  Once i figure that out, I'll see if I can cypher anything out of the logs and make sense of it.  If I can't, i'll head back here :).

Thanks!

[bwolf]

Thanks for your help!  It was indeed a codec issue causing the call to immediately drop.  Working with TAC on the other issue of getting a fast busy when dialing the SFB conference extension from a desk phone, they seem to be baffled.