Brekeke Forum Index » Brekeke SIP Server Forum

Post new topic   Reply to topic
Replace REFER-TO
Author Message
wfx
Brekeke Member


Joined: 28 Aug 2017
Posts: 14
Location: USA

PostPosted: Mon Aug 28, 2017 1:15 pm    Post subject: Replace REFER-TO Reply with quote

1. Brekeke Product Name and Version: PBX/Sip Server Advanced 3.7.7.3/477

2. Java version: 1.8.0_144

3. OS type and the version: Windows Server 2012

4. UA (phone), gateway or other hardware/software involved: SIP application, ITSP

5. Your problem:

My SIP application issues a REFER to transfer a call and BSS sends it to my ITSP OK, but the REFER-TO uri is the BSS external IP address and I need it to be the ITSP's IP address. I would like to replace the IP address of the REFER-TO field.

Example:
Code:
Old REFER-TO - sip:1234567@10.10.10.10
New REFER-TO - sip:1234567@99.99.99.99


Per this post http://www.brekeke-sip.com/bbs/viewtopic.php?t=7458 I have added the following to my advanced configuration:

Code:
&net.sip.outside.dialog.pattern = ^REFER|^NOTIFY


I have also created the following dial plan rule at priority 1 from this post http://www.brekeke-sip.com/bbs/viewtopic.php?t=2951:

Matching Patterns
Code:
$request = ^REFER
Deploy Patterns
Code:
Refer-To = sip:1234567@99.99.99.99

The rule does not appear to be executing as I see no change in the REFER-TO of requests as they cross the BSS. Any ideas on a dial plan rule to make this change to the REFER-TO?
Thanks,
wfx






[/code]
Back to top
View user's profile
snuyzm
Brekeke Talented


Joined: 11 Feb 2015
Posts: 97

PostPosted: Mon Aug 28, 2017 2:12 pm    Post subject: Reply with quote

> Per this post http://www.brekeke-sip.com/bbs/viewtopic.php?t=7458 I > have added the following to my advanced configuration:
>
>&net.sip.outside.dialog.pattern = ^REFER|^NOTIFY

You don't need "&" in the front of the variable name if you put it at [Configuration]->[Advanced] page.

So it will be
Code:
net.sip.outside.dialog.pattern = ^REFER|^NOTIFY



At the DialPlan rule for catching REFER, you might need to add "To=" with the ITSP' IP address.


For example,
Matching Patterns
$request = ^REFER
To = sip:(.+)@
Deploy Patterns
To = sip:%1@99.99.99.99
Refer-To = sip:1234567@99.99.99.99
Back to top
View user's profile
wfx
Brekeke Member


Joined: 28 Aug 2017
Posts: 14
Location: USA

PostPosted: Mon Aug 28, 2017 3:37 pm    Post subject: Reply with quote

snuyzm,

I actually figured out the leading "&" in the advanced config was the issue for the rules not executing by cross referencing some other examples of Advanced configurations. I was coming back to post this with an update when I saw your post. Thank you though for the quick reply and solution.

Now, on to my next issue with the REFER-TO rule... I am still using:

Matching Patterns
$request = ^REFER

Deploy Patterns
Refer-To = sip:1234567@99.99.99.99

The rule is executing now, but when it does the BSS replies with a SIP 404 Not Found and ends the call. I see an entry in the error log with the REFER method code 404 with a Reason of "Session is not created" with the name of the REFER rewrite rule.

It seems to me that when the rule gets matched the BSS is trying to start a new session/dialog for it when all I really want to do is just overwrite the existing value when it crosses the BSS.

Anyone have any thoughts?
wfx
Back to top
View user's profile
snuyzm
Brekeke Talented


Joined: 11 Feb 2015
Posts: 97

PostPosted: Tue Aug 29, 2017 10:12 am    Post subject: Reply with quote

Do you have "To=" definition in the Deploy Pattern like the following?

Deploy Patterns
To = sip:%1@99.99.99.99
Refer-To = sip:1234567@99.99.99.99

Without "To=", Brekeke SIP Server doesn't know the destination.
Back to top
View user's profile
wfx
Brekeke Member


Joined: 28 Aug 2017
Posts: 14
Location: USA

PostPosted: Tue Aug 29, 2017 12:27 pm    Post subject: Reply with quote

snuyzm,
Yesterday I had tried this, to force the message to a destination:

Deploy Patterns
$target = 99.99.99.99

When doing this the ITSP get's the REFER, but denies it most likely since it's not in an active dialog. In Wireshark I can see the ITSP respond to the REFER with a 403, but the BSS does not send that back to the SIP App server, instead it tries to resend the REFER to the ITSP 12 times before quitting. In the meantime the SIP App server still has an open dialog with the calling phone and since it receives no response from the REFER it eventually times out and sends a BYE to the phone and ends the dialog.

Based on your recent comment I removed the $target and just went with your suggestion:

Deploy Patterns
To = sip:1234567@99.99.99.99
Refer-To = sip:1234567@99.99.99.99

The good news the BSS does not issue a 404 error, but unfortunately the result is the same as the deploy rule above where I specify the &Target. The message is forwarded on to the ITSP, but it is now out of the original dialog...

wfx
Back to top
View user's profile
snuyzm
Brekeke Talented


Joined: 11 Feb 2015
Posts: 97

PostPosted: Tue Aug 29, 2017 4:12 pm    Post subject: Reply with quote

What does "out of the original dialog" mean?
Are they using different Call-ID?

If so disable [B2B-UA mode] at [Configuration]->[SIP] page
If you have "$b2bua=true" in the rule for INVITE, remove it.
Back to top
View user's profile
wfx
Brekeke Member


Joined: 28 Aug 2017
Posts: 14
Location: USA

PostPosted: Tue Aug 29, 2017 5:33 pm    Post subject: Reply with quote

snuyzm,
I don't have B2B-UA enabled in config or in the dial plan rule. Even tried enabling it to see if it made a difference but no luck.

By out of the dialog I mean out of the current session/call/conversation etc...

My basic call flow is like this:

ITSP->PBX/BSS->App/IVR

I have dial plan rule for the INVITE for the initial inbound call from the ITSP that forwards it to the App/IVR, which works fine. I believe once the INVITE rule is matched the BSS creates a dialog/session and routes the messages back and forth for the duration of the session/call - works great. My issue occurs if a caller chooses to transfer out of the App/IVR then it produces a REFER and sends it to the PBX who sends it to the ITSP like this:

App/IVR->PBX/BSS->ITSP

This all works fine except when the ITSP receives my REFER to the PSTN it has the external IP address of the BSS in the uri of the REFER-TO field, which my ITSP does not expect and issues a 401. The ITSP would expect to see the REFER-TO with their IP, signaling them to transfer the call to the other number on their network ie. the PSTN. So now I need to replace the IP of the REFER-TO sent to the ITSP.

No dial plan rules will match on messages inside of an existing dialog/session so we must configure BSS to allow this via the "net.sip.outside.dialog.pattern = ^REFER" setting. Once enabled we can now catch the REFER inside the dialog/session, but when we do it seems to create a new session. So my signaling now looks like this:

(dots just for spacing)
App/IVR->PBX/BSS->ITSP (original dialog/session)
....................|
..............PBX/BSS->ITSP (new dialog session for REFER)

Once the dial plan rule processes the REFER inside of the original dialog/session the new REFER signaling is disconnected from the session. The ITSP doesn't know what to do with the REFER out of session so it responds with a 403 Forbidden, but since it is no longer tied to the original session the BSS doesn't send it back to the App/IVR and instead sends it back to the ITSP, who responds with a 403... It does this 12 times:

PBX/BSS->ITSP (REFER)
PBX/BSS<-ITSP (403)
... 11 more times

Meanwhile, the original dialog/session is still up and waiting for the response from the REFER which never comes, so the App/IVR times out and sends a BYE:

App/IVR->PBX/BSS->ITSP (BYE)

This ends the original dialog/session and the call is torn down.

Frustrating...
wfx
Back to top
View user's profile
snuyzm
Brekeke Talented


Joined: 11 Feb 2015
Posts: 97

PostPosted: Wed Aug 30, 2017 10:37 am    Post subject: Reply with quote

There are several doubts.

Does your DialPlan rule for INVITE pass INVITE to the PBX?
or does the rule pass INVITE to the ITSP directly?

If the rule passes INVITE to the PBX, the PBX handles REFER and a makes a transfer without sending REFER to the ITSP.

If you look at the session log at [Logs]->[Session Logs] page, does the [Rule Name] field indicate "To PBX"? If so, INVITE was passed to the PBX. If not, INVITE was sent to the ITSP directly without PBX.

Are you sure that the ITSP support SIP-REFER?
Some ITSP don't support it.



> my ITSP does not expect and issues a 401.

Is it 401? or 404?
In your previous post, you said 404.
Back to top
View user's profile
wfx
Brekeke Member


Joined: 28 Aug 2017
Posts: 14
Location: USA

PostPosted: Wed Aug 30, 2017 12:12 pm    Post subject: Reply with quote

snuyzm,

The INVITE comes from the ITSP. Remember my call flow is like this with calls originating on the PSTN going into the IVR and then being transferred to another location on the PSTN:

PSTN(#A)->ITSP->PBX/BSS->IVR
........................................[REFER]
PSTN(#B)<-ITSP<-PBX/BSS<-IVR

My INVITE rule matches on the IP from the ITSP and forwards the request to the IVR with no $Continue. The session logs list my rule under "Rule Name" there are no "To PBX" entries. Also, there are no entries in the logs with my REFER rule name, only the INVITE rule is in the session log.

On the error from the ITSP, I get 2 depending on whether the REFER rule is in or not.

Only INVITE rule, No REFER rule:
ITSP responds with 401 Unauthorized.
- According to the ITSP they support transfer/REFER
- I have a ticket open with the ITSP at the moment to verify the signaling and their 401 response.

Both INVITE and REFER rule in Dial Plan:
ITSP responds with 403 Forbidden

wfx
Back to top
View user's profile
snuyzm
Brekeke Talented


Joined: 11 Feb 2015
Posts: 97

PostPosted: Wed Aug 30, 2017 1:04 pm    Post subject: Reply with quote

Do you have any reason to use Brekeke PBX? This is because a call is not passed through the PBX.

> ITSP responds with 401 Unauthorized.

Does the IVR support an authentication for REFER?
If so, the IVR will resend REFER with auh credential after it receives 401.
Back to top
View user's profile
wfx
Brekeke Member


Joined: 28 Aug 2017
Posts: 14
Location: USA

PostPosted: Wed Aug 30, 2017 1:18 pm    Post subject: Reply with quote

I use PBX for ARS to authenticate and connect to the ITSP.

The IVR signaling cannot be changed.

I find it hard to believe the PBX/BSS cannot support replacing the REFER-TO address. Without this feature I don't know how you could proxy a transfer at all.

I currently operate this App/IVR on other projects with physical SIP proxy appliances that have a specific setting called "REFER-TO Replacement Domain" to handle this exact situation. When enabled this replaces whatever IP address is in the REFEER-TO with the one specified.

Very frustrated with BSS... but I do appreciate your help.
wfx
Back to top
View user's profile
snuyzm
Brekeke Talented


Joined: 11 Feb 2015
Posts: 97

PostPosted: Wed Aug 30, 2017 3:26 pm    Post subject: Reply with quote

Are you using ARS for the INVITE you have the issue with REFER?

According to your previous posts, it seems you are not using ARS for this ITSP because "To PBX" rule is not used. Is it correct?


If you have Technical support contract with Brekeke, I recommend that you contact Brekeke's support team because you will not post your actual DialPlan rules and logs on the forum.
Back to top
View user's profile
snuyzm
Brekeke Talented


Joined: 11 Feb 2015
Posts: 97

PostPosted: Wed Aug 30, 2017 3:47 pm    Post subject: Reply with quote

Which IP address is specified in Refer-To originally sent from the IVR?

Is it the IVR's IP address? or SIP Server's IP address?
Back to top
View user's profile
wfx
Brekeke Member


Joined: 28 Aug 2017
Posts: 14
Location: USA

PostPosted: Wed Aug 30, 2017 4:17 pm    Post subject: Reply with quote

The original packet from the IVR has the PBX/BSS IP in it's REFER-TO, but when the PBX/BSS forwards it to the ITSP it changes the REFER-TO to it's own external NAT address. Detail:

Address reference:
10.10.10.10 = Interface IP of PBX/BSS
44.44.44.44 = External IP of PBX/BSS (Config/Network/Inteface Address 1)
99.99.99.99 = ITSP IP Address

Incoming REFER message received by PBX/BSS from IVR:
Code:
REFER-TO:<sip:1234567@10.10.10.10:5060;user=phone>

- IVR is refering the call to the PBX/BSS - OK

Outgoing REFER message sent to ITSP:
Code:
REFER-TO:<sip:1234567@44.44.44.44:5060;user=phone>

- PBX/BSS is refering the call to it's own external NAT IP - BAD

What I want to make the REFER sent to ITSP look like:
Code:
REFER-TO:<sip:1234567@99.99.99.99:5060;user=phone>

- PBX/BSS is referring the call to the ITSP

wfx
Back to top
View user's profile
snuyzm
Brekeke Talented


Joined: 11 Feb 2015
Posts: 97

PostPosted: Wed Aug 30, 2017 4:43 pm    Post subject: Reply with quote

I got it.

Let you pass an INVITE to the PBX.
So the PBX will handle both INVITE and REFER.

In this scenario, INVITE will be forward to the ITSP based on the ARS.
and REFER is handled by the PBX automatically on behalf of the ITSP.
If Refer-to indicates a PSTN number, the PBX forwards new call through the ITSP.

If you try this, you need to remove "net.sip.outside.dialog.pattern" from [Configuration]->[Advanced] page.
Back to top
View user's profile
wfx
Brekeke Member


Joined: 28 Aug 2017
Posts: 14
Location: USA

PostPosted: Wed Aug 30, 2017 7:08 pm    Post subject: Reply with quote

I see what you are thinking and it might work, but I ran into issue trying to configure this. I need the INVITE from the ITSP to go to my external App/IVR, but in the ARS "Patterns-In' route from the ITSP I cannot specify a SIP uri/IP address to forward the call to, only extensions, I think this is for security reasons right?

I have read other posts that say to configure an extension and then have that forward to the IP/uri, but I don't see where to configure it. If I enter a sip: uri into the the "Other Forwarding Destinations" field it just removes it.

Any thoughts on how to forward from ARS "Patterns-In" route to an IP address or sip: uri?

wfx
Back to top
View user's profile
wfx
Brekeke Member


Joined: 28 Aug 2017
Posts: 14
Location: USA

PostPosted: Wed Aug 30, 2017 7:21 pm    Post subject: Reply with quote

Never mind, got that figured out, created new ARS route to route calls to the SIP/IVR server that match inbound DID from PSTN.

Still working on it...

wfx
Back to top
View user's profile
wfx
Brekeke Member


Joined: 28 Aug 2017
Posts: 14
Location: USA

PostPosted: Wed Aug 30, 2017 9:48 pm    Post subject: Reply with quote

So I changed the configuration to move the call via the ARS routes and now when the REFER comes from the IVR to the PBX/BSS it responds with a 403 Forbidden. I assume this is because the REFER is requesting a transfer to a number outside of the PBX and the IVR server is not registered as an extension/user etc...

I tried adding a dial plan rule in the the BSS to set $auth = false for traffic from the IVR, but that did not work.

I feel we are getting closer, any thoughts?
wfx
Back to top
View user's profile
wfx
Brekeke Member


Joined: 28 Aug 2017
Posts: 14
Location: USA

PostPosted: Thu Aug 31, 2017 8:15 am    Post subject: Reply with quote

FYI - Here is a section from the log where the PBX/BSS receives the REFER and then responds with the 403.

Address reference:
10.20.20.20 = Interface IP of APP/IVR
10.10.10.10 = Interface IP of PBX/BSS
99.99.99.99 = ITSP IP Address

1111111111 = Original DID of caller
2222222222 = New DID to transfer to

Code:

==============================================

session.14: stat: result=undefined(6)  close=false
>  +--------------+--------------+--------------+--------------+
>  |              |              |              |              |
>  +--------------+--------------+--------------+--------------+
>              0/1            0/0            0/1            0/0         

tcp-con.2: debug: receive: from=10.20.20.20:58491 at 08/31/17 01:07:40.199
==============================================
REFER sip:1111111111@10.10.10.10:5060;transport=tcp SIP/2.0
FROM: <sip:8888@10.20.20.20;transport=TCP>;epid=21A78EE715;tag=aeb3ff8aa1
TO: <sip:1111111111@99.99.99.99>;tag=bfbefa845s
CSEQ: 1 REFER
CALL-ID: ed1c6c5f-7900bb5d-cdee509c-165a0289
MAX-FORWARDS: 70
VIA: SIP/2.0/TCP 10.20.20.20:58491;branch=z9hG4bK207bf5d7
CONTACT: <sip:APPIVR:58491;transport=Tcp;maddr=10.20.20.20;ms-opaque=a6406a573aa1d4bd>;automata
REFER-TO: <sip:2222222222@10.10.10.10:5060;transport=tcp;user=phone>
REFERRED-BY: <sip:8888@10.20.20.20;transport=TCP>
USER-AGENT: RTCC/3.0.0.0
Content-Length: 0


==============================================

session.14: receive: from=UAS:10.20.20.20:58491(TCP/tcp-con.2: ) at 08/31/17 01:07:40.199
==============================================
REFER sip:1111111111@10.10.10.10:5060;transport=tcp SIP/2.0
FROM: <sip:8888@10.20.20.20;transport=TCP>;epid=21A78EE715;tag=aeb3ff8aa1
TO: <sip:1111111111@99.99.99.99>;tag=bfbefa845s
CSEQ: 1 REFER
CALL-ID: ed1c6c5f-7900bb5d-cdee509c-165a0289
MAX-FORWARDS: 70
VIA: SIP/2.0/TCP 10.20.20.20:58491;branch=z9hG4bK207bf5d7
CONTACT: <sip:APPIVR:58491;transport=Tcp;maddr=10.20.20.20;ms-opaque=a6406a573aa1d4bd>;automata
REFER-TO: <sip:2222222222@10.10.10.10:5060;transport=tcp;user=phone>
REFERRED-BY: <sip:8888@10.20.20.20;transport=TCP>
USER-AGENT: RTCC/3.0.0.0
Content-Length: 0


==============================================

session.14: pkt#=9 dp=3 st=0 sip:8888@10.20.20.20:58491(10.20.20.20:58491) --> sip:1111111111@99.99.99.99(127.0.0.1:5054)
    send="REFER sip:1111111111@127.0.0.1:5054 SIP/2.0"

session.14: processtime=3

session.14: send: to=UAC:127.0.0.1:5054(UDP) at 08/31/17 01:07:40.201
==============================================
REFER sip:1111111111@127.0.0.1:5054 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bKa703c75e9032-87c8fd79-2cec7a
FROM: <sip:8888@10.20.20.20;transport=tcp>;epid=21A78EE715;tag=b70fdb3ccs
TO: <sip:1111111111@99.99.99.99>;tag=b27a75cf7p
CSEQ: 1 REFER
CALL-ID: a030367b-a12db9f7-326bc588-43fd0076
MAX-FORWARDS: 69
CONTACT: <sip:127.0.0.1:5060;ms-opaque=a6406a573aa1d4bd>;automata
REFER-TO: <sip:2222222222@127.0.0.1:5060;transport=tcp;user=phone>
REFERRED-BY: <sip:8888@10.20.20.20;transport=TCP>
USER-AGENT: RTCC/3.0.0.0
Content-Length: 0


==============================================

session.14: stat: result=undefined(6)  close=false
>  +--------------+--------------+--------------+--------------+
>  |              | 1 REFER      |              | 1 REFER      |
>  +--------------+--------------+--------------+--------------+
>              0/1            1/1            0/1            1/1         
>  ResendStat: REFER(1),

svlistener: debug: remote=127.0.0.1:5054 at 08/31/17 01:07:40.202
==============================================
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bKa703c75e9032-87c8fd79-2cec7a
From: <sip:8888@10.20.20.20;transport=tcp>;epid=21A78EE715;tag=b70fdb3ccs
To: <sip:1111111111@99.99.99.99>;tag=b27a75cf7p
Call-ID: a030367b-a12db9f7-326bc588-43fd0076
CSeq: 1 REFER
Content-Length: 0


==============================================
session.14: receive: from=UAC:127.0.0.1:5054(UDP) at 08/31/17 01:07:40.203
==============================================
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bKa703c75e9032-87c8fd79-2cec7a
From: <sip:8888@10.20.20.20;transport=tcp>;epid=21A78EE715;tag=b70fdb3ccs
To: <sip:1111111111@99.99.99.99>;tag=b27a75cf7p
Call-ID: a030367b-a12db9f7-326bc588-43fd0076
CSeq: 1 REFER
Content-Length: 0


==============================================

session.14: pkt#=10 dp=4 st=0 sip:1111111111@99.99.99.99(127.0.0.1:5054) --> sip:8888@10.20.20.20:58491(10.20.20.20:58491)
    send="SIP/2.0 403 Forbidden"

session.14: processtime=1

session.14: send: to=UAS:10.20.20.20:58491(TCP/tcp-con.2: ) at 08/31/17 01:07:40.203
==============================================
SIP/2.0 403 Forbidden
Via: SIP/2.0/TCP 10.20.20.20:58491;branch=z9hG4bK207bf5d7
From: <sip:8888@10.20.20.20;transport=TCP>;epid=21A78EE715;tag=aeb3ff8aa1
To: <sip:1111111111@99.99.99.99>;tag=bfbefa845s
Call-ID: ed1c6c5f-7900bb5d-cdee509c-165a0289
CSeq: 1 REFER
Content-Length: 0


==============================================

tcp-con.2: debug: send: to=10.20.20.20:58491 at 08/31/17 01:07:40.203
==============================================
SIP/2.0 403 Forbidden
Via: SIP/2.0/TCP 10.20.20.20:58491;branch=z9hG4bK207bf5d7
From: <sip:8888@10.20.20.20;transport=TCP>;epid=21A78EE715;tag=aeb3ff8aa1
To: <sip:1111111111@99.99.99.99>;tag=bfbefa845s
Call-ID: ed1c6c5f-7900bb5d-cdee509c-165a0289
CSeq: 1 REFER
Content-Length: 0

wfx
Back to top
View user's profile
llucy
Brekeke Talented


Joined: 31 Jan 2014
Posts: 52

PostPosted: Thu Aug 31, 2017 10:13 am    Post subject: Reply with quote

wfx,

Is the UA's number registered as a Phone ID of one of the PBX users?
In the default behavior, PBX does not accept REFER request from a non-PBX user.

If not, can you set it as a PBX user or otherwise add a property from the PBX > Options > Advanced page like below,

com.brekeke.pbx.Setting.ALLOW_REFER=true

If it was already a PBX user, please get the debug logs and backup file from the admintool and send to support@brekeke.com


Lucy
Back to top
View user's profile
wfx
Brekeke Member


Joined: 28 Aug 2017
Posts: 14
Location: USA

PostPosted: Thu Aug 31, 2017 10:54 am    Post subject: Reply with quote

Lucy,
Thank you for your help! The IVR is not registered as an extension, per your suggestion I added the following to my configuration>Advanced and restarted the PBX, but no change:

Code:
com.brekeke.pbx.Setting.ALLOW_REFER=true


I am still receiving 403 Forbidden, are you sure the syntax is correct?

I would add the IVR server as an extension, but have been unable to determine how to do that since the IVR server has no capability to register with the PBX as a UA, it just receives SIP requests and processes them.

Any thoughts?
wfx
Back to top
View user's profile
llucy
Brekeke Talented


Joined: 31 Jan 2014
Posts: 52

PostPosted: Fri Sep 01, 2017 12:04 pm    Post subject: Reply with quote

wfx,

Please get the debug logs and send to support@brekeke.com mentioning you are told to do so here.

http://wiki.brekeke.com/wiki/How-to-get-debug-logs


Lucy,
Back to top
View user's profile
wfx
Brekeke Member


Joined: 28 Aug 2017
Posts: 14
Location: USA

PostPosted: Fri Sep 01, 2017 12:32 pm    Post subject: Reply with quote

Lucy,
I have sent the logs to support.

Thanks,
wfx
Back to top
View user's profile
wfx
Brekeke Member


Joined: 28 Aug 2017
Posts: 14
Location: USA

PostPosted: Fri Sep 01, 2017 3:16 pm    Post subject: Reply with quote

Lucy,
Thank you! After communicating with support I realized I had put the setting you suggested in the wrong location in Brekeke. I added the setting in the Advanced configuration in the Sip Server instead of the PBX.

Based on the feedback from support I moved the setting to the correct location at:
PBX > Options > Advanced
Code:
com.brekeke.pbx.Setting.ALLOW_REFER=true


After restarting the PBX I no longer get the 403 Forbidden, but the PBX does not forward the REFER to the ITSP. Instead it seems like the PBX tries to act on the REFER. This is the messaging that now happens:

ITSP->PBX->IVR (INVITE, call up ok, etc...)
IVR->PBX (REFER / REFER-TO:<sip:1234567@10.10.10.10:5060;user=phone>)
PBX->IVR (202 Accepted)
PBX->IVR (NOTIFY)
IVR->PBX (200 OK)
PBX->IVR (NOTIFY)
IVR->PBX (200 OK)
PBX->IVR (BYE)
IVR->PBX (200 OK)
PBX->ITSP (BYE)
ITSP->PBX (200 OK)

Anyone have any thoughts?
wfx
Back to top
View user's profile
Haddas
Brekeke Guru


Joined: 17 Jan 2008
Posts: 170

PostPosted: Tue Sep 05, 2017 3:12 pm    Post subject: Reply with quote

Do you have an ARS route which can route a call to the specified phone number? In your example, it is 1234567.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    Brekeke Forum Index » Brekeke SIP Server Forum All times are GMT - 7 Hours
Page 1 of 1