I have not contacted Grandstream, as it is not really a Grandstream issue The issue is our sending device, which the manufacturer refuses to change the way they are doing things. It would take a "re-engineering" of their hardware. We were looking for perhaps a way around this through Brekeke, so ...

We can't really use Brekeke PBX, because of the way that the facility needs to work through it's own PBX. I am more than happy to go through Brekeke's technical support, and pay them to develop a plugin or rule that would do this for us. However I'm hoping that we can determine if this is even ...

1. Brekeke Product Name and Version:SIP Server 3.10.6.5 2. Java version:8 3. OS type and the version:Windows Server 2016 4. UA (phone), gateway or other hardware/software involved:Grandstream PBX 5. Your problem: Hi All, I am wondering if it would be possible to set up a rule where I could cancel ...

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

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?

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 ...

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 ...

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 ...

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 ...

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 ...

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 ...

Mhmm.

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

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 ...

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 ...

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 ...

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 ...

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 ...

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 ...

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 ...