Blocking duplicate calls from the same source.

1. Brekeke Product Name and Version:
Sip Server
2. Java version:
8.261
3. OS type and the version:
Windows 10

5. Your problem:
Hello all,

I am just wondering if you would know a way that I can block duplicate sessions that come from the same source. We have a Nurse Call system that uses SIP to call our PBX. The problem that we are running into is our nurse call system creates duplicate SIP Invites if not answered for 3 minutes. The bigger problem is that it does not cancel the original invite, it just sends a new one.

We are using the following Dial Plan to match.
$Request = ^ INVITE
$Registered = ^False
To=Sip (6.+)@
From=sip (1.+)\*(.+)\*(.+)@

The deploy pattern is
To = %1@IP ADDRESS
from %3@IP ADDRESS

(1.+) OR %1 is our room number or our nurse call sip device, which we are relaying to our PBX. We have to strip out some *s which is the reason for \* So we could have multiples room numbers calling in. For example 101, or 102, or 103. I just want to make it so that only the first invite is actually active.

Any ideas?

First, there are several syntax errors in your DialPlan rule so it seems the DialPlan rule is never executed.

Here is the modified DialPlan rule.
Matching Patterns:
$request = ^INVITE
$registered = ^false
To = sip:(6.+)@
From = sip:(1.+)\*(.+)\*(.+)@

Deploy patterns:
To = sip:%1@IP ADDRESS
From = sip:%3@IP ADDRESS

Second, let you check the Nurse Call's setting to disable the call duplication.

Thanks for the reply.

Sorry I failed to include the SIP in the deploy patterns. Our dial plan is fully functional as it is is what you posted a reply with.

Out Nurse call system does not have the capability to not send a duplicate call, which is why I was hoping tjat brekeke could filter those out for us.

Is the duplicated second call made while the first call is still ringing?

If so, add the DialPlan rule below above the current rule. This rule returns "486 Busy Here" if the caller is on another SIP Session.

Matching Patterns
$request = ^INVITE
To = sip:(6.+)@
$isTalking( From ) = ^true

Deploy Patterns
$response = 486

Thanks for the reply!

Yes the second (and potentially more depending on long the client let's it go for) is placed while the first is still ringing.

Will this rule apply to any dial plans with a lower priority after it?
In our case we have several dial plans but the only difference is that the number in the first bracket on the from in the matching pattern changes.

Also let's say the first number is 103, this rule will only block from 103 I assume? Let's say a call from 105 is made, this one should still come through correct?

> Will this rule apply to any dial plans with a lower priority after it?

Yes. but it only matches if "To = sip:(6.+)@" is fulfilled.


> Also let's say the first number is 103, this rule will only block from 103 I assume?

Yes.

> Let's say a call from 105 is made, this one should still come through correct?

Yes.


FYI:
https://docs.brekeke.com/sip/istalking

Yes all of my rules are matching on "To =sip (6.+)@ "
*The 6.+ is an extension in our PBX*

The only thing that changes is the first number in our "From sip: (#.+)

We have to have dial plans that match this specific number that redirects the from IP address in our Deploy patterns. This is make sure that call is connecting to the right controller. I am sure there is an easier way to do this using brackets, but one step at a time!

> The only thing that changes is the first number in our "From sip: (#.+)

Does From-URI have the '#' character?
Do you need to catch an INVITE which has such a From-URI?

No I was just using that character to indicate that it's a number value.

Basically each nurse call device acts as a SIP device, and each of those devices are connected to a Controller. That controller contains the IP address and is actually what sends out the INVITE. The sip device is an extension of that. I just built the rules the way I did because we needed to make sure that the PBX was connecting back to it's assigned controller.


On a separate note, should I be able to see in the logs when this new dial plan actually blocks the duplicate call? Since implementing this rule I am now seeing 486 errors, but its not showing under the new rule name.

Such rejected calls are listed under [Logs]->[Error Logs] page.

Thanks for helping me on this. The rule seems to be working, but I am seeing a different issue arise.

This rule is blocking calls that seem to come back to back with one another.

Our Nurse Call system sends an initial invite, and Brekeke strips the *s in dial plan I described earlier, and forwards it unto our PBX. %3 holds the "Caller ID" that displays on the phone. Within that caller ID holds what priority the call is. For example PATIENT

What happens in the Nurse call is designed to CANCEL the original invite and change the Caller ID and re-send a new invite after a period of time. With this new rule active, it is actually blocking that new call from coming in.

I can see with a wireshark capture that the following steps are happening
1) Invite sent from nurse call to Brekeke
2) Invite forwarded to PBX
3) Cancel sent from nurse call to Brekeke
4) Cancel forwarded to PBX
5) ACK (and a 487) Returned to Nurse Call
6) New Invite from nurse call to Brekeke
7) [/b]Brekeke returns a 486 error to nurse call

From what I can tell with Wireshark a cancel is being sent, but Brekeke is blocking the next call anyways. We only want to block the next call if there is a call currently ringing.

Does the nurse call change the Caller-ID in From: header?
I thought it changed Callee-ID in To: header.

Can you try the DialPlan rule below. I added "$isTalking(To)".
Matching Patterns
$request = ^INVITE
To = sip:(6.+)@
$isTalking(From) = ^true
$isTalking(To) = ^true

Deploy Patterns
$response = 486

I believe it does change it in the from header, but that is the only place it changes.

From:sip(area number) * (sip extension or room number) * (physical station)

When it sends an invite from a room the above digits don't change (unless a new call is initiated by a different station within the room) the caller ID header is always attached to the second digit or bracket 2.

I will try adding that to the rule and get back to you.

Mhmm.

Now it doesn't seem to be blocking any calls since adding the talking to rule

I see.If you have "$isTalking(From)" in that rule, any SIP INVITE which have same caller-ID (as From-URI) will be blocked.

If you have "$isTalking(To)" in that rule, any SIP INVITE which have same callee-ID (as To-URI) will be blocked.

I thought re-send INVITE has same From-URI and To-URI as the original INVITE so I put both $isTalking(From) and $isTalking(To) in the same rule.

If the nurse call changes Caller-ID as you said, what happens if you use only $isTalking(To) as the following?

[Matching Patterns]
$request = ^INVITE
To = sip:(6.+)@
$isTalking(To) = ^true

[Deploy Patterns]
$response = 486

When the nurse call sends the INVITE it sends it as a from-URI sip:11*2122*0@IPADDRESS (For example). The second invite still has a from-URI of sip:11*2122*0@SAMEIP. The To-URI doesn't change either (sip:6020@IPADDRESS for example) it just the SIP Message header that changes.

If I use the $istalkingto on its own it makes things even worse. It actually blocks all calls going to the same sip URI. We have many nurse call stations that ring the same group of phones.

I wonder if it would have anything to do with the way Brekeke is changing the from-URI, when it relays the invite to the PBX.

So as mentioned when an invite is sent, brekeke strips the *s out of the from-URI so only the middle bracket is sent to the PBX. So in my example it would be from sip:2122@IPADDRESS

It seems the original blocking rule like the following is better so far because the second INVITE has the same From-URI.

[Matching Patterns]
$request = ^INVITE
To = sip:(6.+)@
$isTalking( From ) = ^true

[Deploy Patterns]
$response = 486

But it also blocks the next valid call too because the SIP Server doesn't know they are new call or second INVITE...

The best solution is that the nurse call stops sending the second INVITE.
Otherwise... contact Brekeke support to discuss the issue.

Try this..

[Matching Patterns]
$request = ^INVITE
To = sip:(6.+)@
$isTalking( From ) = ^true

[Deploy Patterns]
$response = 486
&net.sip.timeout.bye = 1

Yes you are correct. Only the first rule blocks calls anyways. As soon as I try putting the $istalking (to) it doesn't block calls anymore.

The 2nd Invite is an escalation based on staff not answering the call. So it changes the priority and sends to a different group of phones. So this is needed unfortunately.

What is the sip timeout supposed to accomplish?

> So it changes the priority and sends to a different group of phones.

That's why $isTalking(To) doesn't work because To-URI will be differ.


> What is the sip timeout supposed to accomplish?

If you add "&net.sip.timeout.bye = 1" in the Deploy Patterns, the SIP Server closes the Ringing session immediately just after the nurse call sends CANCEL. so the next call will not be blocked.

Add "&net.sip.timeout.bye = 1" in the Deploy Patterns of the rule which forwards a call to PBX also.

If the nurse call send the second-INVITE before it sends CANCEL, the SIP Server blocks it because the session is still active.

Sorry it just changes the priority in the sip header. The same group of phones rings as far as the nurse call goes. Or the URI is the same. Our PBX sends the call to a different group of phones.

There are several escalations in our PBX, which is why I am trying to stop these "duplicate calls" from happening. Otherwise the PBX tries to escelate every call. Ideally I agree that the nurse call shouldn't do this, but I'm trying to find an intern solution until our nurse call provider can give us a solution. (this could take months)

I did add that rule, and it seems to work intermittently.

Have you put "&net.sip.timeout.bye = 1" in the rule which forwards a call o the PBX? Also the blocking rule must be listed above the forwarding rule.


Rule: Block the second INVITE
[Matching Patterns]
$request = ^INVITE
To = sip:(6.+)@
$isTalking(From) = ^true

[Deploy Patterns]
$response = 486
&net.sip.timeout.bye = 1


Rule: To PBX
[Matching Patterns]
$request = ^INVITE
$registered = ^false
To = sip:(6.+)@
From = sip:(1.+)\*(.+)\*(.+)@

[Deploy Patterns]
To = sip:%1@IP ADDRESS
From = sip:%3@IP ADDRESS
&net.sip.timeout.bye = 1

I didn't realize I had to put &net.sip.timeout.bye=1 in the PBX rules as well.

It seems like the rules are working! (Thanks a million by the way!) It is blocking the calls as it is designed, I just failed to realize something else. What is happening is it is also blocking calls that are supposed to be going to a whole different To:SIP address.

So for example if the nurse call is ringing a "normal" call it will be To=sip6001@IPADDRESS
If an "emergency" call is placed it is has a different To=sip:6005@IPADDRESS.

So with the current configuration it blocks the emergency call from ringing a different set of phones because the FROM:SIP address is the same on both. Or vise versa, if an emergency call is ringing the normal will not ring.

Is there a way we can setup a matching pattern for the To=Sip address without creating a separate rule for each? There isn't really a set digit we use for emergency calls, they all start with 6.

> I didn't realize I had to put &net.sip.timeout.bye=1 in the PBX rules as well.

It closes the canceled session immediately. so next call will not be blocked if the previous call was canceled.


> So for example if the nurse call is ringing a "normal" call it will be To=sip6001@IPADDRESS
> If an "emergency" call is placed it is has a different To=sip:6005@IPADDRESS.

It sounds like adding $isTalking(To) = ^true in Blocking rule solves the issue because the second INVITE has different To-URI.

If adding $isTalking(To) doesn't work, add one more DialPlan rule above to other two rules to pass only the emergency call.

Rule: To PBX Emergency
[Matching Patterns]
$request = ^INVITE
$registered = ^false
To = sip:(6005)@
From = sip:(1.+)\*(.+)\*(.+)@

[Deploy Patterns]
To = sip:%1@IP ADDRESS
From = sip:%3@IP ADDRESS
&net.sip.timeout.bye = 1

So after some more testing, it appears as things are not working correctly. The calls are in fact still being blocked, I thought it was just the different priorities that were coming from the same SIP:To address, but that is not the case. It is still blocking the 2nd call intermittently, even if the call is cancelled first. I find it weird that it sometimes works and other times not. I even added another option within the nurse call to cancel and resend a different invite a 3rd time and it also works intermittently.

I wish I could send you some wireshark logs to help out here, but I can't seem to attach anything on this forum.

Whenever I add the $istalking( To ) =^True rule, it doesn't block anything. Or I am not seeing after 3-4 days of testing that it showed a single error in the logs.

If your company has a support contract with Brekeke, contact support@brekeke.com to open a support ticket. We will look at Wireshark capture and Brekeke's log files to analyze the issue further.

Hi,

I have a newer (What I believe to be simpler) request.

Is it possible to have an active session automatically force cancel if a new call comes in using the exact same parameters?

This way the new call gets processed as an active session, instead of the new call sending back a 486 busy here?

What does "same parameters" mean?
Same SIP header value? same To-URI and/or same Request line?

Same SIP-To URI, and same From-URI,

It requires a custom plugin.
Let you discuss it with support@brekeke.com.