Vodia PBX

Whow, you mean the dial plan already blocks it? Is that a realistic use case? In an office environment I don't see the use of reporting someone for dialling a forbidden number... Maybe you can explain a real-life case where it would make sense to get a report on that...

The PBX is pretty quick blacklisting someone. After something like 10 attempts the address is already blacklisted and the damage is limited. If you want, you can forward the email about the blacklisting event to a clearing house. However, I believe it makes most sense to feed the firewall with these addresses, so that the PBX does not receive any traffic at all. Anyway, I believe the solution we have right now in version 4 is pretty okay and customers can run the system without worrying about someone taking the system down with a simple robot script.

Well, tell that the Outlook team . Anyway, it might imply a lot of unneccessary emails; but it would solve the problem.

The name is "cell_c2d" and you have to set it to "true" (case sensitive). In general, you can see in the extensions directory in one of the XML files the possible names. If you are not sure which one it is, change a setting and compary the old (copy) and the new version of the file.

Looking at IPv6, not sure how realistic that is in the world of plenty IP addresses.

What I am doing is use Outlook for this. There are planty of rules that you can use to sort incoming emails. I am sure you can get the above examples done with Outlook!

In the domain settings, you should see a setting for that... However, the prepaid stuff needs a special license key (--rate true). Make sure you have it...

I guess you want to set an extension parameter. There is "SetExtensionParameterRequest" for this, the name for the cell phone numbers is "cell_dis". <SetExtensionParameterRequest> <Extension>123@domain</Extension> <Parameter>cell_dis</Parameter> <Value>978-746-2777</Value> </SetExtensionParameterRequest>

We'll add a SOAP request that counts the registrations globally, per domain or per user. It will be like this: Request (with the usual SOAP stuff around it): <CountRegistrations> <Domain>abc.com</Domain> <User>32224</User> </CountRegistrations>

We can reproduce the problem now... Seems like the sending T.38 over TCP screws things up. We'll see how we can get this working.

The PBX can deal with such long rate tables in the trunks. However, this is only for reporting purposes. IMHO LCR is more the job of the ITSP. If you have a good ITSP, they will make your dial plan extremly simple.

Good point. We already had the idea to extend the graphic capabilities into the domains and also the accounts, trunks. This is something we hopefully can pick up with the next major release. Right now, you would have to generate auch a report, e.g. out of a database which stores the CDR. This will also be very powerful; but you need to invest significant time to program it

What version is this?

Our system admin told me that we need a special license key for the Ricoh... We try to get it. In the meantime, can you attach the whole trace? Maybe then we can see where the problem is...

The other workaround is to use "sip:callcentric.com:5060" as outbound proxy. The DNS A record for this includes all possible proxies, so that should work as well.

I believe that feature was added later (version 4).

Believe it or not, we have the same device in the office. I noticed the SIP/H.323 features and was wondering what this would be good for? Now I know. Can't wait to get back to the office...

Our experience with the 2007 certification was that it was a lot of work, but we did not see the business impact. Maybe this was because people were just playing because it is "cool" to talk Exchange, but nobody really used it in a productive environment (I don't know about anyone doing this). Unfortunately, being compatibe with Exchange is not trivial because of the way Microsoft uses SIP, so we set the priority relatively low for the Exchange 2010 certification. Also, the FAX support has changed, which IMHO makes Exchange 2010 less interesting than Exchange 2007.

After you get the plug, you should perform the steps mentioned here:http://www.plugcomputer.org/plugwiki/index.php/New_Plugger_How_ToThen after this the pbxnsip description makes https://www.pbxnsipsupport.com/index.php?_m...kbarticleid=576

We found a problem with callcentric and pbxnsip. callcentric obviously added more servers (congratulations!) and had also to add more entries to the DNS SRV field. We added a fix to the code and the next version will be able to deal with it. Workaround for existing version 4: Explicitly add "alpha1.callcentric.com alpha2.callcentric.com alpha3.callcentric.com alpha4.callcentric.com alpha5.callcentric.com alpha6.callcentric.com alpha7.callcentric.com alpha8.callcentric.com alpha9.callcentric.com" to the field "Explicitly list addresses for inbound traffic" in the callcentric trunk. Then the PBX will still use DNS SRV for locating a randon server; but it will accept traffic from the servers listed above. When CC adds more server, the list also must be adjusted. Workaround for other versions: Just randomly pick one of the alpha servers and use it as the outbound proxy.

Well, just make sure you don't overlap ports with a web server (ports 80 and 443).

Stability depends largely on the usage of a session border controller by the service provider. For example, if there is no SBC, you must have a routable ("public") IP address, otherwise you will always suffer from instable registrations. IPv6 will solve the problem. Untile then, you might also check http://kiwi.pbxnsip.com/index.php/Troubles..._Trunk_Problems.

Try to set connect=true, that should help. Of course it will only work if there is only one device to call.

https://www.pbxnsipsupport.com/index.php?_m...kbarticleid=203 is not really helpful here... The new knowledge base seems to lack the concept of links, therefore a link to the old knowledge base: http://kiwi.pbxnsip.com/index.php/Microsoft_Exchange. The key setting on the trunk is the "Accept Redirect", I guess you have set that.

Right now a CO line is bound to one trunk. We have other cases where customers are using one PSTN trunk for domestic calls and another ITSP trunk for international. In this case, customers feel it is a feature to see when the call comes in on the international line. However, once the initial excitement is over we might have to think about sharing a CO-line between different trunks.