Digital Receptionist - call leg problem

[macery]

We have situation where some of the inbound calls are not successful.

We investigated the issue and it seems that this is the case when using IVR as the first inbound rule for caller.

SIP trunk (Generic) - DID -> IVR -> (whatever and unimportant)

Incoming call comes to IVR, but caller doesn't hear anything (like it is one-way audio issue). Wireshark says that RTP packets are sent from 3CX (we can hear audio), but there's no RTP answer and the whole thing results with this log entry:

10:31:46.314|000005a0| Warn|MSEndPoint.cpp(810): 5:[MS105000] C:1677.1: No RTP packets were received:remoteAddr=xxx.xxx.xxx.xxx:14630,extAddr=<none>,localAddr=xxx.xxx.xxx.xxx:9708

Firewall green, all ports correct. The same issue with 3CX v15.5 SP6 (on-prem) and 3CX v16.0.676 (on-prem), but also tested with PBX express cloud instance (OVH).

To narrow down what we concluded, we were asked to slow down 180/200 OK sequence as it is sent in the same milisecond. I didn't find that this is possible in 3CX. Maybe some parameter I'm not aware of.

When incoming call gets answered by IVR, in the same milisecond 180 ringing and 200 OK is sent before other side managed to send PRACK to 180 Ringing. Because of that, leg wasn't correctly closed and call failed.

It should be 180/PRACK/200 OK and then 200 OK, but what happens is 180/200OK/PRACK/BYE

As a workaround we mapped DID to dummy ring group with one dummy extension and then after few seconds ringing to IVR. After that call leg sequence was okay, but this is just workaround. Is there any chance to delay a 180/200 OK sequence a little bit?

 

[AWS2P]

your SIP provider is one 3CX supported?

 

[macery]

your SIP provider is one 3CX supported?

No.

It was working for years, I think from version 12 and it started to happen in version 15.5, as far as I'm aware of. Not all calls were problematic.

 

[AWS2P]

It was working for years, I think from version 12 and it started to happen in version 15.

Ok but unfortunately this is no more as you have problems. I'm pretty sure it's not possible to set something on sip signalisationto slow down answer.
The best you can do is to use 3cx supported Providers, this is surely time to think about

 

[macery]

@aws2p thank you for your answer.

I would like to hear somebody from 3CX. This is something what could be adjusted in IVR core as it is already working if inbound rule mapped to extension, ring group, etc.

 

[JohnS_3CX]

Hi macery

PRACK is not supported. Ask you provider to remove it or switch to a supported provider.

When invites are sent to the PBX there is an "Allow" field. The provider might include PRACK there, but we won't. In this case the provider is probably not honoring the invite and doing whatever they want.

There is no delay adjustment or need (in answer to your original question).

 

[macery]

Provider asks me:

"
B number replied with 180 ringing to INVITE and this reached to TAS with 100Rel supported header.

Now since in FQDN we can see Reliable request/response is acivated so , TAS is adding 100Rel required header.

RELIABLE RESPONSE HANDLING

REQUEST.....................: TRUE

RESPONSE....................: ONLY WITH PAYLOAD

Now upon receiving PRACK from A number TAS is not forwarding this PRACK to B number due to above reason (B sent 100Rel support) hence this PRACK/200OK could not be completed.
"

 

[JohnS_3CX]

This does not seem like a question, but rather they are explaining what happens.

Can you get a clarification of what they mean by this?
"Now since in FQDN we can see Reliable request/response is acivated "

Where do they see that exactly? An FQDN is just a domain name, it does not say anything about SIP.

 

[macery]

Sorry, they asked to add Require:100 Rel in 180 Ringing

 

[JohnS_3CX]

Hi macery.

Thanks, I understood now. Like I mentioned earlier, we do not support 100rel and hence the PRACK that would go with it.

As per RFC, this is an optional capability and the provider should be able to function without it.

And what I mean when I say optional, is that by 3CX not including 100 Rel the provider must still able to process the call regardless. I do not know why they want to enforce an optional capability when it is not mandatory but I guess they have their reasons.

In this case, I think you will not be able to get the required functionality when using this provider because they are enforcing something that is optional.

 

[macery]

Okay thank you for the clarification. I will forward this to our provider, I hope that they could fix it.