Great work on all of these...very helpful.   A note on #7 - the javax.sound.sampled.AudioSystem.getAudioInputStream() method requires an input stream source that supports mark/reset (AKA stream navigation). Recorded prompts in UCCX, when using the .getInputStream() method, do not support mark/reset. I had to modify the code to utilize a java.io.BufferedInputStream as so:   {     try {         Document Recording = (Document) DP[5000]; // Only here to get a Document for sample         java.io.BufferedInputStream bis = new java.io.BufferedInputStream(Recording.getInputStream());         javax.sound.sampled.AudioInputStream ais = javax.sound.sampled.AudioSystem.getAudioInputStream(bis);         int avail = ais.available();         return avail / 8000f;     } catch (Exception e) {         return -1;     } }   EDIT: Forgot to mention, this was on UCCX 11.6(2).   Thanks! Ryan ... View more

The CUCM system at 192.168.0.103 is denying the SIP invite from the gateway at 10.7.75.154. This is likely due to the voice gateway routing the SIP invite from the wrong IP of the router, and CUCM doesn't recognize the IP. To get to the reason for this, we'll need to see the CUCM dial-peer configs. Could you provide the dial-peer config for CUCM? Also, could you provide the ip routes configured on the gateway? This could impact IPs like this also.   013346: *Aug 12 21:58:38.588: //25069/B3C6CF8B9D52/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 503 Service Unavailable Via: SIP/2.0/UDP 10.7.75.154:5060;branch=z9hG4bK1DEBA0 From: <sip:976637000@10.7.75.154>;tag=F8C460E4-2F8 To: <sip:11307431111@192.168.0.103>;tag=1407918946 Date: Sun, 12 Aug 2018 22:20:51 GMT Call-ID: B3C807DB-9DB111E8-9D58BC10-BA50BE76@10.7.75.154 CSeq: 101 INVITE Allow-Events: presence Warning: 399 CUCM "Unable to find a device handler for the request received on port 51614 from 10.7.75.154" Content-Length: 0     Ryan ... View more

Also, a "debug ccsip messages" and "debug ccsip error" can help illuminate the cause of the 500 error.     Ryan ... View more

The 500 error appears to be caused by the next hop circuit refusing the call. The call is being refused due to a "channel unacceptable" error, which roughly translates to a 500 error via SIP back to source:   *Aug 11 20:06:32.228: ISDN Se0/1/1:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x80A3 Cause i = 0x8286 - Channel unacceptable   Once that error is resolved, we can take another look at the 400 error (if it still exists). I recommend checking the settings (or working with corresponding admin to check settings) of the system on the other end of the ISDN circuit to make sure settings are aligned.   Ryan ... View more

Are you able to post a configuration (removing usernames/passwords and public IPs if present) so that we could see what the gateway config looks like? This could be related to the calling party name/number not coming in to the gateway from CUCM as well, you may need to run some debugs during a test call to see if the information is making it to the gateway.   Ryan ... View more

Nothing major looks off to me in the config. It's one of the URLs it isn't happy about - I think it might be the contact header, but not 100% certain. Next step would be to enable some debugging to see what the gateway doesn't like:   no logging monitor debug ccsip messages debug ccsip error logging buffered 1000000 debug clear log <make a test call> undebug all show log   Post the show log output here.   ... View more

The call may be hitting another inbound dial-peer, causing the translation not to occur.   I recommend, during off-peak times, running "debug voip dialpeer inout" (do NOT use terminal monitor - use buffered logging instead - "logging buffered 1000000 debug") and then making a test call. The output will show you which inbound dial-peer is being hit.    Ryan ... View more

Could you attach the gateway config? (sanitize passwords and any public IPs out)   Ryan ... View more

There is a debug command, "debug vpm signal" which roughly translates to "debug voice port module signaling"   Run this debug while a call is attempted and see what the output shows. Either log it to buffer and review buffer: "logging buffered 500000 debug" or use terminal monitor: "logging monitor debug" & "term mon" ... View more

I recommend pulling call manager traces so that the call can be analyzed using translator X. You may find the issue is that the call is not being placed as expected, for example. CDR logs may also help see this. ... View more

Hello,   What model and IOS version is the CUBE?   Thanks! Ryan ... View more