cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2964
Views
30
Helpful
21
Replies

external Calls to UCCX trigger Failing

PenielIpo3099
Level 1
Level 1

I need assistance;

I have a 11.5 su3 CUCM and UCCX 12.0. I have configured UCCX all internal trigger is working. cti port registered.

I also have an ISDN PRI with 100 number range. the current setup is that the first number range is translated to the CUCM DN. The rest of the numbers in the range is unused.

Is it possible to use one of the numbers in the range and point it to the trigger? I have pointed one of the number range and pointed it to my CUCM extension and its working, however, when I replace my number with the UCCX trigger, its not working. Am i missing something? Please assist what to do.

2 Accepted Solutions

Accepted Solutions

@PenielIpo3099 Though the SIP logs that you sent are incomplete, they do contain enough info to show that the issue is related to codec mismatch (Reason: Q.850;cause=47).

Please apply the following changes to your gateway as I previously suggested to both dial peer 1 and dial peer 1000. This will resolve the codec mismatch issue.

voice class codec 10
codec preference 1 g711ulaw
codec preference 2 g711alaw
codec preference 3 g729r8
!
dial-peer voice 1 voip
voice-class codec 10
no vad
!
dial-peer voice 1000 voice
voice-class codec 10

I understand that you do have a transcoder configured but it is not triggered possibly due to misconfiguration. As I mentioned before, you don't need a transcoder in your scenario. Please apply the changes I provided above and test again. If for some reason, the calls still fail, please share the output of "debug ccsip messages" and your new gateway configs (after the change). 

See below the ladder diagram of the SIP traces you provided, and the call disconnect reason code.

TechLvr_0-1664765204223.png

 

 

View solution in original post

From your shared configuration I can see that you have not set the voip dial peers to use the configured codec list. With this your dial peers are still set to use g729. Please configure the voip dial peers, both number 1 and 1000 to use the codec list as both me and @TechLvr has suggested a few times.



Response Signature


View solution in original post

21 Replies 21

TechLvr
Spotlight
Spotlight

In CUCM, make sure the inbound CSS of your SIP Trunk/Gateway can reach the partition of the translation pattern (that xlates the DID to UCCX trigger). Next, make sure the CSS of the translation pattern can reach the partition of your UCCX trigger. 

Also, if your UCCX is configured for g711, make sure the region relationship between the SIP Trunk/Gateway and your UCCX CTI RP/CTI ports is set to 64kbps. 

 

Thank you. Let me check this. Will get back to you.

Should I create a SIP-Trunk betwoeen the CUCM and the UCCX?

No. You cannot create a SIP Trunk between CUCM and UCCX. That's because UCCX does not use SIP; it uses  CTI for call routing. Based on your initial post, since internal calls to your trigger works, you already have CTI Route Points and CTI Ports so you're good there. 

In my previous post, I was referring to the inbound Calling Search Space on the link between your CUCM and Voice Gateway. Not sure if you have a SIP trunk, a MGCP Gateway, or a H323 Gateway, but regardless, you need to verify the calling search space it uses can reach the partition of the UCCX trigger(s). (This is done on the CUCM)

Alternatively, as Roger mentioned, you can change the Calling Search Space for Redirect on the Trigger configuration page in UCCX to Rout Point Address Search Space. (This is done on the UCCX)

@PenielIpo3099 Apart from this if the trigger redirect CSS setting has not been altered from the standard when creating the trigger then you'll need to make sure that the calling endpoint CSS has access to the partition where you have placed the CTI ports. This would in your scenario of external calls be the incoming CSS used on the Trunk/Gateway.

For additional details on this see this from the online help.image.png

To give an example from another system landscape we do not have the partition of the CTI ports in the calling device CSS, so we have changed the setting for the redirect CSS on all our triggers to this.
image.png
With this it is the CTI RP CSS that is used when passing the call(s) to the CTI ports.



Response Signature


PenielIpo3099
Level 1
Level 1

Hi @TechLvr / @Roger Kallberg Roger,

I have done all thats advised but still fails. Please refer attached my dial-peer. Should i create one specifically for the interested number on the VG? 3123430 is the called number which is supposed to be xlated to 2825 (UCCX Trigger)-and that should be captured in the current dial-peer. When i remove the UCCX trigger and replace it with my extension number, it dials, however, not UCCX trigger. 

If I understood correctly, you said when you point the translation pattern 3123430 to your extension, the call goes through but the call fails when you point it to the UCCX trigger.  

That’s most likely a calling search space issue. Can you make sure the Calling Search Space of your translation pattern contains the partition of your UCCX trigger. 

Also, what codec is your UCCX configured for? I don’t see any codecs hardcoded on your voip dial-peer, and so it’s using the default g729. If your UCCX is configured for g711, then you have a codec mismatch which results to call failure. If that’s the case, can you apply the following change to your gateway.

voice class codec 10
codec preference 1 g711ulaw
codec preference 2 g711alaw
codec preference 3 g729r8

dial-peer voice 1000 voice
voice-class codec 10
no vad

 

1. Checked CSS and same all-across. There hasnt been any change on the UCCX. I changed the extension only with no result. CTI route point has the same CSS, Trigger has the same CSS, xlation pattern has the same CSS-all in one partition. 

2. Codec for uccx, when i configured was g711ulaw. On the VGW i have configured as per below:

dspfarm profile 1 transcode
codec g729abr8
codec g729ar8
codec g711alaw
codec g711ulaw
maximum sessions 10
associate application SCCP

Have you verified that the gateway/trunk inbound CSS and outbound CSS on the TP has access to the partition(s) where you have the CTI RP and the CTI ports? Also if you take a look at the trigger in CCX what is the redirecting CSS set to? If it has not been altered from the default any calling device, including gateway and trunks, need to have access to both the partition of the CTI RP and the partition of the CTI ports used by CCX. However if it is set to use route point CSS the CSS set on the trigger, aka CTI RP needs to have access to the partition of the CTI ports.



Response Signature


The both CSSs have access to the partition- The Pstn CSS has access to internal partition. same partition in the SIP GW, CTI  ports, CTI point, Trigger and Xlation pattern-I just dont know where i am getting wrong. For redirect, refer below: 

PenielIpo3099_0-1664521236598.png

 

 

@PenielIpo3099 
What you have there is a transcoder. You should avoid invoking transcoders when it is possible to prevent mismatches. In your case, you can simply add the voice class codec that I suggested in my last post. Since you use a PRI trunk on the carrier side, your carrier does not dictate what codecs to use, and you have full control over your codec list.  The only codec negotiation that happens is between your voice gateway and CUCM/UCCX, not the carrier. 

As Roger pointed out, you can also apply the voice class codec to your dial-peer voice 1 voip for good practice but that’s related to outbound calls, not inbound. For inbound calls, you definitely need to apply the voice class codec to your dial peer 1000. 

I have already configred as per your advice. Should i disable transcoder?

Can you please share the current configuration of your gateway, after the changes that you say that you have made, and a screenshot of the compete trigger configuration, especially for the redirect CSS, and of any CSS that is apart of the call routing for this specific call scenario? Also please share a screenshot of your CTI port configuration from CCX.

You can keep the transcoder configuration. Is the xcoder btw registered in CM and also setup in an MRGL/MRG that the endpoints in the call can access?



Response Signature