REFER failing with 403 Forbidden.

1. Brekeke Product Name and version: Brekeke PBX and SIP server, Version 2.2.6.2 , Pro Evaluation.


2. Java version: 1.6.0_11

3. OS type and the version: Windows XP

4. UA (phone), gateway or other hardware/software involved: X-Lite and Linksys SPA942

5. Select your network pattern from http://www.brekeke-sip.com/bbs/network/ ... terns.html : pattern 1

6. Your problem:

My problem is fairly simple but is rather difficult to explain. I have noticed while re-reading my other thread that I have missed out some detail and I think that it would be better to start over.

I am developing a VoIP VMS and I am using Brekeke PBX and SIP Server.

If I dial into my VMS and do not pick an option from the first menu the VMS then blind transfer you to a predetermined operator extension after a given time out. This uses SIP REFER and work perfectly.

However in the real world it is more likely that a user will dial an extension, get no answer and then be transferred to the VMS. In this case if the uses does not pick an option from the front end menu then they are transferred to the operator extension after a given time out.

Each user in the PBX is set to divert to 73nnnn after a number of rings. I have set up a dialplan in the SIP server that catches INVITEs to a 73 prefix number and adds the Diversion information to the INVITE message when the PBX diverts my caller to the VMS on no answer.

The dial plan is shown below.

Matching Pattern

$port=15062
$localhost=true
$registered=false
$outbound=false
$request=^INVITE
$getUri(From)=!_ocs
To=sip:73(.{4})

Deploy Pattern

$transport=udp
$auth=false
&net.sip.transport.follow.request=true
To=sip:4000@10.1.0.159;tag=%1
Diversion=<tel:%1>;reason=user-busy;screen=no;privacy=off
$replaceurl=true

The 4000:10.1.0159 in the dial plan is my VMS.

The problem is that when the VMS does the REFER to the operator extension I get a 403 Forbidden response.

Below is the REFER and the 403 response.

REFER sip:4069@10.1.0.159:5060 SIP/2.0
From: <sip:4000@10.1.0.159:5060>;tag=67b0158-7900010a-1b76-50022-2329-480af89a-2329
To: "4069"<sip:4069@10.1.0.159>;tag=b796a36a1p
Call-ID: f1f31025-f604458-3e2662dd-7d02d64f@10.1.0.159
CSeq: 1 REFER
Via: SIP/2.0/UDP 10.1.0.121:7030;branch=z9hG4bK-233b-89a04c-74087c4a
Refer-To: <sip:1001@10.1.0.159>
Referred-By: <sip:10.1.0.121:7030>
Max-Forwards: 70
Supported: replaces
Route: <sip:10.1.0.159:5060;lr>
Contact: <sip:10.1.0.121:7030>
Allow: INVITE, CANCEL, ACK, BYE, OPTIONS, REFER, NOTIFY
Allow-Events: refer
Content-Length: 0


SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 10.1.0.121:7030;branch=z9hG4bK-233b-89a04c-74087c4a
From: <sip:4000@10.1.0.159:5060>;tag=67b0158-7900010a-1b76-50022-2329-480af89a-2329
To: "4069"<sip:4069@10.1.0.159>;tag=b796a36a1p
Call-ID: f1f31025-f604458-3e2662dd-7d02d64f@10.1.0.159
CSeq: 1 REFER
Content-Length: 0


It seems that the dial plan maybe causing the problem. Calling the VMS directly and waiting for the time out transfer to the operator extension works perfectly.

The REFER and 202 Accepted packets are shown below.

REFER sip:4031@10.1.0.159:5060 SIP/2.0
From: "4000"<sip:4000@10.1.0.159>;tag=67b2550-7900010a-1b76-50022-2997f-5d3797c9-2997f
To: "4031"<sip:4031@10.1.0.159:5060>;tag=bbd7fe4f7p
Call-ID: 3608be7b-7be1932e-19db9c47-e9842525@10.1.0.159
CSeq: 1 REFER
Via: SIP/2.0/UDP 10.1.0.121:7030;branch=z9hG4bK-29992-a27e5bb-4dfea27d
Refer-To: <sip:1001@10.1.0.159>
Referred-By: <sip:10.1.0.121:7030>
Max-Forwards: 70
Supported: replaces
Route: <sip:10.1.0.159:5060;lr>
Contact: <sip:10.1.0.121:7030>
Allow: INVITE, CANCEL, ACK, BYE, OPTIONS, REFER, NOTIFY
Allow-Events: refer
Content-Length: 0


SIP/2.0 202 Accepted
Via: SIP/2.0/UDP 10.1.0.121:7030;branch=z9hG4bK-29992-a27e5bb-4dfea27d
Record-Route: <sip:10.1.0.159:5060;lr>
From: "4000"<sip:4000@10.1.0.159>;tag=67b2550-7900010a-1b76-50022-2997f-5d3797c9-2997f
To: "4031"<sip:4031@10.1.0.159:5060>;tag=bbd7fe4f7p
Call-ID: 3608be7b-7be1932e-19db9c47-e9842525@10.1.0.159
CSeq: 1 REFER
Contact: <sip:4031@10.1.0.159:5060>
Content-Length: 0


Any help with this problem would be gratefully recieved.

TIA

Which version of Brekeke PBX are you using?
Are you using OCS with it?

Because you are a developer, ask Brekeke to check the packet trace.

james wrote:Which version of Brekeke PBX are you using?
Are you using OCS with it?

Brekeke PBX, Version 2.2.6.2 , Pro Evaluation.

No not using OCS. Using Brekeke PBX and SIP server. Thats it. All phones and VMS 'hook up' to that.

Because you are a developer, ask Brekeke to check the packet trace.

Does that require that I am part of the Developer Support Program?

It seems 10.1.0.121 sent REFER.
Is it your application too?

And, Your DialPlan seems wrong...

>> To=sip:4000@10.1.0.159;tag=%1

Why do you need to replace "tag"?


>> Does that require that I am part of the Developer Support Program?

Because you are using original SIP application, I have no idea about it ... Ask Brekeke to analyze a packets trace.

james wrote:It seems 10.1.0.121 sent REFER.
Is it your application too?

Yes. 121 is my VMS, 159 is the Brekeke PBX/SIP Server.

And, Your DialPlan seems wrong...

>> To=sip:4000@10.1.0.159;tag=%1

Why do you need to replace "tag"?

I will remove that and test again. I can find very little useful documentation on dialplans and have basically been adapting other dialplans that do similar to what I require.

james wrote:Because you are using original SIP application, I have no idea about it ... Ask Brekeke to analyze a packets trace.

I've tried with the "tag%1" removed but it has made no difference.

What do you mean by "original SIP application"?

I would ask Brekeke to look at the packets, but I suspect that there is a cost involved in that and that is (currently) a "no-go".

>> 159 is the Brekeke PBX/SIP Server.

I'm confused.. because you said "The 4000:10.1.0159 in the dial plan is my VMS. "...

Can you clarify the above?
Who is 10.1.0.121:7030?
Who is 10.1.0.159?
Is there any other application program?

>> What do you mean by "original SIP application"?

because VMS is your original ...
I don't know how to setup it.

What does your dial plan mean?
Is it for making a call to VMS? Is it for making a call to the operator?

OK to clarify IP addresses.

10.1.0.159 is the Brekeke PBX/SIP Server
10.1.0.121 is the VoIP VMS

The VMS is registered in the PBX with extension 4000.

The dial plan is there to provide the VMS with what is effectively "divert CPI" or in a VoIP world a Diversion field in the SIP header. The Brekeke does not supply this by default.

To achieve this I have set all extensions in the Brekeke to divert to 73nnnn (where nnnn is the extension number) on no answer. The dial plan catches the 73 prefixed number and patches the SIP header appropriately (I hope ) The Diversion field then allows the VMS to work out who was originally being called and hence which 'mailbox' to use for the message.

However, if the incoming caller does not press any keys at the first menu then they are transferred to the operator after a timeout.

It is this transfer that fails.

A direct call to the VMS, so one that does not involve the dial plan, transfers successfully to the operator when the timeout occurs.

I am begining to suspect that there is some problem with what I am doing regarding the dial plan, but the Brekeke and the Wireshark packet traces give no information as to what has caused the problem.

Hi Andy ,,

Can you paste related DailPlan rules here?

Or, Ask Brekeke team to analyze the issue.

james wrote:Can you paste related DailPlan rules here?

My dialplan is in my first post, but here it is again

Matching Pattern

$port=15062
$localhost=true
$registered=false
$outbound=false
$request=^INVITE
$getUri(From)=!_ocs
To=sip:73(.{4})

Deploy Pattern

$transport=udp
$auth=false
&net.sip.transport.follow.request=true
To=sip:4000@10.1.0.159
Diversion=<tel:%1>;reason=user-busy;screen=no;privacy=off
$replaceurl=true

Or, Ask Brekeke team to analyze the issue.

I pretty sure that costs money.......that 'we' don't have.

Hi Andy ,

Are you sure that the above DialPlan rule is used?
If your DialPlan rule works correctly, you can see "Diversion" header in a SIP packet which sent from the SIP Server.
Can you see it?

If you use another SIP UA instead of yours, does the same issue happen?


Does your application send a REFER in a mid-session?
(It means a REFER uses the same Call-ID with INVITE.)

james wrote:If your DialPlan rule works correctly, you can see "Diversion" header in a SIP packet which sent from the SIP Server.

According to the export from the Wireshark trace I do get the Diversion header

INVITE sip:4000@10.1.0.121:7030 SIP/2.0
Via: SIP/2.0/UDP 10.1.0.159:5060;rport;branch=z9hG4bK0d01fbeabbff2d1431a2b-bd7b7b4c-6c4bdc73
Via: SIP/2.0/UDP 10.1.0.159:15062;rport=15062;branch=z9hG4bKb07b05f26ed6e9b825b2
From: "TMS VoIP" <sip:1001@10.1.0.159>;tag=beffb83b3p
To: <sip:4000@10.1.0.159:5060>
Max-Forwards: 18
Contact: <sip:1001@10.1.0.159:5060>
Call-ID: e152d32c-8f9baf51-c0abe944-82b6ef93@10.1.0.159
User-Agent: Brekeke PBX
CSeq: 1 INVITE
Allow: INVITE,ACK,BYE,CANCEL,INFO,MESSAGE,REFER,NOTIFY,SUBSCRIBE,UPDATE,PRACK
Diversion: <tel:4070>;reason=user-busy;screen=no;privacy=off
Record-Route: <sip:10.1.0.159:5060;lr>
Content-Type: application/sdp
Content-Length: 141


To clarify what is happening there. 1001 originally called 4070 but has been diverted to the VMS (4000) because of no answer from 4070.

If you use another SIP UA instead of yours, does the same issue happen?

Some of this confused me.

I have tried this test with a number of different 'extensions' to elimiate the possiblilty that it is related to the type of phone.....software (X-lite) verus desk phone (Linksys), so I think the answer to your question is yes I do get the same issue if I use another SIP UA. If that is not what you are asking then please explain

Does your application send a REFER in a mid-session?
(It means a REFER uses the same Call-ID with INVITE.)

Again, not too sure what you mean, but I think the answer is yes on both counts

The SIP server sends and INVITE to the VMS (packet shown above) and then after a timeout (because of no user interaction) a REFER is sent from the VMS to the SIP server to transfer the user (1001) to the operator. This REFER is the one that is getting the 403 response from the SIP server.

Checking both the INVITE and REFER packets in Wireshark I can see that they both have the same Call-Id.

The REFER packet is shown below.

REFER sip:1001@10.1.0.159:5060 SIP/2.0
From: <sip:4000@10.1.0.159:5060>;tag=68504f8-7900010a-1b76-50022-83cbb-782a95d-83cbb
To: "TMS VoIP"<sip:1001@10.1.0.159>;tag=beffb83b3p
Call-ID: e152d32c-8f9baf51-c0abe944-82b6ef93@10.1.0.159
CSeq: 1 REFER
Via: SIP/2.0/UDP 10.1.0.121:7030;branch=z9hG4bK-83cce-202d84c6-68e772c1
Refer-To: <sip:4069@10.1.0.159>
Referred-By: <sip:10.1.0.121:7030>
Max-Forwards: 70
Supported: replaces
Route: <sip:10.1.0.159:5060;lr>
Contact: <sip:10.1.0.121:7030>
Allow: INVITE, CANCEL, ACK, BYE, OPTIONS, REFER, NOTIFY
Allow-Events: refer
Content-Length: 0

Once again James, thanks for you time regarding this issue.