How to Make Specific Calls "unanswerable" but Stil

1. Brekeke Product Name and Version: Responder SIP Server 3.14.0.7/557

2. Java version:
Eclipse Adoptium 11.0.17

3. OS type and the version:
Windows Server 2019

4. UA (phone), gateway or other hardware/software involved:
Whistle iOS Softclient
5. Your problem:

Need a way to prevent a phones from accepting/establishing audio specific INVITES. I can match on the types of calls but have not found a deploy pattern that prevents it from "answering" the call

How about.. rejecting a call with a SIP response such as "404 Not Found" with $response.

https://docs.brekeke.com/sip/response

[deploy pattern]
$response = 404

I tried manipulating that in the deploy pattern but then the call never rings the phone. If I could find a way to match on the status message I could change the response code but none of the match patterns seem to trigger on the status code(s).

Do you want to reject a specific call after a phone rings?

I suppose, we send a specific call type to multiple phones, if a phone declines the call their phone stops ringing while the others continue. If someone accepts the call and then hangs up we start ringing all the handsets again. That's why I'm trying to suppress the ability to accept the call. Does that make sense? I know it's a tad convoluted

Brekeke PBX's Ring Group feature will meet the requirement.

https://docs.brekeke.com/pbx/ring-group

I suspected as much, my customer is not entertaining the upgrade to the PBX product and was trying to configure the SIP Server to do it. I was able to do it with a softclient by providing a codec payload the client couldn't use but when doing this with a mobileheartbeat device it won't ring the phone with an unusable codec

What does "types of calls" mean?
Audio codecs, SIP-URI or something else?

The INVITES originate from the Nurse Call system which is generating a "call" based on activity initiated in the Nurse Call System. The event is an urgent level call which is why after an accept we send a fresh invite to all of the recipients of the call. Since we add the "call type" in the calldisplay portion of the From field I can reliably match on that value but I don't want to match on the INVITE, I want to match on the OK the phone replies with for that call.

> I want to match on the OK the phone replies with for that call.

Is it "200 OK" response?
What do you want to do if a call matches "OK"?

That's when I want to send the responsecode 404 or 603

Do you want to send 404 or 603 on the same SIP session what "200 OK" happens? or other SIP sessions?

I would want to send those response codes for the same session for the 200 OK I am matching on

Feicstur,

Is it for terminating a call that the UAS accepted with "200 OK"?

Since these SIP response codes are "Final response" according to RFC3261, the UAC (caller SIP client) might ignore 404/603 because it already received "200 OK".

Why do you want to terminate a call with 404 or 603 even after the call was accepted with "200 OK"?

because I want it to ring but not be answerable. Cancels and BYEs are okay but the 200OK causes unwanted behavior for the customer. I know this is a weird request and not normal. Weird and unusual is par for the course when supporting hospitals

Do you want to keep ringing until a called party picks the call up ?
Do you want to disconnect a call immediately if a called party picks the call up ?

Disconnect immediately if the called party picks up

My idea is to set the talking timer 1 ms.

Put the line below in the Deploy Patterns of the rule. If so, the call will be terminated just after 1ms from "200 OK".

The default value is 259200000 [ms] (=3 days) which you can tune at [Talking Timeout (ms)] in the [Configuration]->[SIP] page.

when I use that deploy I get an 404 session not created in the error log

It depends on existing DialPlan rules.
Did you put "&net.sip.timeout.talking=1" in the current rule? or new rule?

If it is new rule, you might need to add $continue=true in Deploy Patterns too.
[Deploy Patterns]
&net.sip.timeout.talking = 1
$continue = true

If you still get "404", other DialPlan rules may be influencing.

wasn't fast enough, same unwanted behavior

Have you push the [Apply Rules] button after you modify any DialPlan rules?

What kind of SIP entity are you using as the call destination?
Is it registered in the SIP Server or did you specify the destination's SIP-URI or IP address with any DialPlan rule?

Does the destination phone ring if you disable the DialPlan rule which has "&net.sip.timeout.talking"?

SIP client that is registered with Brekeke
Disabling the dial plan rule rings the phone
I click apply rules after every dial plan change

> Disabling the dial plan rule rings the phone

Have you put "&net.sip.timeout.talking=1" and "$continue=true" in the Deploy Pattern of the rule?


> Disabling the dial plan rule rings the phone

Check the rule names which applied the call.
Go to [Logs]->[Session Logs] page, click the date and find the rule name at [Rule Name] filed.
Are there any rule names there other than "registered=" ?