REFER failing with 403 Forbidden.

andyb · Last edited by andyb on Fri Mar 13, 2009 2:52 am; edited 2 times in total

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/networkpatterns.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 Patterns

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

Deploy Patterns

$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

james · Brekeke Master Guru Joined: 10 Dec 2007 Posts: 498

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.

andyb · Posted: Fri Mar 13, 2009 2:23 am Post subject:

james · Brekeke Master Guru Joined: 10 Dec 2007 Posts: 498

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.

andyb · Posted: Tue Mar 17, 2009 7:32 am Post subject:

andyb · Posted: Tue Mar 17, 2009 9:00 am Post subject:

james · Brekeke Master Guru Joined: 10 Dec 2007 Posts: 498

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

james · Brekeke Master Guru Joined: 10 Dec 2007 Posts: 498

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

andyb · Posted: Thu Mar 19, 2009 3:46 am Post subject:

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 Smile

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

james · Brekeke Master Guru Joined: 10 Dec 2007 Posts: 498

Hi Andy ,,

Can you paste related DailPlan rules here?

Or, Ask Brekeke team to analyze the issue.

andyb · Posted: Wed Apr 15, 2009 1:53 am Post subject:

james · Brekeke Master Guru Joined: 10 Dec 2007 Posts: 498

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

andyb · Posted: Thu Apr 16, 2009 8:39 am Post subject: