3CX and Brekeke SIP Server (BSS)

1. Brekeke Product Name and Version:
Brekeke SIP Server - 3.14.5.17/563.2

2. Java version:
11.0.15

3. OS type and the version:
Windows Server 2012

4. UA (phone), gateway or other hardware/software involved:
3CX IP PBX

5. Your problem:
3CX makes use of the rinstance parameter in the Contact field field when registering with a SIP server. I see that BSS is handling that, as I see the rinstance parameter being returned back to the 3CX server in the 200 OK message after sucessful registeration.

3CX also tries to use the rinstance parameter on inbound calls. My upstream service provider is IP authenticated, so they don't give me the rinstance parameter.

For inbound calls coming from my upstream provider, through BSS, to the 3CX server, is there a way to add the rinstance parameter with the correct value to inbound calls, to forward to the 3CX server?

How do you forward an incoming call from the upstream provider to the 3CX through the Brekeke SIP Server?

Does the caller at the upstream provider dial the 3CX's registered number at the Brekeke?
Or do you use any DialPlan rules for forwarding an incoming call to the 3CX?

Yes, I'm using DialPlan rules. All DID numbers are entered into BSS, using Aliases.

John

$regdb.URIparam("<UserName>") returns the registered URI parameters.
So to get the rinsance's value,
use $param($regdb.URIparam("<UserName>"),"rinsance")

The example below puts rinsance's value in the INVITE's To-header if the registered username is "9999".

[Matching Patterns]
$request = ^INVITE
$param($regdb.URIparam("9999"),"rinsance") = (.+)

[Deploy Patterns]
To/uri/param/rinstance = %1
$target = %{$regaddr("9999")}

Here are my DialPlans.

When a call comes in, it looks it up in the Alias list/database.

It if finds it there, then it does a 302 Move (forwards the call) to my STIR/SHAKEN service.

The call then comes back and forwards the call on to the proper 3CX system.

I've replaced the IP addresses of my upstream provider with 'x' to hide 'identities'. The IP address of my STIR/SHAKEN service is replaced with 'y'.

What I need to be able to do is to do what you're example shows, but I need to be able to do this with each registered UserName (I have many registered users on this system). I don't know of my STIR/SHAKEN service can handle the rinstance parameter, so it might be best to 'insert' it into the INVITE just before it's sent to the 3CX servers.

First Matching Plan:
===========================================
$request = ^INVITE
$addr = ^xxx.xxx.xxx.xxx$|^xxx.xxx.xxx.xxx$|^xxx.xxx.xxx.xxx$|xxx.xxx.xxx.xxx$|^xxx.xxx.xxx.xxx$|^xxx.xxx.xxx.xxx$|^xxx.xxx.xxx.xxx$
To = sip:(.+)@
$alias.lookup("%1") = (.+)/(.+)
$regAddr("%2") = (.+)
===========================================
First Deploy Plan:
===========================================
&inbound.to = sip:%1@%4
$rtp = %3
$auth = false
$continue = true
===========================================

Second Matching Plan:
===========================================
$request = ^INVITE
&inbound.to = (.+)
Identity = .+
To = sip:(.+)@
===========================================
Second Deploy Plan:
===========================================
$b2bua = true
To = sip:%2@yyy.yyy.yyy.yyy
$session = failover %1
&failover.timer.provisional = 120
&failover.redirection = false
===========================================

Third Matching Plan:
===========================================
$request = ^INVITE
&inbound.to = (.+)
===========================================
Third Deploy Plan:
===========================================
$b2bua = true
To = %1
===========================================

Does the STIR/SHAKEN service return "302 Move"?
Does this "302 Move" carry the call destination URI in Contact header?
Can you paste the "302 Move" packet here?

Yes, a 302 Moved Temporarily is returned.

Here's a SIP Message. I've removed the actual IP addresses.
The 'aaa.aaa.aaa.aaa' is the correct IP address of the 3CX server to which the call is being sent.

SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bKff331d26af050-270bc515-2fe321
To: <sip:14171234567@yyy.yyy.yyy.yyy>
From: "JOHN RAYFIELD" <sip:1417zzzzzzz;verstat=TN-Validation-Passed@xxx.xxx.xxx.xxx>;tag=b8f1e7adfs
Contact: <sip:14171234567@aaa.aaa.aaa.aaa>
Call-ID: f1b3e7a3-41c54ac7-c054ca3d-bd4677c2
CSeq: 1 INVITE
Reason: SIP;cause=302;text="no-fraud-detected"
Content-Length: 0

The first rule will be like this for inserting "rinsance".

==============
[Matching Patterns]
$request = ^INVITE
$addr = ^xxx.xxx.xxx.xxx$|^xxx.xxx.xxx.xxx$|^xxx.xxx.xxx.xxx$|xxx.xxx.xxx.xxx$|^xxx.xxx.xxx.xxx$|^xxx.xxx.xxx.xxx$|^xxx.xxx.xxx.xxx$
To = sip:(.+)@
$alias.lookup("%1") = (.+)/(.+)
$regAddr("%2") = (.+)
$param($regdb.URIparam("%2"),"rinsance") = (.+)

[Deploy Patterns]
&inbound.to = sip:%1@%4
$rtp = %3
$auth = false
To/uri/param/rinstance = %5
$continue = true
==============

That did not work.

Incoming calls were not forwarded to the STIR/SHAKEN service (yyy.yyy.yyy.yyy in my 2nd Deploy Pattern).

It appears that after this new 1st Dialplan, the Matching Pattern of the 2nd Dial Plan isn't being matched (if I'm understanding the DialPlan correctly).

John

Let you enable the DialPlan log to see why the second rule was not matched.

How do I enable Dial Plan logs?

It is [Diagnostics]->[Debug Logs] page -> "Dial Plan" category.

I found this in the logs:

Pattern: $param($regdb.URIparam("%2"),"rinsance") = (.+)
Input: $param($regdb.URIparam("rayfield001"),"rinsance") = null
Result: false

And this showed the typo that was causing the problem.

I corrected this typo and now the rinstance parameter is showing up in the To field:

However, that's not what I need. Here's what 3CX states:

"3CX tries first to find an “rinstance” parameter in the RURI SIP field in an INVITE to match against a SIP Trunk, only present in Register-based providers. If this exists, then 3CX checks if this “rinstance” value was used to register one of the configured SIP Trunks and if found, match it with that specific Trunk"

So, I need the rinstance parameter in the INVITE message that is sent to 3CX for an inbound call.

Here's an example from 3CX's website:

Request-Line: INVITE sip:DID@2.2.2.2:5060;rinstance=187128bdfcec4b74 SIP/2.0

So what would be the correct format of the line in the Deploy Patttern to add the rinstance to the INVITE?

Replace the Request URI with $request in Deploy Patterns.

https://docs.brekeke.com/sip/request-2

So here's what you gave me for the Deploy Pattern:

&inbound.to = sip:%1@%4
$rtp = %3
$auth = false
To/uri/param/rinstance = %5
$continue = true

I replaced the "To/uri/param/rinstance - %5" line with:

$request = INVITE sip:%1@%4;rinstance=%5

This appeared to work, except that the resulting INVITE sent to the 3CX server had two "sip:did-number@3CX-server-ipaddress;rinstance=bunch-of-characters"

So I'm getting a duplicate of the parameters in the INVITE. Why?

John
John

The definition will be like this.
$request= INVITE sip:%1@%4;rinstance=%5 SIP/2.0

You may need to insert $request= in the Deploy Patterns of Second and Third rules. so store the rinstance's value in a variable like what you did as &inbound.to.

Thank you Laurie.

I was pretty close with my last try. I forgot the "SIP/2.0".

I was going to ask you about using a variable to store the rinstance value - something like this in the 1st Deploy Pattern:

&inbound.rinstance = %5

Then I can use that in the 2nd Dial Plan Deploy Pattern, like this:

$request= INVITE sip:%1@%4;rinstance = &inbound.rinstance SIP/2.0

This should work, shouldn't it?

[quote="JRayfield"]Thank you Laurie.

I was pretty close with my last try. I forgot the "SIP/2.0".

So I have, in the 1st Deploy Pattern:

&inbound.to = sip:%1@%4
$rtp = %3
$auth = false
$request = INVITE sip:%1@%4;rinstance=%5 SIP/2.0
$continue = true

This seems to work. Here's the INVITE as it's sent to the 3CX server:

INVITE sip:DID-Number@3CX-Server-IP:5060;rinstance=b3839ecac2dc397c SIP/2.0

In comparing the rinstance value in the 3CX REGISTRATION messages, with the rinstance value that is added to the INVITE messages sent to the 3CX server, they match.

So it looks like this is all working. I did not have to add the new $reqest line into the 2nd or 3rd Dial Plans. I also did not make use of a variable for the rinstance value.