Replace REFER-TO

wfx · Post by **wfx** » Mon Aug 28, 2017 1:15 pm

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: Select all

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: Select all

&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: Select all

$request = ^REFER

Deploy Patterns:

Code: Select all

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]

snuyzm · Post by **snuyzm** » Mon Aug 28, 2017 2:12 pm

> 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: Select all

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

wfx · Post by **wfx** » Mon Aug 28, 2017 3:37 pm

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

snuyzm · Post by **snuyzm** » Tue Aug 29, 2017 10:12 am

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.

wfx · Post by **wfx** » Tue Aug 29, 2017 12:27 pm

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

snuyzm · Post by **snuyzm** » Tue Aug 29, 2017 4:12 pm

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.

wfx · Post by **wfx** » Tue Aug 29, 2017 5:33 pm

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

snuyzm · Post by **snuyzm** » Wed Aug 30, 2017 10:37 am

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.

wfx · Post by **wfx** » Wed Aug 30, 2017 12:12 pm

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

snuyzm · Post by **snuyzm** » Wed Aug 30, 2017 1:04 pm

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.

wfx · Post by **wfx** » Wed Aug 30, 2017 1:18 pm

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

snuyzm · Post by **snuyzm** » Wed Aug 30, 2017 3:26 pm

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.

snuyzm · Post by **snuyzm** » Wed Aug 30, 2017 3:47 pm

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?

wfx · Post by **wfx** » Wed Aug 30, 2017 4:17 pm

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: Select all

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: Select all

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: Select all

REFER-TO:<sip:1234567@99.99.99.99:5060;user=phone>

- PBX/BSS is referring the call to the ITSP

wfx

snuyzm · Post by **snuyzm** » Wed Aug 30, 2017 4:43 pm

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.

wfx · Post by **wfx** » Wed Aug 30, 2017 7:08 pm

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

wfx · Post by **wfx** » Wed Aug 30, 2017 7:21 pm

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

wfx · Post by **wfx** » Wed Aug 30, 2017 9:48 pm

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

wfx · Post by **wfx** » Thu Aug 31, 2017 8:15 am

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: Select all

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

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

llucy · Post by **llucy** » Thu Aug 31, 2017 10:13 am

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

wfx · Post by **wfx** » Thu Aug 31, 2017 10:54 am

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: Select all

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

llucy · Post by **llucy** » Fri Sep 01, 2017 12:04 pm

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,

wfx · Post by **wfx** » Fri Sep 01, 2017 12:32 pm

Lucy,
I have sent the logs to support.

Thanks,
wfx

wfx · Post by **wfx** » Fri Sep 01, 2017 3:16 pm

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: Select all

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

Haddas · Post by **Haddas** » Tue Sep 05, 2017 3:12 pm

Do you have an ARS route which can route a call to the specified phone number? In your example, it is 1234567.