Jump to content

Number 'NOT FOUND'


Happy

Recommended Posts

Since I upgraded from Pbxnsip version 3 to version 4, it is impossible to force an outgoing call to a specific trunk.

When I call out using the default trunk, things go well. But when I call out choosing a specific trunk with a prefix, I'm getting a NOT FOUND : DIALEDNUMBER.

 

Since the same dialplan worked fine for me on version 3, I have no idea where to look for to solve this issue.

Hope someone stumbled upon this problem also.

 

Marc.

Link to comment
Share on other sites

Are you using country codes? If that is the case keep in mind that numbers are always represented in "canonical" format (e.g. NANPA). In plain words, in the USA all numbers will be ten digits. If you dont want it, clear the country code then the dial plan will see what the user has entered.

I'm using country code 32.

According to the docs, that should exclude the NANPA and make me use a 'rest of the world' notation with 00 as prefix for international calls.

Is there a way in the log-settings to see what number is actually sent to the trunk ? Without the country code, my default trunk won't work correctly either.

Link to comment
Share on other sites

I'm using country code 32.

 

There is also canonical format for ROW. International numbers (outside of 0032) are represented in 00xxxx format, national numbers in the format 0xxxx. If you set the domain code, you also get numbrs without 0 prefix for local calls. This number is put into the dial plan.

 

According to the docs, that should exclude the NANPA and make me use a 'rest of the world' notation with 00 as prefix for international calls.

Is there a way in the log-settings to see what number is actually sent to the trunk ? Without the country code, my default trunk won't work correctly either.

 

You can see what is fed into the dial plan on log level 9. That is very useful to debug problems like the one that we have here.

Link to comment
Share on other sites

There is also canonical format for ROW. International numbers (outside of 0032) are represented in 00xxxx format, national numbers in the format 0xxxx. If you set the domain code, you also get numbrs without 0 prefix for local calls. This number is put into the dial plan.

 

 

 

You can see what is fed into the dial plan on log level 9. That is very useful to debug problems like the one that we have here.

I have a dial plan where the numbers starting with 1 and 2 go to a specific trunk : type pattern 1* // replacement *.

It looks like these 2 are not well handled by the dial plan, the respective trunks seem not to be found (see the log below).

This was not the case in version 3, I don't see why, but you probably do.

 

----Log file---

[8] 2010/11/25 20:39:59: Could not find a trunk (4 trunks)

[6] 2010/11/25 20:39:59: Received bindRequest for user pbx.praktijk.be\12

[6] 2010/11/25 20:40:03: Received searchRequest, cn=

[8] 2010/11/25 20:40:04: Could not find a trunk (4 trunks)

[7] 2010/11/25 20:40:04: Set packet length to 20

[6] 2010/11/25 20:40:04: Sending RTP for 3c29221ee5dc-azxfh9mboreo to 192.168.1.22:59164, codec not set yet

[8] 2010/11/25 20:40:04: Call from an user 12

[8] 2010/11/25 20:40:04: To is <sip:10495123456@pbx.praktijk.be;user=phone>, user 0, domain 1

[8] 2010/11/25 20:40:04: From user 12

[8] 2010/11/25 20:40:04: Call state for call object 148: idle

[7] 2010/11/25 20:40:04: set_codecs: for 3c29221ee5dc-azxfh9mboreo codecs "", codec_preference count 6

[9] 2010/11/25 20:40:04: Dialplan: Evaluating !^0([0-9]*)@.*!sip:0\1@\r;user=phone!i against 10495123456@pbx.praktijk.be

[9] 2010/11/25 20:40:04: Last message repeated 2 times

[9] 2010/11/25 20:40:04: Dialplan: Evaluating !^1([0-9]*)@.*!sip:\1@\r;user=phone!i against 10495123456@pbx.praktijk.be

[9] 2010/11/25 20:40:04: Dialplan: Evaluating !^2([0-9]*)@.*!sip:\1@\r;user=phone!i against 10495123456@pbx.praktijk.be

[9] 2010/11/25 20:40:04: Dialplan: Evaluating !^329909([0-9]*)@.*!sip:329909\1@\r;user=phone!i against 10495123456@pbx.praktijk.be

[7] 2010/11/25 20:40:04: Set packet length to 20

Link to comment
Share on other sites

Well, this one should work! There is something fishy here. Maybe some "invisible" characters here like a space?

Strange thing is : when I go back to verion 3, just by changing the pbxctl.exe file, the dialplan works again.

What do you suggest me to do, the dialplan just seems to skip the right trunk. Reinstall some things here ? Or look into the trunks or dialplan directory for anomalies ?

 

Any suggestions highly appreciated !

Link to comment
Share on other sites

Well, this one should work! There is something fishy here. Maybe some "invisible" characters here like a space?

I ran some tests, but did not come to a solution anyway :

1. Created new expression in dialplan (4* replaced by *, and the standard trunk : works fine

2. Same dialplan expression, with the trunks that were not working : a 'not found : number'.

3. Deleted one of the trunks and build it up again : just a 'not found' on the display, no comfort noise.

 

One of the trunks that are not working is a patton gateway, the other one is a Ipness Sip account.

The 2 accounts working are Weepee Sip accounts.

 

I did check the subdirectories trunks, dial_plan and dial_plan_entry. There were no abnormalities.

 

Well I'm stuck here. Hope support comes up with some ideas.

Marc

Link to comment
Share on other sites

  • 2 weeks later...

I'm having the same problem as the above poster. Here is a verbose output of my logfile:

Please note, I'm configured to SIP trunks which provide our dialtone. They require e164 number format for dialing. I'm running this under linux, ClearOS 5.2 (CentOS base).

 

SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.2.63:2048;branch=z9hG4bK-fldyvxgnso0j;rport=2048
From: <sip:40@192.168.2.160>;tag=uhu2hvbrm4
To: <sip:40@192.168.2.160>;tag=a194625d70
Call-ID: 3c2670679951-nwr4iraahml8
CSeq: 549 REGISTER
Contact: <sip:40@192.168.2.63:2048>;expires=361
Supported: path
Date: Wed, 8 Dec 2010 19:29:54 GMT
Content-Length: 0

[9] 2010/12/08 19:31:36:	UDP: Opening socket on 0.0.0.0:53642
[9] 2010/12/08 19:31:36:	UDP: Opening socket on 0.0.0.0:53643
[9] 2010/12/08 19:31:36:	UDP: Opening socket on [::]:53642
[9] 2010/12/08 19:31:36:	UDP: Opening socket on [::]:53643
[8] 2010/12/08 19:31:36:	Could not find a trunk (3 trunks)
[9] 2010/12/08 19:31:36:	Resolve 773: aaaa udp 192.168.2.63 2048
[9] 2010/12/08 19:31:36:	Resolve 773: a udp 192.168.2.63 2048
[9] 2010/12/08 19:31:36:	Resolve 773: udp 192.168.2.63 2048
[9] 2010/12/08 19:31:36:	Resolve 774: aaaa udp 192.168.2.63 2048
[9] 2010/12/08 19:31:36:	Resolve 774: a udp 192.168.2.63 2048
[9] 2010/12/08 19:31:36:	Resolve 774: udp 192.168.2.63 2048
[8] 2010/12/08 19:31:36:	Tagging request with existing tag
[7] 2010/12/08 19:31:36:	Set packet length to 20
[6] 2010/12/08 19:31:36:	Sending RTP for 3c273d2e5acf-uu4dkwylvt81 to 192.168.2.63:51454, codec not set yet
[9] 2010/12/08 19:31:36:	Resolve 775: aaaa udp 192.168.2.63 2048
[9] 2010/12/08 19:31:36:	Resolve 775: a udp 192.168.2.63 2048
[9] 2010/12/08 19:31:36:	Resolve 775: udp 192.168.2.63 2048
[8] 2010/12/08 19:31:36:	Call from an user 40
[8] 2010/12/08 19:31:36:	To is <sip:+91831xxxxxxx@192.168.2.160;user=phone>, user 0, domain 1                    <!--Edited out the number-->
[8] 2010/12/08 19:31:36:	From user 40
[8] 2010/12/08 19:31:36:	Set the To domain based on From user 40@pbx.company.com
[8] 2010/12/08 19:31:36:	Call state for call object 29: idle
[9] 2010/12/08 19:31:36:	Dialplan: Evaluating !^9([0-9]*)@.*!sip:\+\1@\r;user=phone!i against +91831xxxxxxx@192.168.2.160           <!--Also edited out the number-->
[7] 2010/12/08 19:31:36:	set_codecs: for 3c273d2e5acf-uu4dkwylvt81 codecs "", codec_preference count 6
[7] 2010/12/08 19:31:36:	Set packet length to 20
[9] 2010/12/08 19:31:36:	Resolve 776: aaaa udp 192.168.2.63 2048
[9] 2010/12/08 19:31:36:	Resolve 776: a udp 192.168.2.63 2048
[9] 2010/12/08 19:31:36:	Resolve 776: udp 192.168.2.63 2048
[9] 2010/12/08 19:31:36:	Resolve 777: aaaa udp 192.168.2.63 2048
[9] 2010/12/08 19:31:36:	Resolve 777: a udp 192.168.2.63 2048
[9] 2010/12/08 19:31:36:	Resolve 777: udp 192.168.2.63 2048

Link to comment
Share on other sites

Well, this one should work! There is something fishy here. Maybe some "invisible" characters here like a space?

Checked out some more and made a sip-log of the problem :

 

-----Log Partim -------

[7] 2010/12/10 12:50:25: Cannot convert number 20495****** into global format

[7] 2010/12/10 12:50:25: Last message repeated 4 times

[7] 2010/12/10 12:50:25: SIP Tx tls:192.168.1.22:2344:

SIP/2.0 100 Trying

Via: SIP/2.0/TLS 192.168.1.22:2344;branch=z9hG4bK-x5f790s0efyx;rport=2344

From: "Bureel" <sip:12@pbx.praktijk.be>;tag=tada1u8hqo

To: <sip:20495******@pbx.praktijk.be;user=phone>;tag=b209a129e7

Call-ID: 3c26a7c1696f-75gxn6gfe3d9

CSeq: 1 INVITE

Content-Length: 0

 

-----------------------

Dial Plan : Pattern = 2* | Replacement = * | Trunk = Ipness

-----------------------

 

So the number 20495****** should be going to trunk Ipness AND be stripped to 0495******.

Looks to me even the trunk is not found ?? Number - unstripped - is handled to ???

 

Marc

Link to comment
Share on other sites

[7] 2010/12/10 12:50:25: Cannot convert number 20495****** into global format

 

That is probably because you have the country code set, but not the area code. You can try to use the area code "-" to suppress this message. Then the PBX will convert it into something like +3220495****** (for Belgium). Then in the dial plan you would have to match 00322* instead of 2* (00 is used in ROW for the + symbol).

 

If you dont like the reformatting according to the country code at all, you can of course take it out. But I think it is better to keep it and change the dialplan accordingly.

 

So the number 20495****** should be going to trunk Ipness AND be stripped to 0495******.

Looks to me even the trunk is not found ?? Number - unstripped - is handled to ???

 

You should see in the log what number the PBX is actually matching. But I guess there is a confusion going on with the country code replacement algorithm.

Link to comment
Share on other sites

There are several interesting facts in your answer :

 

1. <<your answer 'You can try to use the area code "-" to suppress this message. Then the PBX will convert it into something like +3220495****** (for Belgium). Then in the dial plan you would have to match 00322* instead of 2*'>>

Means that pbxnsip is doing the number comversion (according to country code and area code) BEFORE the number reaches the dial plan. That is of cause very inconvenient and quite unpractical to work with. Because all Belgian numbers start with 0, I can use prefixes like 1 or 2 to go to a specific trunk. But if the 1 and 2 get mixed up in a general format before they reach the dial plan, the starting 0 is filtered out and I can't distinguish between the prefix 1 and a normal number starting with 01. That means I'll have to use something like a star code #111# to send numbers to a specific trunk. Is it possible to give this code after the number also ?

 

2. I followed the wiki instructions to get a sip trace, but I did not manage to see the actual conversion of the number before it reaches the dialplan. Maybe I'm missing something here. In addendum the complete sip trace like I managed to make it. Are my log settings incomplete ?

 

3. When does the trunk number modifications (rewrite general number) take place : they should at least be after the dial plan conversions ??

Log Ipness.txt

Link to comment
Share on other sites

Means that pbxnsip is doing the number comversion (according to country code and area code) BEFORE the number reaches the dial plan. That is of cause very inconvenient and quite unpractical to work with. Because all Belgian numbers start with 0, I can use prefixes like 1 or 2 to go to a specific trunk. But if the 1 and 2 get mixed up in a general format before they reach the dial plan, the starting 0 is filtered out and I can't distinguish between the prefix 1 and a normal number starting with 01. That means I'll have to use something like a star code #111# to send numbers to a specific trunk. Is it possible to give this code after the number also ?

 

When a user dials a number, the PBX has to convert the number into a canonical format. Otherwise, you would for example always have to deal with the problem that the user dials 00321234 or 01234 (area code makes even more cases possible). In the dial plan, you have to deal only with one representation. The representaion is the "local" representation, that means the country code (with the 00 prefix) is only used when neccessary and the area code also only used when neccessary.

 

If you want to use a country code but dont want to use the area code, you can use "-" as the area code.

 

2. I followed the wiki instructions to get a sip trace, but I did not manage to see the actual conversion of the number before it reaches the dialplan. Maybe I'm missing something here. In addendum the complete sip trace like I managed to make it. Are my log settings incomplete ?

 

On log level 9 you should see something like "Dialplan: Evaluating so-and-so against so-and-so" (Log IVR events).

 

3. When does the trunk number modifications (rewrite general number) take place : they should at least be after the dial plan conversions ??

 

There are several stages when the PBX needs to convert numbers. The first step is when the call comes in to the PBX (into a global format starting with +), then when it hits the dialplan and finally when it hits the trunk into the format that the service provider would like to see.

Link to comment
Share on other sites

If you want to use a country code but dont want to use the area code, you can use "-" as the area code.

'-' is not accepted in the area code field, has to be a number.

But anyway, problem is the same wether I use the country code or not.

 

On log level 9 you should see something like "Dialplan: Evaluating so-and-so against so-and-so" (Log IVR events).

 

This is a small portion of the log file, first with just the number, next one with a 1 before the tel.number.

Looks to me the dialplan skips all options and doesn't find a match, though it definitely should match !

 

----------Log -------------

[8] Call from an user 19

[8] To is <sip:0495******@pbx.praktijk.be;user=phone>, user 0, domain 1

[8] From user 19

[8] Call state for call object 703: idle

[9] Dialplan: Evaluating !^0([0-9]*)@.*!sip:0\1@\r;user=phone!i against 0495******@pbx.praktijk.be

[5] Dialplan "Algemeen Kiesplan": Match 0495******@pbx.praktijk.be to <sip:0495******@ssw0.brussels.weepee.org;user=phone> on trunk WeePee

[8] Call state for call object 703: alerting

 

*******************

 

[8] Call from an user 19

[8] To is <sip:10495******@pbx.praktijk.be;user=phone>, user 0, domain 1

[8] From user 19

[8] Call state for call object 704: idle

[9] Dialplan: Evaluating !^0([0-9]*)@.*!sip:0\1@\r;user=phone!i against 10495******@pbx.praktijk.be

[9] Last message repeated 2 times

[9] Dialplan: Evaluating !^1([0-9]*)@.*!sip:\1@\r;user=phone!i against 10495******@pbx.praktijk.be

[9] Dialplan: Evaluating !^2([0-9]*)@.*!sip:\1@\r;user=phone!i against 10495******@pbx.praktijk.be

[9] Dialplan: Evaluating !^329909([0-9]*)@.*!sip:329909\1@\r;user=phone!i against 10495******@pbx.praktijk.be

 

------------End Log ---------

Link to comment
Share on other sites

Spent some quality time on it...

 

This must definitevely have to do with CO-lines. Can you check in the directory colines if there are any entries and if yet, if there is one file that contains a paramter "user"? If that is so, please remove that user, restart the system and see if that did a change. Actually a restart should clear the CO line anyway.

 

That "user" means that this user has seized the line and outbound calls must stick with it. It must be something in this area.

 

 

Link to comment
Share on other sites

Spent some quality time on it...

 

This must definitevely have to do with CO-lines. Can you check in the directory colines if there are any entries and if yet, if there is one file that contains a paramter "user"? If that is so, please remove that user, restart the system and see if that did a change. Actually a restart should clear the CO line anyway.

 

That "user" means that this user has seized the line and outbound calls must stick with it. It must be something in this area.

I' m using 6 CO-lines, 2 on the Belgacom trunk and 4 on the Weepee trunk. These entries are in the \colines directory. Every xml-file contains a #text field referring to one of the trunks. No user info there.

 

I did a restart, things remain the same. Log info exactly as before.

 

If you think that Co lines are the culpit, I could of course remove them all and see what I'm getting. Does that make any sense to do ?

 

Best Regards,

Marc

Link to comment
Share on other sites

I' m using 6 CO-lines, 2 on the Belgacom trunk and 4 on the Weepee trunk. These entries are in the \colines directory. Every xml-file contains a #text field referring to one of the trunks. No user info there.

 

I did a restart, things remain the same. Log info exactly as before.

 

If you think that Co lines are the culpit, I could of course remove them all and see what I'm getting. Does that make any sense to do ?

 

Best Regards,

Marc

 

Before removing the CO lines, I would delete the country code setting (under the domain) and try it. In the USA, we set the country code on the domain so that user can either dial 10 digit or 11 digits.

Link to comment
Share on other sites

I' m using 6 CO-lines, 2 on the Belgacom trunk and 4 on the Weepee trunk. These entries are in the \colines directory. Every xml-file contains a #text field referring to one of the trunks. No user info there.

 

I did a restart, things remain the same. Log info exactly as before.

 

If you think that Co lines are the culpit, I could of course remove them all and see what I'm getting. Does that make any sense to do ?

 

Best Regards,

Marc

 

Before removing the CO lines, I would delete the country code setting (under the domain) and try it. While country code setting is useful, it may create issues like this sometimes. In the USA, we set the country code on the domain so that user can either dial 10 digit or 11 digits.

Link to comment
Share on other sites

Before removing the CO lines, I would delete the country code setting (under the domain) and try it. While country code setting is useful, it may create issues like this sometimes. In the USA, we set the country code on the domain so that user can either dial 10 digit or 11 digits.

Removing the country code did not solve the problem.

However .. removing all CO lines did !

 

Now next question : can I just put the CO lines back ? Is it better to first set the index.txt file to 1 in the colines directory ?

 

Marc.

Link to comment
Share on other sites

Just created the same co-lines on the trunks, everything works fine.

Many thanks for the support, would never have found this one without your input !

 

There must be a bug somewhere so that the CO line does not get cleared. Obviously then it never gets cleared again. We also have to investigate in the code; however if it should happen again, it will be a lot faster to fix it...

Link to comment
Share on other sites

There must be a bug somewhere so that the CO line does not get cleared. Obviously then it never gets cleared again. We also have to investigate in the code; however if it should happen again, it will be a lot faster to fix it...

Indeed there must be a bug : same problem occurs again every now and then.

Until now, a simple restart of the service clears the co-lines.

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.

×
×
  • Create New...