CUBE converts 180-Ringing to 183-Session Progress

[dgonzalez1]

Hello, I have a CUBE that, when calling from the inside to the service provider, is converting service provider response 180-Ringing to 183-Session Progress and, as a result, the caller heards no ringback tone.

I'm attaching the message interaction.

I found there is this bug CSCth89564 with a similar description, but it applies for older versions. I'm Running IOS 17.03.03. It also mentions it happens with 180 and 183 without SDP and in my case 180 and 183 are with SDP.
Any clue of which could be the cause?

(I'm not ataching a show run not to reveal my customer network info, but let my know if something could be necessary).

Thank you.

[b.winter]

Hey,

just to clarify:

You are receiving an 180 with SDP from the provider on one call leg, and CUBE sends a 183 with SDP on the other leg?

If it is like that, then it's the default behaviour.

To change that, you can use the command "send 180 sdp"

[dgonzalez1]

Yes, that's correct.

Now I applied the "send 180 sdp" to the tenant that is applied to the dial-peers and asked the customer to test.

I will let you know as soon as I have news.

Thanks.

[b.winter]

Ok, sounds great.

[dgonzalez1]

Yes, but unfortunately, they've just tolds me that it continus to work the same way.

I applyed the command to the tenant, as I said:

voice class tenant 300
connection-reuse
options-ping 60
send 180 sdp
session transport udp
bind control source-interface GigabitEthernet0/0/0.118
bind media source-interface GigabitEthernet0/0/0.118
early-offer forced

and tenant was already added to caller's incoming and outgoing dial-peers.

Should it be enough?

[b.winter]

That's interesting.

According to the doc, it should be exactly the command that you need:

Another example of local logic in regard to provisional response handling is changing
the messages received on one call leg into another type for the egress call leg. This can
be observed if CUBE receives a 180 response with SDP. This message is converted, by
default, into a 183 Session in Progress with SDP unless the command send 180 sdp is
enabled

Maybe you can try to put it under "voice service voip --> sip" as a global command.

Another chance is to block 183 with SDP with "block 183 sdp present" or a combination of both commands

[TONY SMITH]

Another option is to disable early media for 180 responses.  You're receiving 180/SDP which means the other party is going to play you actual audio of the ringing tones.  If you add the configuration  "disable-early-media 180" under "sip-ua" then the CUBE will pass the 180 message on without SDP, meaning that the calling party will generate the ringing tone locally. 

[dgonzalez1]

Hi Tony, not actually. The customer seems to have forgotten the issue and I got involved in other subjects.

My next courses of action, that I has no opportunity to try, were first: to be sure the call was entering by the dial-peer where I applied the change (because there were several, and based in the config it could be actually using another than supposeed. I wanted to confirm that with a 'debug voip ccapi inout'). And second, it that neither worked, I was thinking in applying the change globally.

I hope you have luck with it.

[TONY SMITH]

You can identify the dial peer from the call history or call active records.  For example to show DPs in use for active calls ..

sh call act voice | i PeerId

Or from the call history using a specific call ID ..

sh call history voice callid xxxxx | i PeerId

[JP 54]

Hello, I am facing the same issue, were you able to get a resolution ?