Jump to content

Dial Plan bug?


R. Baltzer
 Share

Recommended Posts

Hi,

 

Since I have upgraded from PBXnSIP 3.4.0.3201 to PBXnSIP 4.2.0.3958 the dial plan is doing some strange things.

 

My dial plan:

100;Exchange Gateway;;7*;*

200;SIP Provider;;112;

300;SIP Provider;;xxxxxx;"sip:0123\1@\r;user=phone"

400;SIP Provider;;*;

 

With PBXnSIP version 3.4.0.3201 I was able to dial 7900 to connect to my Exchange server.

Since version 4.2.0.3958 this is not working anymore, this call is always directed to the "SIP Provider" trunk.

But even more strange is that my Snom 320 programmed button (speeddial 7900) is directed correctly to my Exchange server!

 

When I dial 7900 I see the following log information:

[5] 2010/11/24 08:15:59: Dialplan "PBXnSIP": Match 7900@localhost to <sip:7900@113.156.197.104;user=phone> on trunk SIP Provider

[5] 2010/11/24 08:15:59: INVITE Response 500 Server Internal Error: Terminate 304602b4@pbx

 

When I press the programmed speeddial button I see the following log information:

[5] 2010/11/24 08:15:20: Dialplan "PBXnSIP": Match 7900@localhost to <sip:900@192.168.0.10;user=phone> on trunk Exchange Gateway

[5] 2010/11/24 08:15:20: Charge user 900 for redirecting calls

 

As mentioned before, PBXnSIP version 3.4.0.3201 was working fine with this same dial plan!

Does anyone know what's going on here?

 

Kind regards,

 

Rene.

Link to comment
Share on other sites

Yes, that is really very strange. The same dial plan returns different results for the same input. So again, it makes a difference if you dial via the speed dial or directly from the phone? If that is reproducable, any clue from the SIP packets (INVITE)? Maybe there is a local dial plan on the phone that could cause this. Do you have multiple identities on that phone? Did you try the dial plan simulator (at the botton of the dial plan web page)?

Link to comment
Share on other sites

Yes, that is really very strange. The same dial plan returns different results for the same input. So again, it makes a difference if you dial via the speed dial or directly from the phone? If that is reproducable, any clue from the SIP packets (INVITE)? Maybe there is a local dial plan on the phone that could cause this. Do you have multiple identities on that phone? Did you try the dial plan simulator (at the botton of the dial plan web page)?

 

 

I have tried the dial plan simulator, it tells me that the Exchange trunk should be used.

So the dial plan is looking fine.

 

All my phones do have only one identity configured.

 

I have also created 2 log files on my Snom 320 phone (firmware 8.4.22).

One log while manually dialing 7900 and one log while pressing the retrieve button (programmed with speed dial 7900).

It looks to me like the problem is caused by the Snom phone; when I start dialing 7900 the phone is immediately sending some sip commands and these are using my sip trunk.

So now my dial plan is not functioning anymore I guess...

 

Could this be the problem?

 

LOG1.txt

LOG2.txt

Link to comment
Share on other sites

Could you explain this a bit more because I have no idea where to look?

 

Well, are you using shared lines on the phones? Or did you use it before (maybe the configuration is still present on the phone)? This would explain such strange behavior: First the phone seizes the line on the on-Exchange trunk and then when it dials the number the PBX actually keeps the promise and looks only at those entries of the dial plan that have this trunk as the destination.

Link to comment
Share on other sites

Well, are you using shared lines on the phones? Or did you use it before (maybe the configuration is still present on the phone)? This would explain such strange behavior: First the phone seizes the line on the on-Exchange trunk and then when it dials the number the PBX actually keeps the promise and looks only at those entries of the dial plan that have this trunk as the destination.

 

I have checked the shared line option on my Snom phones, but these are all disabled:

 

<user_shared_line idx="1" perm="">off</user_shared_line> <user_shared_line idx="2" perm="">off</user_shared_line> <user_shared_line idx="3" perm="">off</user_shared_line> <user_shared_line idx="4" perm="">off</user_shared_line> <user_shared_line idx="5" perm="">off</user_shared_line> <user_shared_line idx="6" perm="">off</user_shared_line> <user_shared_line idx="7" perm="">off</user_shared_line> <user_shared_line idx="8" perm="">off</user_shared_line> <user_shared_line idx="9" perm="">off</user_shared_line> <user_shared_line idx="10" perm="">off</user_shared_line> <user_shared_line idx="11" perm="">off</user_shared_line> <user_shared_line idx="12" perm="">off</user_shared_line>

All the Snom phones were flashed to firmware 8.4.22 after upgrading PBXnSIP from version 3 to 4 and the phones were reset to the factory defaults too.

So there could be no leftovers from an old configuration I suppose. The other phone settings are all due to PnP from PBXnSIP.

 

 

 

Link to comment
Share on other sites

  • 2 weeks later...

Well, there are several possibilites on snom phones to implement shared lines. The one above is not the one that the PBX is using.

 

The PBX uses buttons for shared lines. What you can do is clear the settings for the "fkeys" and reprovision the phones. Then you can be sure it is not using the pbxnsip shared lines.

 

 

Link to comment
Share on other sites

I do not understand what you mean by this.

I have provisioned the fkeys with PBXnSIP and programmed them to be "Shared line" buttons.

All my phones have been reset to the factory defaults before they were provisioned by PBXnSIP so there can not be any leftovers from an old configuration.

Do you mean by this that I should not be using the Shared Line buttons with PBXnSIP?

Link to comment
Share on other sites

Do you mean by this that I should not be using the Shared Line buttons with PBXnSIP?

 

The pbxnsip shared lines implicity lock the call to the seized line on the trunk, that is obviously not what you want. Park orbits may be something you want to use instead, they look similar and small groups can still transfer calls with one button push.

Link to comment
Share on other sites

The pbxnsip shared lines implicity lock the call to the seized line on the trunk, that is obviously not what you want. Park orbits may be something you want to use instead, they look similar and small groups can still transfer calls with one button push.

 

 

Thanks for replying.

This configuration was working fine with PBXnSIP 3.4.0.3201 (also with the Shared Line buttons) and it stopped working after the upgrade to version 4.2.0.3958.

I guess that the working of the Shared Lines is changed a lot then...

I will consider changing the configuration.

Thanks again.

 

Rene.

Link to comment
Share on other sites

Just curious why you upgraded to 4.2 if it was working fine in 3.4. Was there a particular feature you wanted in 4.x? Can you fall back to 3.4 for now since it sounds like a bug as pointed out in the prior post with the buttons that needs to be sorted out.

 

I know, but we are a reseller of IT related solutions and we also support the PBXnSIP software.

For this reason I want find problems myself in our own network instead of onsite by my customers.

 

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...