CUBE not sending ACK in response to 200 OK

[steveAkerman]

On outgoing calls via CUBE, ITSP is replying with 183, followed by 200 OK.

The 183 is sent to the UAC, but the CUBE is not transmitting the 200 to the UAC, and is not replying to the 200 with ACK. As a result, the call is dropped either by the UAC or by the ITSP.

There was an issue on earlier versions with CUBE not handling 183 correctly linked to the Contact: containing a dns which could not be resolved (or resolved in time).

I have tried implementing the workaround in case this was a similar issue, which was to drop the Contact: header.

However, whether I try to drop or modify the contact header, the changes do not take effect, but are reported correctly by debug

Apr  5 2022 10:17:58.541 CEST: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_modify_remove_header: Contact is removed from the SIP message
Apr  5 2022 10:18:02.641 CEST: //1536/ACCC218E844B/SIP/Msg/ccsipDisplayMsg:
Received: 
SIP/2.0 200 OK
Call-ID: ACCD5A76-B3EF11EC-84519600-967845B6@109.28.240.88
Via: SIP/2.0/UDP aaa.bbb.ccc.ddd:5060;received=aaa.bbb.ccc.ddd;branch=z9hG4bK5FA807
To: <sip:00442087599036@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=6220a085-624bfb1b38800acf-gm-po-lucentPCSF-046126
From: "+33123456789" <sip:+33123456789@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=9106844-0
CSeq: 101 INVITE
Accept-Encoding: identity
Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,SUBSCRIBE,NOTIFY,INFO,REFER,UPDATE
Contact: <sip:lucentNGFS-154644@pcgw-0006.imsgroup0-012.mit2isc12.ims.sfr.net:5062;x-afi=5>
Content-Type: application/sdp
Server: Alcatel-Lucent-HPSS/3.0.3
Session-Expires: 3600;refresher=uas
Supported: timer
Timestamp: 1649146651
Content-Length: 205

I would appreciate any assistance in resolving this issue either in getting the CUBE to send ACK and retransmit, or by helping me to understand why the sip-profile is not taking effect as a possible workaround

Thanks

[Roger Kallberg]

It would help if you could share your SBC configuration for us to validate it. Mask out any sensitive information, but please keep the overall structure intact.

[steveAkerman]

Thanks for your reply Roger.

I have advanced a little, and am still cleaning up, but the issue is (partially) resolved - pending further testing!

2 problems:

1. ZBFW was blocking dns from self to internet

This did not really fix, just made the calls drop faster when fixed, as the host is not resolved even on the operators servers.

2. Host is not resolved

It appears that CUBE just consumes 200 OK if the contact cannot be resolved.

I had expected that the outbound proxy would remove this constraint as the IP of last resort, but no.

The workaround has so far to create a local ip host record for the contact host to the proxy, and that works.....but as this is IMS, and I guess there will be many contact dns, for how long?

As an aside, my initial post was incorrect: 

sip-profiles are applied AFTER processing by CUBE inbound, and not before - a strange state as it would be better if it was the reverse - so my initial observation was probably wrong in that the rules were applied, but to the preceding message

I will post my voice config after cleaning it up  so as not to obfuscate with all of my trials.

[b.winter]

Honestly, I personally don't really get the point you are talking about / having issues with.

In my opinion, you just through in pieces after pieces of your problem and your troubleshooting already done, but don't come up with any further details like setup, config or debugs.

You mention something probably about a bug, but don't post the Bug-ID, so others also can make up their on mind about it.

You are talking about UAC, but taking into account that CUBE is both UAC and UAS at the same time, doesn't make it any easier for at least me, to follow up.

I also don't get the point, what the contact header should have to do with any DNS resolution problems. And then suddenly, you mention something about the outbound proxy.

So:

- How does the setup look like / which systems are involved?

- What's the call flow? From which system to CUBE / From CUBE to which system?

- Add the logs of the debugs and write the calling and called number

 debug ccsip all or only of debug ccsip messages

 debug voice ccapi ind 1

 debug voice ccapi ind 2

 debug voice ccapi ind 74

- Add the config (without any sensitive info)

- Get the output of show hosts

[steveAkerman]

Thanks for your reply, and sorry if the problem was not clear. After my original post, I continued working on the issue, rather than just waiting, and eventually found a partial solution. For posterity, the set-up is:

UAC <-> CUBE <-> ITSP running Alcatel/Lucent IMS

CUBE running on 2921 with IOS 15.7.3

The problem was, as defined in the header, that the CUBE was receiving a 200 OK from the ITSP on outgoing calls, but was neither replying with an ACK, nor forwarding the 200 OK to the UAC, hence the call drops after 25-30 secs, when the retry counter of the ITSP hits its limit for resends of 200 OK.

The issue is that when the CUBE receives a 200 OK, it looks to reply via the Contact, which in this case is a dns that cannot be resolved. In this case, the CUBE does nothing and eats the 200 OK (and does not forward it to the UAC).

My expectation, was that if the Contact could not be resolved, the CUBE would send an ACK using the outbound proxy, and forward a 200 OK to the UAC; this is obviously false.

The resolution was to create an ip host entry for the contact host pointing to the proxy. Calls are now fine and the CUBE behaves as expected.

The remaining potential problem, is that in an IMS/3GPP system, I am sure that there are multiple possible contact hosts, and as soon as this changes, calls will fail again. I am therefore still looking for a solution that forces the CUBE, in the event of dns non-resolution, to use either the outbound proxy as host IP address for the ACK, or another default address.

The referenced bug, which was on a similar type of issue with 183, is CSCvf85462

I hope that this helps to clarify the issue, and would appreciate any assistance with the remaining problem.

[b.winter]

Please also share a complete output of debug ccsip messages

[steveAkerman]

Thanks for your reply

I am not sure that this will help now as I have (partially) fixed the issue. All that this showed though was the itsp sending 200 OK until a retry counter was hit.

With the fix to the dns issue above, the ACK stops this stream, although I am not sure that this fix is sustainable

[Shalid Kurunnan Chalil]

Hi, 

once we have the detailed debug output or the configuration, the community members can help you in a better way.

Meanwhile, I had seen similar behaviour recently when ITSP was expecting PRACK and the CUBE doesn't do this as expected. Could you please check or add the following Global :

voice service voip

  sip

   rel1xx require 100rel

in dial peer: 

voice-class sip rel1xx require 100rel

Regards, 

[steveAkerman]

Thanks for your input Shalid

I am obliged to set the rel1xx to disable as the uac does not accept - this was an earlier issue!

My problem is with 200 OK which are not affected by this

[Shalid Kurunnan Chalil]

Did you manage to resolve the issue or it is still occurring? if the issue is not resolved, Could you please send the complete output of the debug ccsip messages from your CUBE for a test call?

Regards

[steveAkerman]

I eventually found a solution to this issue by using dnsmasq. The issue was that the cube was sending ACK, but to the wrong ip because the operator was using a round-robin dns and the cube looked up the dns before sending the ACK. If it helps there is another thread created by me that resolves this issue.

https://community.cisco.com/t5/ip-telephony-and-phones/cube-outgoing-to-ims-sip-trunk-using-dns-for-session-target/m-p/4863023#M410667