Vodia PBX

One answer that I know is to use several IP addresses. One IP address for each domain. Don't ask... I also thought Cisco would know about DNS...

No, this is not normal. Well, I would call this "MS-SIP"... I guess we need to spend some time to make the PBX compatible with Exchange (again). Not sure why Exchange needs this kind of information. Other products work fine with without special blows and whistles.

That looks pretty good. What you can try is to set "Trunk requires out of band-DTMF tones", though I would give that only a small chance. The other thing that you can try is to put the handset into inband mode, so that all DTMF is inband by nature. Higher chance, but this will make it difficult to have DTMF on the PBX. Of course, it would be interesting what the trunk provider returns in the 200 Ok. My guess is that they return support for telephone-event, but when sending the RFC4733 tones it fails.

We will come out with a version 3.5. I think there we can include the 870 config file. I attach the files that you can throw into the html directory. Don't forget to remove them when you upgrade later. pnp.xml snom_3xx_fw.xml snom_870.xml

We need to redefine the logic for the recording location. On thing that is clear is that it should be a lot more account related, e.g. a feature of the ACD or the hunt group. Then it also becomes easier to come up with a useful name.

Hosted PBX and multicast are a problem, though not impossible. If the routers between the hosting company and the CPE router all suppotr multicast it is still possible (that was the original idea of the whole multicast project). Though today I would say not very practical. As a rule of thumb I would say multicast requires a local PBX right now.

In a conference you have to perform transcoding anyway. You must always add up all the different voices of the conference room anyway. There is no way around transcoding in a conference unless you limit the number of speakers to one.

The PBX really looks at the IP address on the IP packet itself, not in the SIP packet. In the SIP URI the IP address is not the point. Maybe that was the problem here. But there are also other ways to match the inbound request, e.g. on the DID number or the used domain.

You cannot register a trunk to the PBX (you can register a trunk from the PBX to an external registrar). You can register only a extension. Now sure if that makes sense here; but this is worth a try. Otherwise, I would just use the gateway mode of the trunk and use the outbound proxy on the gateway.

There is a small checklist for one way audio at http://pbxnsipsupport.com/index.php?_m=kno...ratingconfirm=1. Probably a problem with NAT? Or a problem with the codec negotation?

Well maybe you really have somehow created a loop. 30 redirections before locating the final destination is extremly long. I would not set such a high value, there must be something wrong in the setup.

Hosting can be so beautiful!

Well, it is difficult to have everything in one system. Technically, it is perfectly okay to run a seperate process/service for that. From a business perspective, it does make sense to offer the whole package. But that is the beauty about having SIP: You can pick the best components that you need and put them together. I know, some of those fax2email tools have price tags that are hefty. I agree, from customer perspective it would be nice to have it included--for free. But realisticly, we need to license libraries for the FAX negotiation which cost money, and if we do that we would essentially pass those costs through to the customer. It would make the product more expensive.

Yea sorry, stupid. I guess the problem is that you need a license key that allows you to do that! The log probably contains something line "SOAP: Need a professional license", right? Log level 5.

Did you check out the TAPI service provider (https://www.pbxnsipsupport.com/index.php?_m...kbarticleid=480)? For outbound calls it could solve the problem.

Make sure that the content-type is either "application/xml" or "text/xml".

Well, fax2email is something that can be very easily run externally. For example, faxback or Microsoft Exchange can do that. Or even use the FritzBox!

We are just using a hosted forum... No idea how to change or resolve this.......

Search for "Linux crontab"; I think this is the way to go. You can for example execute this command: "sync;reboot" to make sure everything is written to the flash and then reboot the system.

All set?

Does that PSTN gateway (what type is it BTW) support DTMF? Maybe you need to get a Wireshark trace to see what exactly is going on. It could be a problem of the gateway, not the phone.

Turn on the logging on for "other" SIP messages. Then you should see the whole SIP packet.

Actually I saw recently that some vendors (e.g. AudioCodes) supports a standard called "HTTPS".... Seems like this will bypass all audio channels and just post the fax on a central server. Apart from being out of the loop (which we obviously like a lot) this has the advantage that the FAX can now be encrypted (T.38 is unencrypted). For sending documents over the Internet that is IMHO an important feature.

The other thing that you can do is just write a shell script that walks through the cdr directory and pulls the information out that you want/need. If you are able to pull out usernames and passwords out of the PBX database on the filesystem, you sure can do the same for CDR at midnight.

I guess this phone talks SIP the same way the other phones do. So supporting this phone should be no problem. The other question is automatic provisioning. There we need to see if the templates that we have right now are sufficient.