[aklawrence]

I'm trying to see if there is a way to distinguish SIP calls from PSTN calls for purposes of billing in the hotel module? It looks like there is only one billing rate table so I can't make different outbound rules for SIP versus PSTN calls. I am using the 3cx for hotel rooms and integrating the system with our main office VOIP gateway. If I look through the room's call log, costs are being determined by the associated rate in the billing table, eg. Room 101 called x5259 for a 5 minute duration and based on the default value of 1.0 in the rate table, the cost is roughly $5. The same logic holds true for a PSTN call. The problem is that I don't see a way to distinguish 4 digit calls from any other call since there is only one rate table and it appears to be global rather than VOIP provider or outbound route specific.
Am I wrong or is there a workaround?

Thanks in advance

[lneblett]

I am a lttle confused - Are you indicating that you want to be able to use either the PSTN and/or SIP trunks to be able to call the same locations and that depending on which Trunk was actually used to deliver the call you would like to have that trunk (provider's) billing rate applied?

Or is that the default rate is perhaps all too encompassing as any call that doesn't fit the country code is automatically assessed the default? Your example makes reference of an extension to extension call which, in my testing, does not show as a billable call in the hotel module, even with the default rate set to one. Of course, in my testing all extensions are of the same length and while your example uses Room 101 to x5259, I assume Room 101 is actually also a 4 digit extension.

While I am curious about the intent, as I am about to do a hotel and perhaps you have latched onto something that I have not considered, there is only the one rate table that i know of. It appears to me that you can use the SMDR output to discern which outbound trunk (SIP or PSTN) was used to make the call. How would you not create outbound rules to differentiate and direct calls to the two physically different mechanisms (SIP & PSTN)? You might be able to use a 3rd party call accounting software package that can take the SMDR output and manipulate it to provide the data you need. The SMDR output indicates the trunk used and then perhaps yo can build the billing tables accordingly. Then, I assume (again) that you might be able to take the now desired results and feed them back into the Hotel property management system for subsequent guest check-out/billing. In any event, I am not sure I understand the reference to the default rate as you applied it in your query. If the issue is that you wish not to charge a call to the 4 digit extension (which is not a country code), then set the default rate to 0 in the biling table. I am assuming that the extension is not making use of either PSTN or the SIP trunks. If on the other hand, you are directing calls to a specific outbound trunk based upon how a caller dials the number, then I understand. I assume it possible that in some cases one provider could have a better rate than another or maybe provides service to a location that the other doesn't, but regardless, wouldn't you typically modify the billing table to reflect the rate associated to the provider you have selected to serve that country? Do you need to granularize down to a city code? It also looks like you can add to the table as long as the digits emulate a country code usage.

[aklawrence]

Thank you for your response. Here is a more complete description:
We are a private club that also maintains 18 rooms for members and guests. We are currently migrating from an old InterTel PBX to a Microsoft Lync infrastructure using an NET VX1200 gateway. One of the last pieces of our implementation is our hotel rooms. Since Lync doesn't have a simple voicemail and handset option, we are planning on using 3CX to fill this gap. The testing we have setup right now would have all of our hotel rooms with 3CX extenstions (eg. 1401, 1402) and those calls all get routed within the 3CX server so there are not related charges. The way we have integrated them with our gateway is to create VoIP providers for each room and map the SIP registration of the hotel phone to the SIP registration of the VoIP provider. So basically we have each hotel room tied to a unique SIP registration on our VX1200. We can then dial our 4 digit internal extensions from hotel phones, eg. 5259, and the VX1200 knows that they are to be routed to our Lync handsets. I originally thought it would be best to create a bridge between the 3CX and our VX gateway but don't really understand how this is implemented in 3CX. I see the option in the management console and assume it is probably very easy when using two 3CX systems, but the documentation doesn't seem to go into how to configure a bridge correctly with a third-party gateway.
The second piece of that is local, and long distance calls. Right now, the dialing rules throw everything to our VX1200 and it sends PSTN calls out our PRI. So the problem arises in that I can't seem to differentiate calls that are "internal" SIP calls from hotel to Lync from calls that make it out the PRI. Ideally I would have two billing tables and could route internal SIP calls to the VX1200 and any PSTN calls out a third-party VoIP provider. It does seem like this would be consistent with anyone trying to use least cost routing.
The other complication I'm having is that the hotel software we are using to manage room booking and billing, only supports call accounting using a direct serial connection and the vendor's support is very limited with writing integrations. I'm trying to keep things simple for my front desk staff so they can use the 3CX hotel module to quickly look at a billing summary for calls and manually charge the guest on checkout. I don't know know if adding another interface with a third-party call accounting software would make help with trying to keep things simple for checkout procedures.
Hopefully that clarifies the problem and doesn't bore everyone.

[lneblett]

I see (as my head starts to spin). The problem as I see it is that the dialing rule is directing the calls to the same interface. I assume the implication is that when looking at the port/trunk status in 3CX there is only the one trunk registered which is the VX1200. I am not familiar with this particular gateway, but perhaps the manufacturer has a solution.

Wish I could help, but if 3CX is treating the dial plan as a common element and the VX1200 is doing the routing, then I am stuck. Otherwise, you could still use the CDR or SMDR to develop a solution, but it requires external processing that is not a standard function of 3CX.