RobertoAchab

Hello, thanks, so it's only a matter to try and install it? I'm sure we're going to have resources enough, but I'd like to be sure about the "dedicated cpu", I saw in a blog article that it was mandatory an year ago, isn't there any official recommendation now? Regards

Hello, I'm planning to move our pbx to a virual environment, in this momento we don't know if it'll be vmware or scale, and I have a question about best practices. I read a blog article asserting that if I install the pbx on a VM I have to do it dedicating a phisical processor to that vm only. Is it still the offficial best practice for virtual enironments, or are there vm environments/configurations/products (i.e. the linux one) that doesn't need to dedicate a phisical processor to the PBX? I don't want to know if it simply "works", I need to know if it is officially supported by Vodia. Regards Roberto Arvigo

By the way, is it possible to use FQDNs in some ways in the access lists? a lot of our teleworkers have dyndns configured...

Hello, as I repeated a couple of times I was testing to move the pbx on a public ip because teleworkers would have great advantage in not using VPNs anymore, but they are connecting from dynamic IPs, so I can't use access list... well, I can't use them now, I was just thinking to ask developers if they can configure access list of the pbx as they do with hunt groups and phone calls from our CRM... but that is science fiction for now :-D

Hello, my pbx has only one trunk and it's confiured as an outbound proxy, the test I did was only for me, to be sure that without a trunk defined calls can't reach the pbx. The password for my extensions are randomly generated and periodically changed, so I think they are quite secure. Step by step I'm understanding how to secure my pbx, the only think I still can't understand is why the hacked calls came from accounts 100 and 1010, while those accounts don't exist (as phone numbers, service flags, ivr.... they don't exist at all). I can understand why hackers scanned whose numbers, because they usually are the desk's numbers, but my internal addressing has 9xx numbers, so where did pbx take "100" account? Is it so standard that it exists also if it's not defined as an account? Regards

OK, I tried and disabled the trunk, then I called from my mobile and the Patton gateway don't even receives the call, because the pbx is refusing it. Now at least I'm sure the hackers can't "impersonate" a trunk- Regards

Hello, I'm glad to read that calls couldn't be placed, as I didn't understand from the nightly report if they were only trials or real calls. Unfortunately they came from "100" and "1010", those accounts don't exist on my pbx, they aren't service flags, nor any other things. I assumed that they were seen as coming from a trunk for this reason. I think that this night I'm going to temove the outbound proxy and try to call from home to the office, if it fails then I'll know that without being configured a trunk can't reache the pbx. I'm also going to evaluate upgrading to 5, if I can find the spare time to test it. Regards

Sorry, maybe I'm misunderstanding all this... I have a trunk defined as outbound proxy, it's a patton connected to isdn lines, but I also do "hacked" calls from non-exixsting internal accoounts (like 1010, all my numbers start with 7), I can't understand how configuring an outbound proxy should stop these attacks.

Ok, i knew, but my role in the company is to give support to customers of a couple of programs we distribute, my boss decided that we are spending too mush time for this thing to work, so I think we're going to live with VPNs for a while and then, in some months we're going to migrate to an itsp, so those will be someone else's problems.

As I said before, I don't know which ips my user are coming from, they use dinamic-ip home ADSL connections. As far as I can read the conclusion is that you can't have a public pbx or you'll be helpless against hackers

Hello, I can have the strongest pasword policy (I was planning to have a process on our crm to change passwords automatically every weeks) but the hacked calls came from non-existing numbers(100 and 1010, my addressing doesn't use 1xx numbers), vhat can I do to tell the pbx that it can place calls only if they come from rgistered accounts? It seems to me like fighting mail relay, unortunately pbxs have a lot less tools than mail servers... Regards

...btw, in the few hours I had the public pbx xlite clients did correct login and placed phone calls, while some "behind double-NAT" SNOM hw phones didn't work or only received calls, but didn't call out. In the registration message of these phones the subnet declared was 10.176,x.x, I don't even know how the phone knew it, the phone was on a 192.168.x.x network, NATted behind a 10.176 by the provider (that thing explains the term "duble natted" :-)), then it was natted again to a public 93.x.x.x that was finally shown in the registration message as the real ip from which the phone came. The Xlite in the very same subnet showed the original 192.168.x.x ip in the registration instead (and 93.x.x.x as the real one) and it worked well. os there any way to say to the snom phone (821s and 3xxs) what to declare as the phisical p address? Should I use a STUN? and in this case which is a working free STUN? Thanks in advance for the answers.

Hello, thanks for the answer, giving a public ip address to the pbx is a solution to avoid using VPNs, the company I work for has mostly tele-workers and VPNs "instability" sometimes gives us problems. This is the reason why I can understand that "closing" the pbx from unknow ip addresses should secure it, but I don't want to do it, because teleworkers often have dinamic ip addresses (and sometimes they connect from their grandma' house... :-)). I already read the suggestion to set an outbound proxy, I'm attaching my only trunk configuration, but I can't understand how this can prevent internet-connected hacker-accounts to place calls. I can filter the outgoing phone numbers on the patton itself, obviously, but I'd prefer to keep all the "security" configurations on the pbx

Hello, recently I put a pbx on a public address, but as soon as I did it I was submerged by false call from an extension that didn't even exist. I found documentation about the fact that this behavior is caused by someone that impersonate e trunk. Now my question is how can I protect my trunk? I only have one patton and I don't want any other trunk, so is there any option in the pbx so that it asks for the trunks to be pre-configured, or that they have to do a signon? Also, is there a step by step guide somewhere about securing a pbx? i can use ten letter random passwords for my extensions, but if someone can simulate a trunk all my efforts are useless... Regards (I have a 4.5.0125 snomone pbx, I forgot to mention)

Hello, I installed a pbxnsip in the late 2009, then I got ill and came back to work only this summer, in june. Now they want to update to snom one, I tried to copy exactly the directory of this onto the pbxnsip's ones, but the result is very unstable (on a virtual test machine, obviously, not on a production environment :-)). We don't have a big pbx, it's 40 licenses only, but the configuration is compliated, lot of ivrs and autoattendandm call groups, backup trunks and things like that, I'd really like not to re-configure the snomone from scratch, so I ask you, is there a best practice for migrating from pbxnsip to snomone? thanks for the attntion bye Roberto

Thank you, I'm afraid I made a mistake, It is not the "supervisor monitoring" feature (I think it refers to ACD)? What's supervisor monitoring? Unfortunately a lot of terms being "logical" for english-speaking people are a little obscure for foreign people like me, expecially if in the pbx interface they are not called exactly the same...

Hello, I have to translate and describe the functionality of Pbxsip for our site, but I can't understand the "Permissions to monitor this account" field in ACD configuration, nor wiki explains it, because in ACD configuration that line doesn't exist (I think it was an olfer pbxnsip release...). Can, please, someone explain me? Which are the differences (if it's not totally a different thing) between this field and the "Queue Manager" field? Thanks in advance

Well, I usually don't speak in english, so pheraphs I've missed the point, the communication is already in T38, the Patton already converts it when calling Zoiper "alone", if Pbxnsip would let all packet to pass, the fax should arrive correctly...

BTW, giving a better look at the two trace, I think the error is in the first"good" Vs. fourth"bad" packet, in the good one there is an "invite" that includes a T38 announcements in the last rows, then zoiper responds "200" and receives the call. When pbxnsip sends the "same" invite it hasn't a T38 announcement, so Zoiper must accept it with a "ringing" state. I wonder why pbxnsip can't recognize and announce T38...

Yes, I knew, I think the problem is in negotiating the T38 protocol, Zoiper can't recognize an analog fax, but only a T38. As I said beofre Patton->Zoiper works well, that's the reason why I think that pbxnsip pheraphs "translates" some tone from rtp to SIP info, or something like that, the initial connection of the two faxxes should be exctly the same if pns were "transparent" :-(

Sure... In the attached zip file there is a sample of a successful transmission from Patton to Zoiper, and a sample of a failure through the pbx, same configuration of Zoiper and Patton. Patton = 192.168.101.7 Zoiper's PC 192.168.101.213 PBX 192.168.100.3 I set the Patton to repeat CNG three times Thank you PCAPs.zip

Hello, I'm testing T38 for our costumers, a lot of them need to route a fax call through an AA. I installed a Patton Gateway, configured to transform analog faxes in T38, then I have a Zoiper soft client on a machine, this client is an extension of our production pbx. I switch the PAtton between two configurations, the first sends the fax directly to the IP of the Zoiper client, the second sends it to the pbx, this is the only difference between the two (infact, I only change manually the SIP proxy address). pbxnsip has the inband detection enabled an AA with the "F" detection, and routing works well. now: If I send faxes directly to zoiper it receives them and wireshark shows a T38 communication. If i send the same fax through pbxnsip zoiper tells me the phone is ringing, as if he can't understand it's a fax, or a T38 communication. Unfortunately the first case is not a solution, because i'm sending ALL connections to Zoiper, so in a real environment my pbx couldn't receive any voice call. I think that pbxnsip in some way "strips" the ced tone, or sends it where it can't be heard by zoiper (I tried sip-info and rtp mixing them on Patton and Zoiper both), please is there someone knowing which are the correct parameters? Thank you

I had the same problem, unfortunately I was also the firewall administrator... What I understand is that when you do a port-forwarding to an host, you write a rule like "everything arriving at you to your port X must be forwarded to port X", that's correct, but what most upper-class firewall understand is "everything arriving at you to your port X from port Y must be forwarded to port X, like it was originated from a RANDOM port", this is simmetrical NAT, and ruins rtp streams (voice), while SIP (TCP) survives (so the phones register) being connection-oriented... You can see this problem tracking communications with wireshark, if you generate with a snom phone a log you will see udp packets starting from port X, then the same packets arrive to the pbx (another wireshark here) as if they were originated from other ports (tipically near 10000) With that situation there are no "simple solution" I used another device to publish the pbx (a full-cone NATting one), the other solution is to publish it setting the firewall in "transparent mode", if it has that option (and you have a free ip address)

Hmm, if I have understood your message (sorry, I'm not so good in reading/writing english) I don't want such a fault tolerance, I only want two PBXes working like one, then when the fiber fails the B-side users should phone over the the isdn of that site. Nothing more, unfortunately I must put B-Site phones in the hunting groups of A-site PBX

Yes, we obviously have two phone services, a 6 line ISDN in Milano and a 2 line ISDN in Genova (this is from another provider, it gaves us the fiber cable and a Cisco emulating a NT/1 device.