Vodia PBX

Oh, okay. Well, that will clearly have the consequence that outbound calls will have to use one of the identities. Did you try this setup from the web interface? IMHO that should work already. Regarding *70 I agree it could be a problem. Maybe we have to split it up or change the IVR to explicitly log in or out.

Let me try to restate the question. So you want to swap the extensions?

Nope. Just make sure that your phone actually subscribes for MWI... That should do the job.

You can also use tcpdump which should be available on the appliance. For example, "tcpdump -i eth2 -nn -p -w dump.pcap" should capture the traffic on the WAN port.

Maybe it is time to factory-reset the phone now... I remember it took me a couple of reboots and resets and reboots to get this done. And drop the bootloader and the firmware into the tftp directory again (2.2.2 preferred). http://wiki.pbxnsip.com/index.php/Polycom contains a good list of what you should have in the tftp directory. The sip.cfg in the tftp does not correspond to the files on the master.xml, the templates that Polycom provides should not be read at all (they are just a generic example for manual edit, which is something we want to avoid by all means). You can also remove it from the tftp directory to really really make sure it is not being read.

Hmm. Can you verify that the call park code was sent from the same account where the call was received? E.g. when the call went to 300 and then later you call from 500 to park the call it is understandable that the PBX says "what call are you talking about?"...

Hmm, it is a little bit hard to say what the reason is. The PBX tries to establish the voice path already during the ringback, so that this pickup delay should be minimized. In not too incovenient, can you connect the PBX to a hub (or do port mirroring on a good Ethernet switch) and see what exactly is going on? Does that connect happen only with the service provider or does it also happen for internal calls to the same hunt group?

Ouch, seems there is for a strange reason a problem with the case. The link that is being generated is upper-case, while the matching expects lower case. Maybe just move the pnp.xml file away and restart the service (unfortunately that file is cached in the PBX). "In theory" the master file and the pnp.xml case should match and there should be no problem. The /provisioning is hardcodec inside the PBX and just tell it to run the filename through the pnp.xml file for a match. This is to keep other web access efficient, no need to run through a list of ERE!

I guess we can "officially" release 2.1.12 this week... Stay tuned!

Check out http://www.pbxnsip.com/protect/pbxctrl-2.1.12.2489.exe (see http://wiki.pbxnsip.com/index.php/Installi...#Manual_Upgrade for the upgrade procedure).

Could be a problem with the ACK branch values. Are you available for a test with a 2.1.12 version (what OS)?

Oh I think you need to update the PBX. There is a build 2933 available which might even solve your Caller-ID issues. But at least it will make PSTN logging possible. The SW is available from http://www.pbxnsip.com/software.

No that's fine.

So that file is not in the generated directory? Did you manually edit the pnp.xml file? Check out http://forum.pbxnsip.com/index.php?showtopic=701. There you see the logic how the PBX searches for files.

Any chance to get PSTN logging? Hint: You need to reboot the device to get them after enabling them in the web interface...

Set it to something lower, e.g. 5. Then if you are logging on log level 5, 6, 7, 8 or 9 those messages will make it into the log.

Does it work with the pbxnsip PBX?

Looks interesting. Is there any spec for this?

Looks to me like you are talking to the wrong port (UDP 5061) on the Avaya system. Check your outbound proxy. Maybe you have to use TLS or change the port 5060.

You can assign dial plans on per-extension basis. Is that the problem? Well, the problem for the PBX is that the call comes in on a trunk and it goes out on a trunk. Someone needs to pay the bill... (and that extension dial plan is being used). Not sure how this problem can be solved in another way. What about a tel:-alias? Does that solve the problem.

Do you have the SIP packets (INVITE request and the response)? If you know the ISP IP address, just filter for that IP address then you will see the relevant packets and you can copy and paste them here.

Make sure that you assign the real DID numbers in the PSTN gateway settings of the CS410. Then you can do inbound call routing as described in http://wiki.pbxnsip.com/index.php/Inbound_Calls_on_Trunk. That part is easy... Outgoing calls are a little more complicated. You can include the parameter "line" in the destination, then the cs410 FXO gateway will use only that line (for example, "line=3" means line 3). This way you can assign a dial plan to the executive that will send all calls to a specific line. Making sure that the other users do not use that line is a little bit more difficult. You would have to have three different dial plan entries and use the failover feature to find the first free line.

Line = trunk? So you want that only a specific user can use this trunk for outbound calls? Then you must create a dial plan specifically for that user and route the outbound calls over that trunk.

Looks like the PBX believes that the call comes from an extension, not from the carrier. One way to solve the problem is to take the domain context explicitly out and then route the calls just on DID basis. Which makes sense because usually incoming calls from the switch come from PSTN and then the PBX has to match it to the right domain based on the tel:alias. That could be done by putting a different domain name into the outbound trunk that sends the call to the switch. For example, you can set up just one global trunk to the switch that uses the outbound proxy and the domain name of the switch. That global trunk is in a dummy domain that has no accounts. Then incoming calls from the switch get distributed into the right domain based on the DID number (tel:alias). Outbound calls get the ANI (first tel:alias in 2.1) of the calling extension. When a loop from one domain to the other happens, the switch will send the call back to the PBX, the PBX will put that into the dummy domain, then look the DID up and send the call into the right domain.

Using Digium hardware with Trixbox is not a bad idea. If you want to use the Digium card with trixbox, Asterisk will work as PSTN gateway, just like other PSTN gateways (e.g. AudioCodes, Cisco, Mediatrix, Patton, Parlay, Vegastream, Welltech). Other vendors of PCI-cards offer a SIP API (Sangoma, Dialogic and I heared about Junghanns), so that you can use the PCI card in the same server where the PBX is running on Windows. Digium's only API (correct me if I am wrong) is Zaptel, and the only PBX supporting that is Asterisk. pbxnsip does not support Zaptel. The problem remains the same, no matter how many keys you have. Grandstream uses the "BLF" (aka RFC 4235) standard, which does not permit a call pickup. In other words, the pbxnsip PBX can tell the phone that there is a call coming in, the phone might even be able to display a blinking LED, but when you press that key nothing happens. IMHO that is not usable. We have specified a "buttons" package for Instant Messages that solves this problem. See http://wiki.pbxnsip.com/index.php/Buttons for more information. However, Grandstream does not support this method. It is always good if customers asking for features, so maybe you should ask them. I would just use the "private" lines one the phone (where the phone assigned the LED to calls itself). That is much easier and most customers think that is okay.