maslym

Yes, I did. I set up all four global variables and I could find them in pbx.xml file. I did further test by removing the user from the MySQL server and the CDR was still dumped into the database table. But when I removed the anonymous user from the MySQL server and kept the user, there was no CDR dumped into the database table. This makes me believe that the pbxnsip server is using anonymous user to talk to the MySQL database. Please check. Yimin

Yes, the call goes through. But what we need is a solution for multi-domain environment on one server. For example, if we have three domains: A, B and C. Both domain A and B have extension 905. Domain C has extension 901. How can extension 901 in domain C call extension 905 in either domain A or B without calling the trunk DID of either domain A or B first?

I tried to set the outbound proxy to the SIP proxy and it didn't make any difference.

Hi pbxnsip support, That's the setup we have been using since version 2 and now it stops working on almost all version 3.x release after version 3.0.1.3023. We can see that the call is routed back to the pbxnsip server by the SIP proxy server and the pbxnsip server sends back 'Not found' to the SIP proxy server. The loopback detection is turned off. Following are the error messages found in pbxnsip logfile. [5] 2009/07/30 10:31:10: Received loopback request without tag [5] 2009/07/30 10:31:10: Received incoming call without trunk information and user has not been found Thank you, Yimin

Hi pbxnsip support, I think I figured out the cause of the problem. The pbxnsip server is connecting to MySQL database as anonymous user. I set up a new mysql server on a window machine and created an anonymous user on it and now I can see CDR in the database. It seems the pbxnsip server doesn't use the username and password provided. Please check. BTW, usually our MySQL database is running on linux server. Thank you, Yimin

The mysql user used by pbxnsip has all privileges on the CDR table. I can see the INSERT statement sent from pbxnsip. But still the record cannot be saved in the table. Following is the tcpdump output. ---------------------------------------------------------------------------------------------------------------------------------------- 13:35:05.671884 IP 216.251.151.100.52481 > 64.254.145.211.3306: S 517339025:517339025(0) win 5840 <mss 1460,sackOK,timestamp 345459692 0,nop,wscale 2> 0x0000 0050 ba8f e548 001e bed8 7540 0800 4500 .P...H....u@..E. 0x0010 003c bc7d 4000 3a06 410d d8fb 9764 40fe .<.}@.:.A....d@. 0x0020 91d3 cd01 0cea 1ed5 f791 0000 0000 a002 ................ 0x0030 16d0 9d2d 0000 0204 05b4 0402 080a 1497 ...-............ 0x0040 4bec 0000 0000 0103 0302 K......... 13:35:05.671930 IP 64.254.145.211.3306 > 216.251.151.100.52481: S 860864178:860864178(0) ack 517339026 win 5792 <mss 1460,sackOK,timestamp 2580708677 345459692,nop,wscale 0> 0x0000 0078 0c00 0940 0050 ba8f e548 0800 4500 .x...@.P...H..E. 0x0010 003c 0000 4000 4006 f78a 40fe 91d3 d8fb .<..@.@...@..... 0x0020 9764 0cea cd01 334f beb2 1ed5 f792 a012 .d....3O........ 0x0030 16a0 9434 0000 0204 05b4 0402 080a 99d2 ...4............ 0x0040 7d45 1497 4bec 0103 0300 }E..K..... 13:35:05.706017 IP 216.251.151.100.52481 > 64.254.145.211.3306: . ack 1 win 1460 <nop,nop,timestamp 345459701 2580708677> 0x0000 0050 ba8f e548 001e bed8 7540 0800 4500 .P...H....u@..E. 0x0010 0034 bc7e 4000 3a06 4114 d8fb 9764 40fe .4.~@.:.A....d@. 0x0020 91d3 cd01 0cea 1ed5 f792 334f beb3 8010 ..........3O.... 0x0030 05b4 d3dc 0000 0101 080a 1497 4bf5 99d2 ............K... 0x0040 7d45 }E 13:35:05.706706 IP 64.254.145.211.3306 > 216.251.151.100.52481: P 1:61(60) ack 1 win 5792 <nop,nop,timestamp 2580708712 345459701> 0x0000 0078 0c00 0940 0050 ba8f e548 0800 4508 .x...@.P...H..E. 0x0010 0070 c3d4 4000 4006 337a 40fe 91d3 d8fb .p..@.@.3z@..... 0x0020 9764 0cea cd01 334f beb3 1ed5 f792 8018 .d....3O........ 0x0030 16a0 dece 0000 0101 080a 99d2 7d68 1497 ............}h.. 0x0040 4bf5 3800 0000 0a35 2e30 2e33 372d 6c6f K.8....5.0.37-lo 0x0050 6700 3c00 0000 3a3d 604f 4961 2f60 002c g.<...:=`OIa/`., 0x0060 a208 0200 0000 0000 0000 0000 0000 0000 ................ 0x0070 007a 635f 362d 7e56 725a 4b4a 7100 .zc_6-~VrZKJq. 13:35:05.743336 IP 216.251.151.100.52481 > 64.254.145.211.3306: . ack 61 win 1460 <nop,nop,timestamp 345459710 2580708712> 0x0000 0050 ba8f e548 001e bed8 7540 0800 4500 .P...H....u@..E. 0x0010 0034 bc7f 4000 3a06 4113 d8fb 9764 40fe .4..@.:.A....d@. 0x0020 91d3 cd01 0cea 1ed5 f792 334f beef 8010 ..........3O.... 0x0030 05b4 d374 0000 0101 080a 1497 4bfe 99d2 ...t........K... 0x0040 7d68 }h 13:35:05.745075 IP 216.251.151.100.52481 > 64.254.145.211.3306: P 1:68(67) ack 61 win 1460 <nop,nop,timestamp 345459710 2580708712> 0x0000 0050 ba8f e548 001e bed8 7540 0800 4500 .P...H....u@..E. 0x0010 0077 bc80 4000 3a06 40cf d8fb 9764 40fe .w..@.:.@....d@. 0x0020 91d3 cd01 0cea 1ed5 f792 334f beef 8018 ..........3O.... 0x0030 05b4 4854 0000 0101 080a 1497 4bfe 99d2 ..HT........K... 0x0040 7d68 3f00 0001 85a6 0300 0000 0001 0800 }h?............. 0x0050 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060 0000 0000 0000 7072 6f76 6973 696f 6e00 ......provision. 0x0070 149f 1143 99fc 931b a0ff 6bfd b51f 1edc ...C......k..... 0x0080 9fd3 c299 04 ..... 13:35:05.745254 IP 64.254.145.211.3306 > 216.251.151.100.52481: . ack 68 win 5792 <nop,nop,timestamp 2580708750 345459710> 0x0000 0078 0c00 0940 0050 ba8f e548 0800 4508 .x...@.P...H..E. 0x0010 0034 c3d5 4000 4006 33b5 40fe 91d3 d8fb .4..@.@.3.@..... 0x0020 9764 0cea cd01 334f beef 1ed5 f7d5 8010 .d....3O........ 0x0030 16a0 c21f 0000 0101 080a 99d2 7d8e 1497 ............}... 0x0040 4bfe K. 13:35:05.745294 IP 64.254.145.211.3306 > 216.251.151.100.52481: P 61:66(5) ack 68 win 5792 <nop,nop,timestamp 2580708750 345459710> 0x0000 0078 0c00 0940 0050 ba8f e548 0800 4508 .x...@.P...H..E. 0x0010 0039 c3d6 4000 4006 33af 40fe 91d3 d8fb .9..@.@.3.@..... 0x0020 9764 0cea cd01 334f beef 1ed5 f7d5 8018 .d....3O........ 0x0030 16a0 c30f 0000 0101 080a 99d2 7d8e 1497 ............}... 0x0040 4bfe 0100 0002 fe K...... 13:35:05.783376 IP 216.251.151.100.52481 > 64.254.145.211.3306: P 68:79(11) ack 66 win 1460 <nop,nop,timestamp 345459719 2580708750> 0x0000 0050 ba8f e548 001e bed8 7540 0800 4500 .P...H....u@..E. 0x0010 003f bc81 4000 3a06 4106 d8fb 9764 40fe .?..@.:.A....d@. 0x0020 91d3 cd01 0cea 1ed5 f7d5 334f bef4 8018 ..........3O.... 0x0030 05b4 8b9e 0000 0101 080a 1497 4c07 99d2 ............L... 0x0040 7d8e 0700 0000 0272 6164 6975 73 }......radius 13:35:05.783538 IP 64.254.145.211.3306 > 216.251.151.100.52481: P 66:92(26) ack 79 win 5792 <nop,nop,timestamp 2580708789 345459719> 0x0000 0078 0c00 0940 0050 ba8f e548 0800 4508 .x...@.P...H..E. 0x0010 004e c3d7 4000 4006 3399 40fe 91d3 d8fb .N..@.@.3.@..... 0x0020 9764 0cea cd01 334f bef4 1ed5 f7e0 8018 .d....3O........ 0x0030 16a0 d863 0000 0101 080a 99d2 7db5 1497 ...c........}... 0x0040 4c07 1600 0003 ff13 0423 3038 5330 3142 L........#08S01B 0x0050 6164 2068 616e 6473 6861 6b65 ad.handshake 13:35:05.783554 IP 64.254.145.211.3306 > 216.251.151.100.52481: F 92:92(0) ack 79 win 5792 <nop,nop,timestamp 2580708789 345459719> 0x0000 0078 0c00 0940 0050 ba8f e548 0800 4508 .x...@.P...H..E. 0x0010 0034 c3d8 4000 4006 33b2 40fe 91d3 d8fb .4..@.@.3.@..... 0x0020 9764 0cea cd01 334f bf0e 1ed5 f7e0 8011 .d....3O........ 0x0030 16a0 c1c4 0000 0101 080a 99d2 7db5 1497 ............}... 0x0040 4c07 L. 13:35:05.783570 IP 64.254.145.211.3306 > 216.251.151.100.52481: R 93:93(0) ack 79 win 5792 <nop,nop,timestamp 2580708789 345459719> 0x0000 0078 0c00 0940 0050 ba8f e548 0800 4508 .x...@.P...H..E. 0x0010 0034 c3d9 4000 4006 33b1 40fe 91d3 d8fb .4..@.@.3.@..... 0x0020 9764 0cea cd01 334f bf0f 1ed5 f7e0 8014 .d....3O........ 0x0030 16a0 c1c0 0000 0101 080a 99d2 7db5 1497 ............}... 0x0040 4c07 L. 13:35:05.819090 IP 216.251.151.100.52481 > 64.254.145.211.3306: P 79:213(134) ack 92 win 1460 <nop,nop,timestamp 345459729 2580708789> 0x0000 0050 ba8f e548 001e bed8 7540 0800 4500 .P...H....u@..E. 0x0010 00ba bc82 4000 3a06 408a d8fb 9764 40fe ....@.:.@....d@. 0x0020 91d3 cd01 0cea 1ed5 f7e0 334f bf0e 8018 ..........3O.... 0x0030 05b4 1927 0000 0101 080a 1497 4c11 99d2 ...'........L... 0x0040 7db5 8200 0000 0349 4e53 4552 5420 494e }......INSERT.IN 0x0050 544f 2072 6164 6163 6374 5f70 6278 6e73 TO.radacct_pbxns 0x0060 6970 2028 6073 7461 7274 5f64 6174 655f ip.(`start_date_ 0x0070 7469 6d65 602c 6065 7874 656e 7369 6f6e time`,`extension 0x0080 602c 6072 656d 6f74 655f 6361 6c6c 5f69 `,`remote_call_i 0x0090 6460 2c60 6475 7261 7469 6f6e 6029 2056 d`,`duration`).V 0x00a0 414c 5545 5320 2827 3230 3039 3037 3239 ALUES.('20090729 0x00b0 3133 3335 3036 272c 2739 3035 272c 272a 133506','905','* 0x00c0 3937 272c 2731 2729 97','1') 13:35:05.819111 IP 64.254.145.211.3306 > 216.251.151.100.52481: R 860864270:860864270(0) win 0 0x0000 0078 0c00 0940 0050 ba8f e548 0800 4500 .x...@.P...H..E. 0x0010 0028 0000 4000 4006 f79e 40fe 91d3 d8fb .(..@.@...@..... 0x0020 9764 0cea cd01 334f bf0e 0000 0000 5004 .d....3O......P. 0x0030 0000 a065 0000 ...e.. 13:35:05.819638 IP 216.251.151.100.52481 > 64.254.145.211.3306: F 213:213(0) ack 92 win 1460 <nop,nop,timestamp 345459729 2580708789> 0x0000 0050 ba8f e548 001e bed8 7540 0800 4500 .P...H....u@..E. 0x0010 0034 bc83 4000 3a06 410f d8fb 9764 40fe .4..@.:.A....d@. 0x0020 91d3 cd01 0cea 1ed5 f866 334f bf0e 8011 .........f3O.... 0x0030 05b4 d220 0000 0101 080a 1497 4c11 99d2 ............L... 0x0040 7db5 }. 13:35:05.819645 IP 64.254.145.211.3306 > 216.251.151.100.52481: R 860864270:860864270(0) win 0 0x0000 0078 0c00 0940 0050 ba8f e548 0800 4500 .x...@.P...H..E. 0x0010 0028 0000 4000 4006 f79e 40fe 91d3 d8fb .(..@.@...@..... 0x0020 9764 0cea cd01 334f bf0e 0000 0000 5004 .d....3O......P. 0x0030 0000 a065 0000 ...e.. 13:35:05.820597 IP 216.251.151.100.52481 > 64.254.145.211.3306: . ack 93 win 1460 <nop,nop,timestamp 345459729 2580708789> 0x0000 0050 ba8f e548 001e bed8 7540 0800 4500 .P...H....u@..E. 0x0010 0034 bc84 4000 3a06 410e d8fb 9764 40fe .4..@.:.A....d@. 0x0020 91d3 cd01 0cea 1ed5 f867 334f bf0f 8010 .........g3O.... 0x0030 05b4 d21f 0000 0101 080a 1497 4c11 99d2 ............L... 0x0040 7db5 }. 13:35:05.820603 IP 64.254.145.211.3306 > 216.251.151.100.52481: R 860864271:860864271(0) win 0 0x0000 0078 0c00 0940 0050 ba8f e548 0800 4500 .x...@.P...H..E. 0x0010 0028 0000 4000 4006 f79e 40fe 91d3 d8fb .(..@.@...@..... 0x0020 9764 0cea cd01 334f bf0f 0000 0000 5004 .d....3O......P. 0x0030 0000 a064 0000 ...d..

Hi pbxnsip support, Then what's the solution for big systems like ours? I am not sure if the loopback detection works. If the loopback detection is on. Following one line is found in the logfile. Received loopback request without tag If the loopback detection is off. Following two lines are found in the logfile. Received loopback request without tag Received incoming call without trunk information and user has not been found Thanks, Yimin

Now I could see data sent from the pbxnsip to the database server after I changed the password in user table to old format. But still records are not dumped into database table. I was wondering if the table format is mismatched. Thanks, Yimin

Hi pbxnsip support, I followed the instructions on your wiki website to set up the latest release (3.4.0.3201) to send CDR to MySQL database and nothing happened. From the pbxnsip logfile, I could see "SQL client: Connect to xxx.xxx.xxx.xxx:3306". But there were no records dumped into database table. I tried tcpdump on the MySQL port on the database server and there were no packets sent from the pbxnsip server. It seems to me that pbxnsip server never sent CDR out. Any idea? Thank you, Yimin

Hi pbxnsip support, Thank you for the update. First of all I tried the 'loopback' method and for some reason it didn't work. Even though the 'loopback' method works, it is still not a practical solution for us. We provide hosted PBX service and we have more than 80 domains on one server. If we use the 'loopback' method, we have to put all trunk DIDs in the dial plan of all domains. And each time when we add a new domain, we have to update the dial plan of all domains with the trunk DID of the new domain. Currently we are using external SIP proxy server to route the call back. Each time when we add a new domain, we don't need to worry about the routing issue since the external SIP proxy server will handle that properly. This setup is working very well on the old version pbxnsip software. Thanks, Yimin

Hi pbxnsip support, Any update on this topic? I found the same problem while testing the latest release (3.4.0.3201). Following is what I got from the log while calling trunk b on domain B from trunk a on domain A. ------------------------------------------------------------------------------------------ Received loopback request without tag Received incoming call without trunk information and user has not been found ------------------------------------------------------------------------------------------ I can make such inter domain call on version 2.xx.xx. Thanks, Yimin

When the Hot Desking is enabled, it also affects other extensions in any other domains that have the same extension number. Here is the scenario. Two domains are set up on the same PBXnSIP server: domain A and domain B. Domain A has two extensions: extension AA and extension BB. Domain B has one extension: extension BB. On domain A, dial *70 from extension BB, enter extension AA and PIN code so extension BB takes the ownership of extension AA. When dial *97 from extension BB, it reaches the main menu of extension AA's voice mail. When dial out from extension BB, it shows the caller ID of extension AA. Then on domain B, when dial *97 from extension BB, it now reaches the main menu of extension AA's voice mail on domain A. When dial out from extension BB, it now shows the caller ID of extension AA on domain A. It seems extension BB on domain B also takes the ownership of extension AA on domain A. This problem can be reproduced on all versions of PBXnSIP (version 2 to version 3) including the latest release 3.2.0.3143. Please check. Thank you, Yimin

We are running 1.9.2.16 on both XP and 2003 server and still getting the same problems.

Hi, We got report from several customers using PBXnSIP that when they set up call forwarding on the extension to the cell phone or landline number, they could hear DTMF tones in the incoming call forwarded by the PBXnSIP to their cell phone or landline number. We tested it and couldn't reproduce the same problem. Have you heard such problem before? Thank you, Yimin

Hi, We tried to install the CS410 appliance at our customer's site and the appliance couldn't get a public IP from the Internet service provider (ADSL). We tried both WAN port and LAN port and it's the same. The customer is using an old 3COM ADSL modem. I attached my laptop to the same modem and I could get a public IP. We then tried the appliace in the office on both the same Internet service provider(ADSL) and another Internet service provider(Cable) and the appliance could get a public IP from both service providers. Our office is using D-Link ADSL modem. I think there might be something to do with the customer's old 3COM ADSL modem. Any idea? Is there anything we can try on the appliance? Thanks, Yimin

When the conference is in Ad-hoc mode, the PINs are okay.

Thank you for prompt reply. Regarding star codes *9 and *1, the funny thing I found is that every participant can dial *9 or *1 except moderator. That is, every participant entering conference room by dialing participant's PIN can dial *9 and *1. But every participant entering conference room by dialing moderator's PIN cannot do that. That happens on all 2.1.x versions including the latest version 2.1.10.2474. Regarding the e-mail on conference # and PIN, I did try to put both participant's extensions and e-mail addresses separated by ';' into the Participants field and no e-mail was sent out by the system. The other thing I found is that the Start time and End time of scheduled conference don't work as they are supposed to. I can enter the conference room before Start time or after End time. I think this might be a bug. Thanks, Yimin

Hi, I tried the conference feature of pbxnsip and got following questions. 1. What's the difference between moderator and participant? I notice there are different PIN's for moderator and participant. And according to the your wiki website, the moderator has the ability to clean all participants of the conference by dialing *9 during the conference. But what I found is that every participant can do that as well. Is this a bug? I am using version 2.1.6.2447 on SuSE 10. Maybe I should upgrade the software. 2. How can I configure the system to send e-mail including conference # and PIN to each participant? I put each participant extension into the Participants field when creating scheduled conference but the system didn't send e-mail to each participant extension. 3. Where can I find the latest document on pbxnsip? The document available on your website is too old (version 2.0.x). Thank you, Yimin

Actually I set the mode of the Service Flag account to Manual and toggled the status of it between Clear and Set manually by calling it. The result is still the same.

But the fact is that the cell is also included in the call even after the "office hours". It seems to me that the service flag setup on the extension is totally ignored. Based on how the service flag works on other accounts such as auto attendant, my understanding is that during the office hours, incoming calls will ring the extension only. After the office hours, incoming calls will also ring the cell.

I am trying to use the service flag feature of the extension to redirect calls to the cell phone number and it doesn't work very well. On the Redirection page of the extension, I enter the cell phone number and set "Include the cell phone in calls to extension" to "Immediately". When the extension has no registrations, if the service flag is Clear, incoming calls to the extension are answered by the voice mail. If the service flag is Set, incoming calls to the extension are redirected to the cell phone number. When the extension has at least one registration, incoming calls to the extension always ring both the registered ATA and the cell phone number simultaneously no matter whether the status of the service flag is Clear or Set. This problem is found on both pbxctrl-suse10-2.1.2.2292 and pbxctrl-suse10-2.1.6.2446. Have I missed something or it's a bug? Any idea? The service flag feature on other accounts such as auto attendant works fine. Thanks.

Hi, I set up the Redirection target to extenion 501 and Redirection timeout to 30 seconds. After 30 seconds, the call is still in the queue. No redirection happens on the call. Any idea? I am using 2.1.2.2292 (Linux). Thanks.

Hi, When the mailbox is full, there is no way to access the mailbox from any other extension by dialing * and PIN. The system simply says that the mailbox is full and hangs up. The access to full mailbox from own extension is okay. I was wondering if this is a bug. Please advise. Thanks.

I got the similar problem before after upgrading the pbxnsip system from 2.0.3.xxxx to 2.1.0.xxxx. The problem only happened on CDMA cell phones. I fixed the problem by forcing the PSTN GW to use RFC 2833 for SIP DTMF relay.

Well, it seems putting a value there solves the problem. Thank you.