Cisco CUBE Call forward to external no audio (only for external calling number)

[bpetit@axians.com]

Hello everybody

I have a problem with a SIP trunk and external calls forward to external. 

let me explain :

here is my configuration :

CUCM ----- SIP Trunk to -----> CUBE ----- SIP Trunk to -----> ITSP

inbound, outbound call work perfectly

internal calls forward to external work

external calls transfered to external, it's OK 

but for external calls forward to external, I have no audio (my mobile ring but no audio).

I post my CUBE configuration in attached and a debug ccsip message for a testing call (+33383449358 is the calling number, +33143126753 is the internal number forward to the mobile number 06...)

I already test to change the SIP header to make the calling number of the forward call a DDI number knows by the provider but without success.

The only things that's weird on the ccsip message debug is the SIP 183 session progress messages received, sent, received again... like if a loop appears !

If needed, i can post my CUCM SIP trunk configuration.

Thank for your help.

[cofi]

Hello,

I am having the same problem. Did you manage to solve this problem?

Regards,

Alex

[Ayodeji Okanlawon]

Can you attach your debug ccsip messages? Include the call details please. Calling number, called and forwarded number,

[cofi]

Attached the ccsip messages.

I have replaced in the debug the ITSP IP with XX.XXX.XXX.XXX

You will find the call details at the begining of the file

[Ayodeji Okanlawon]

Cofi,

Based on your logs here is what I see:

leg 1: PSTN------>CUBE: isbco4ktp4wd9drsqtko4tpd4vwsqitvtotv@SoftX3000

leg 2: CUBE--------->.CUCM: 801BB756-764211E9-93549002-D9FECD1@10.151.1.5

This leg advertises G711Alaw only

leg 3: CUCM-------->.CUBE ( forwardall):a9425980-cdc103c8-713397-43640c0a@10.12.100.67

This leg advertises only G711ulaw
leg 4: CUBE------->PSTN ( for forwarded call):8037A35A-764211E9-935C9002-D9FECD1@10.151.10.240

As you can see leg 2 and leg 3 advertises different codecs and this is likely because of the following:

1. Dial-peer to CUCM has only G711alaw configured

2. The codec preference list for the SIP trunk to the gateway is not setup properly

To address this, try and enable G711ulaw on the dial-peer to CUCM. Ie add multiple codec to the dial-peer doing the following:

voice class codec 20

codec preference 1 G711ulaw

codec preference 2 G711alaw

2. ensure that the audio bit rate for the region assigned to the SIP trunk is set to 64Kbs

If the call still fails collect another set of logs and then attach the CUCM SDL traces

[davidbognar]

Hello,

I understand where you are coming from with this, but to be fair I don't think this will be an issue.

Yes there is a codec missmatch, however this would not be the reason for external calls having no audio.

In case of a codec missmatch that cannot be handled by a XCODE or an MTP, the calls will fail.

The fact that the call is established and there is no auido would suggest another issue.

I am currently investigating pretty much the same issue, will let you know my findings.

So far what we found that if we enable anti-tromboning, on the CUBE, the issue fixes itself, however other stuff breaks.

Anti-tromboning should be used as a way to make a call more efficient not to fix broken call flows.

David

[Ayodeji Okanlawon]

This is ironic. I am having exactly the same issue with one of my deployments. It is not indeed a codec related issue it is an issue with the way ITSP handles media. When I used anti-thromboning as well the issue is fixed(however it breaks other call flows-hence had to remove it) and the reason is because CUBE is removed from the media path and CUBE tells ITSP to send media directly to itself. When you take a packet capture you will observed that the ITSP never sends media when the call is forwarded back out to the PSTN. Interesting thing is that this is ITSP dependent. I have this issue with Winet in Switzerland. With TATA I do not have the same issue.I am currently battling with Winet on this

[TONY SMITH]

Do you have a firewall between the CUBE and the ITSP?   I had this issue where the firewall did not have open ports for inbound RTP, but only allowed RTP to be received in answer to outgoing.   So in a call forward situation there is no outbound RTP from the CUBE until it has received inbound, which of course it can't.

[Ayodeji Okanlawon]

Tony it was a firewall issue. I had already asked them to check firewall a few times. In any case the resolution was to implement SIP ALG. Thanks

[Ayodeji Okanlawon]

Updates: 

This issue is now resolved by the ITSP. The solution was to implement a SIP ALG on their Fortigate firewall that sits between their SBC and our CUBE