Vodia PBX

You can do that relatively easy with a IVR node. See http://wiki.pbxnsip.com/index.php/Linking_..._to_an_IVR_Node. The next version will make it possible to call an external number from a IVR node, that was possible yet. But you can already call an extension that has the cell phone forking enabled.

Should be possible: Set up a trunk "AtoB" on PBX A that points to PBX B. Use Gateway mode for that and set the domain (e.g. b.com) and outbound proxy (e.g. sip:64.63.42.21). Set up a trunk "BtoA" on PBX B that points to PBX A, same as above. Add an entry to the dial plan on PBX A that routes calls with a speicifc prefix to trunk "AtoB". Make sure that the priority is higher that the other "default" entries. As pattern you can use the whole telephone number of the other office (e.g. 6144356542) or just a short prefix (e.g. 614*). Add an entry to the dial plan on PBX B that routes calls with a speicifc prefix to trunk "BtoA".

You mean you want to trunk from one PBX to another? So that you can call from location A to location B directly over the Internet?

I think if you give callers the option to call the cell phone, they will do that. It will be difficult to charge them for that - one thing is how you automatically generate the bill, and the other question is if you have a business relationship with them at all. Plus do you really want to charge a customer because the PBX redirected the call to a cell phone? If I would be the customer, I would say why does that guy not sit in the office and pick up my calls? But I agree: The cell phone integration topic is not over. This will be one of the hot topics over the next couple of years.We have to keep this on hte radar and make it very usable.

Hmmm. Can you turn SIP logging on for the address 127.0.0.1? It would be good to see the INVITE coming from the PSTN gateway. If you can reproduce the problem, chances are good that we can solve the riddle...

Ehh... You are right. There is still one possibility. A auto attendant will immediately do to dial by name if you put "start" into the place where you currently have "411". If you use two auto attendants, then the first one can make the annoucement as described above, then redirect the call to the second attendant (which has an unspellable name like "dialbyname") and bingo - we have the perfect annoucement.

Well that would mean that the INVITE is already out. There is a new version that has more logging in this area: http://www.pbxnsip.com/protect/update-2898.tgz. Maybe you have the chance to give that image a shot.

Well write him an email and see what happens!

Well the PSTN gateway is really a seperate subsystem. Just like you connect an external PSTN gateway. The communication runs only via SIP. If a CO-line on the PBX gets stuck, then that means that the gateway did not send a BYE. So if you do logging, make sure that you are watching the SIP traffic on the IP address 127.0.0.1.

What surprises me here is that channel 1 obviously receives the caller-ID while in the "RING" state... Is that possible? I thought the caller-ID is sent in the pause between the first and the second ring?

With "hijack" I mean overwrite. Then select it in the AA as one of the annoucements and as direct destination put a "x" there.

You could hijack one of the existing prompts (e.g. "for support press") and use an unspellable pattern as input (e.g. "x"). Just a wild idea.

2.1.6 supports the recording of conferences. You must use a scheduled conference for that. When you create the conference, check the recording flag. Then the conference recording is available for the moderator (the one who created the conference) from the web interface. Needless to say, those files can get big. The conference must be deleted manually from the web interface to delete the recording.

STUN works only in < 80 % of the cases, leaving the remaining > 20 % as a support nightmare. We gave up troubleshooting all kinds of one-way audio problems and explicity removed the support for STUN-allocated identities. Our life and the life of our customers became much easier after that. And we saved a lot of money buying all these different DSL and cable routers to find out what the problem was with this and that installation. Pulver must get a session border controller. That is what practically all SIP service providers are doing. Or they should start supporting IPv6 addresses (no more NAT the way it was done in IPv4). If you don't have a routable address, don't expect that someone calls you . At least not in a reliable way.

The setting for the dial plan in indeed missing for the IVR node. The IVR node can only call internal numbers that do not require a dial plan. Feature will be available in the next version.

You mean the ARP cache does not get updated? That would be a huge surprise and IMHO a bug.

Probably the outbound proxy is not correct any more. My suggestion is to use the same IP address on the new machine as the old machine, this way you can keep the phones untouched. An alternative would be having a completely automatic plug and play. Then you may have to change option 66 on the DHCP server, and that's it.

Maybe just put the xxxxxxxxxx there.

You can redirect the calls from the ACD to an external number, that should be no problem. If you redirect from a ACD also to an extension, then the cell phone redirection rules apply again and the call will fork to the cell phone as well.

Do you remember what you had in that field before? ...

Sounds great! Anything that you would like to change on http://wiki.pbxnsip.com/index.php/Polycom to make other's life easier?

We got rid of these "$f $i $x $y $z" strings in the trunk. I think the new name is now "Trunk DID". Normally, it is okay to just leave it empty, the PBX then will automatically fill something useful in. It is debatable if that was a smart move. On the one hand, it caused a lot of support and problems with too much programmablility for nothing. On the other hand we have an upgrade issue, and now we need to explain everyone .

Whow. Indeed, that default certificate expired almost two years ago... If you want to get rid of these errors, you better get your own certifate anyway. There is some info on http://wiki.pbxnsip.com/index.php/Getting_...lid_Certificate.

That means that the PBX received a new media stream on the RTP port. It is allowed according to the IETF, but raises questions. A legal case could be that the other side uses an external music on hold server and sends music on hold out of the original media context. "Illegal" cases would be that there are really several audio streams running on the same RTP port. Do you have enough RTP ports open on the firewall? Or maybe there is a device that just did not stop sending audio streams?

http://www.pbxnsip.com/protect/update-2895.tgz has some more flags, e.g. for the CPC duration.