Queue Calls Dropping - SIP 200 OK Issue

[contoured]

I have a customer using an unsupported SIP provider (I know, I know) and they are experiencing frequent call drops after ~20 seconds on inbound calls to queues. This customer has been working with a top engineer at the SIP provider and after reviewing some packet captures he demonstrated that the 3CX is sending a "180 Ringing" and a "200 OK SDP" at almost the same exact same time. Apparently this causing the SIP providers switch from responding appropriately to the "200 OK SDP" so eventually 3CX terminates the call.

Any insight on how to address this would be appreciated. The engineer mentions that in FreePBX or Asterisk there is a parameter that allows you to delay the 200 OK.

 

[cobaltit]

So since there is a parameter that allows you to delay it but it's enabled by default that sounds like a work around to deal with equipment that doesn't behave properly (like the SIP providers switch) but that the default behaviour should be fine for SIP compliant equipment. I don't recall ever seeing anything that could adjust something like this so my guess is that 3CX is going to tell you to use a supported provider or that your provider is going to have to make the fix at their end. I supposed the third option if the first two aren't feasible is put a true SBC in between.

And not that I believe it will fix the issue but just in case, what version of 3CX is this on?

 

[YiannisH_3CX]

Hi @contoured

There is no option in 3CX to delay the 200 OK message to the provider and honestly there was never a need for one. I would recommend using a supported provider that can properly process this.

 

[contoured]

Hi @contoured

There is no option in 3CX to delay the 200 OK message to the provider and honestly there was never a need for one. I would recommend using a supported provider that can properly process this.

Thanks for the insight. Changing providers may not be an option for this customer. More likely they will change the PBX. Looks like they are not the only ones experiencing this issue. Here is a post from a few months ago with the same exact issue.

https://www.3cx.com/community/threads/digital-receptionist-call-leg-problem.69181/

 

[cobaltit]

One post among thousands, and you can see in the explanation that 3CX is adhering to the RFC and the provider is not. This is likely the case here as well. If the customer is not able or willing to switch providers then the option is to put a SBC between 3CX and the provider (I would confirm with the SBC vendor that they can resolve this issue first) or change PBX as you mentioned.

 

[contoured]

One post among thousands, and you can see in the explanation that 3CX is adhering to the RFC and the provider is not. This is likely the case here as well. If the customer is not able or willing to switch providers then the option is to put a SBC between 3CX and the provider (I would confirm with the SBC vendor that they can resolve this issue first) or change PBX as you mentioned.

SBC is not a bad idea. Do you have any recommendations? I would hate to lose this rather large license/customer.

The reason it's not so easy to switch is that they have a great relationship with their current provider and absolutely killer rates for their volume. We've shopped and none of the supported providers were satisfactory.

 

[cobaltit]

Patton, Ribbon or Edgewater come to mind. Not particularly familiar with either of them and none of them are 3CX certified so you'd be relying on the vendor to help with configuration. In that light Patton might be the best choice as their gateways are 3CX certified so they know who 3CX is and they have good support. @eddv123 can probably help more in this area as I seem to recall he mentioned working with one of the aforementioned SBCs

 

[eddv123]

There is no option in 3CX to delay the 200 OK message to the provider

SBC's can do something called SIP normalisation the device can work in pass-through modes but in this scenario terminating the leg and re-generating will enable you more options for manipulating the call.

I am very surprised the provider cannot adjust to suit your need, however as @cobaltit says it could work for you in the opposite direction if an SBC is used in front of 3CX.

Despite my amount of support on Patton gateways on the forums, I have never actually used their SBC's.
I have used Edgewater and Audiocodes however.

Audiocodes are very flexible, but due to this can be found to be complicated, Edgewater SBC's I found the best to integrate with 3CX (I used the 2900E) however the first question would be where is your 3CX system (on premise or hosted) ?

 

[contoured]

SBC's can do something called SIP normalisation the device can work in pass-through modes but in this scenario terminating the leg and re-generating will enable you more options for manipulating the call.

I am very surprised the provider cannot adjust to suit your need, however as @cobaltit says it could work for you in the opposite direction if an SBC is used in front of 3CX.

Despite my amount of support on Patton gateways on the forums, I have never actually used their SBC's.
I have used Edgewater and Audiocodes however.

Audiocodes are very flexible, but due to this can be found to be complicated, Edgewater SBC's I found the best to integrate with 3CX (I used the 2900E) however the first question would be where is your 3CX system (on premise or hosted) ?

Thank you for the suggestions. I'm going to look into the Edgewaters. This instance is on-premise. Windows VM recently upgrade to version 16 from 15.

 

[eddv123]

If on premise this should work even better.

The main problem that I recall we had with the SBC when I tested it was that it had some issues with working with hosted instances ( we trialled with the SBC on premise with the phones not PBX).

Trunk settings have a lot of the required connection settings which assist with the integration of the SBC where in our scenario we we connecting phones via the SBC (trunk was separate) which gave us limited configuration parameters.

Note: Edgewater has been acquired by Ribbon communications, however you should (dependent of where you are in the world) have a local representative you can contact - they are very helpful.