Call shown as failed since V20 upgrade

[JoshuaM]

Hello,

since upgrading one of our customers to V20 we are having some problems with calls which should be declined.
In this example the caller called an extension directly. This extension was not available and these settings should apply:


And the log is showing the following, with the error being the last entry:




The problem with this is that our provider gets the following message (got this from them, but censored the IPs and phone numbers):

25.06.2024 09:15:14.040 +02:00: 185.*.*.*:50195 --> 89.*.*.*:50195
SIP/2.0 480 Temporarily Unavailable
Via: SIP/2.0/UDP 89.*.*.*;branch=z9hG4bK1eaa.e48879f0bbde9109a8f30ee095e06023.0
Via: SIP/2.0/UDP 89.*.*.*:5070;received=89.*.*.*;rport=5070;branch=z9hG4bKHc8v4BS82BgUe
To: <sip:083****27@89.*.*.*:5060>;tag=306b614f
From: <sip:004983****226@89.*.*.*>;tag=Z9230pv84eacN
Call-ID: 5ab4f9b8-11fc-44a9-aef3-2ea45a729a86
CSeq: 85096064 INVITE
User-Agent: 3CXPhoneSystem 20.0.1.731 (731)
Warning: 499 ***.on3cx.de "Not available"
Content-Length: 0
--> They are getting a 480 Temporarily Unavailable with Warning: 499

As the provider (which is not an officially supported one by 3cx) is getting this message, the provider assumes the call was not successfull and forwards the call towards the backup number we have set up in case the entire SIP-Trunk goes offline.

Does anyone know if this is an error on the 3CX side, something modifiable on the 3CX side or if it's something the provider must do.

Regards,
Joshua

 

[OlegR_3CX]

Hi Joshua.
Why are you ending the call on the user? What is your goal there, and why not routing the call somewhere else if this is your goal?

 

[JoshuaM]

Hey Oleg,
the goal is just to end the call - thats it, nothing afterwards. The problem is that since V20 the message that gets changed to the provider (probably) changed, and thus the provider thinks the call didn't get cancelled correctly and is forwarding the call to their backup number in case of the trunk being offline.

Of course i could experiment sending calls to a digital receptionist but getting all users to use that instead of just the "end call" option would probably not work very well.

 

[OlegR_3CX]

You can't modify SIP code on that 3CX send, and this is expected to send 480 Unavailable when Send Busy on our end.
Maybe you can send the call to the IVR and after 1-second end the call, but this will be 200 OK as the call will be answered. Extension settings also have 302 reflection, you could use this one too.

 

[JoshuaM]

Thanks! So are you saying the log entry is correct as it is? I thought the 2nd last line was an error?

 

[OlegR_3CX]

Yes, log is OK, as there is no other forwarding and saying NotAvailable for the reason,

Failed to build divert target EndCall.DisabledByFwdRule; fail reason = NotAvailable

and then followed after

Inv[SentInvite&Neutral]} terminating with reason 'Not available', code = 480

 

[JoshuaM]

Ok, so it seems the provider has "a problem" that a warning-header is included, and not just the 480 error / message. It seems we therefore can't use the "backup-number feature". Since disabling it, everything works fine, thanks.

 

[OlegR_3CX]

Great! Let us know if it's all good and i will close this thread too.

 

[JoshuaM]

So it seems we actually have a big problem with v20 regarding this (i am saying v20 because v18 seems like it sends a different message? - not sure though, haven't tested it, because there is no problem with v18 regarding this). When calling any extension which is set to end call, the provider gets the said warning-header and thus tries to reach the 3cx again which results in tons of missed calls from just one call.


I do realize this is not an officially supported provider, but do other providers just ignore the 480 error with a warning-header? The provider here said a 486 Busy here message or just the 480 without a warning-header would fix the issue

 

[OlegR_3CX]

So in your case, there are multiple invited to the extension?
If you run the report, you see that the provider is keep on sending you new calls over and over again?

 

[JoshuaM]

Yes, the provider confirmed this. As they get a 480 with a warning header they automatically try to send the call again

 

[OlegR_3CX]

Maybe you can change this on the provider and request to accept our message.

 

[JoshuaM]

I've asked the provider, but they kind of already said they can not (or maybe will not) adjust this. Will see how they respond by asking directly.
Did something change in this regard in V20 compared to V18? We've never had this problem before (i can replicate this on other V20 machines).