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
REFER failing with 403 Forbidden.
Moderator: Brekeke Support Team
REFER failing with 403 Forbidden.
Last edited by andyb on Fri Mar 13, 2009 2:52 am, edited 2 times in total.
Brekeke PBX, Version 2.2.6.2 , Pro Evaluation.james wrote:Which version of Brekeke PBX are you using?
Are you using OCS with it?
No not using OCS. Using Brekeke PBX and SIP server. Thats it. All phones and VMS 'hook up' to that.
Does that require that I am part of the Developer Support Program?Because you are a developer, ask Brekeke to check the packet trace.
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.
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.
Yes. 121 is my VMS, 159 is the Brekeke PBX/SIP Server.james wrote:It seems 10.1.0.121 sent REFER.
Is it your application too?
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.And, Your DialPlan seems wrong...
>> To=sip:4000@10.1.0.159;tag=%1
Why do you need to replace "tag"?
I've tried with the "tag%1" removed but it has made no difference.james wrote:Because you are using original SIP application, I have no idea about it ... Ask Brekeke to analyze a packets trace.
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.
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.
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.
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.
My dialplan is in my first post, but here it is againjames wrote:Can you paste related DailPlan rules here?
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
I pretty sure that costs money.......that 'we' don't have.Or, Ask Brekeke team to analyze the issue.
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.)
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.)
According to the export from the Wireshark trace I do get the Diversion headerjames wrote:If your DialPlan rule works correctly, you can see "Diversion" header in a SIP packet which sent from the SIP Server.
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.
Some of this confused me.If you use another SIP UA instead of yours, does the same issue happen?
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
Again, not too sure what you mean, but I think the answer is yes on both countsDoes your application send a REFER in a mid-session?
(It means a REFER uses the same Call-ID with INVITE.)
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.