Then the identity can be seen from the outbound call (callerid being sent)
at whatever switch they are going through.

I would recommend getting the billing/cdr at the lec/clec/itsp switch. It
will be more reliable. If queried properly it will be able to provide exact
data and will bill properly.

Sipx cdr is not accurate enough for billing (IMO), but good enough for
reference.

What type of switch is it sending the calls through?
============================
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.984.8431

Email: [email protected]

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
Fax: 434.984.8427

Helpdesk Contract Customers:
http://www.myitdepartment.net/gethelp/

----- Original Message -----
From: [email protected]
<[email protected]>
To: Discussion list for users of sipXecs software
<[email protected]>
Sent: Sun Sep 19 19:09:34 2010
Subject: Re: [sipx-users] dial plan logic for multiple DID's


You want each user to have a different outbound dialing plan?
Well... I want to have each user's outbound calls to route through their own
gateway. I need to be able to do billing for things like long distance,
peering costs, and toll calls. Each DID is a different client.

Unless you are doing something out of the ordinary, outbound dialing plans
can be "plain" and applied to groups or globally.
I might be doing something out of the ordinary actually.  We have a group of
customers that are on our DSL service and we are thinking to convert them
over and offer residential phone service to them as well.  I have made 9
dialing rules that should cover all of the users, IF I can still control the
route that each user uses (their gateway). I see in each rule you specify
which gateways use each dial plan rule... but.  Does this mean that I need
to make a set of dial plan rules for each customer (DID)?


Inbound dialing plans can be used, but it is more typical to use a DID on a
user as an "alias".
Create a user, add the DID as the alias. Inbound calls fro the DID got o the
user. Dialing plans are not involved at the inbound call to the user.
I have inbound working perfectly, just as you are describing.



On Sun, Sep 19, 2010 at 6:23 PM, Mark Theis
<[email protected]<mailto:[email protected]>> wrote:
Hi all...  I think that I am just making myself go crazy.  I am trying to
make my pbx host each user to have a DID and not shared gateways.  Do I need
to make full sets of dial plans for each of the users?  Let's say I have 100
users each with their own DID/gateway assigned.  IF I need to make an entire
dial plan set for each of them, I would need 900 rules.

I have been playing with making the gateway not shared and creating a new
'branch' for each one, assigning that to each user.  Is this the way that it
is supposed to work? Or am I missing something?  I really think that it
would be a pain to make 900 dial rules.

Someone please tell me that I am not looking at this correctly.

Thank you!


Mark D. Theis

Southern California Telephone and Energy

Office (951) 693-1880 Ext. 212
Fax (951) 693-1550
Cell (951) 545-1013  or (949) 682-VOIP
27515 Enterprise Circle West
Temecula, CA. 92590
[email protected]<mailto:[email protected]?subject=reply%20from%20email%20footer>


_______________________________________________
sipx-users mailing list
[email protected]<mailto:[email protected]>
List Archive: http://list.sipfoundry.org/archive/sipx-users/



--
======================
Tony Graziano, Manager
Telephone: 434.984.8430
sip:
[email protected]<mailto:[email protected]>
Fax: 434.984.8431

Email: [email protected]<mailto:[email protected]>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip:
[email protected]<mailto:[email protected]>
Fax: 434.984.8427

Helpdesk Contract Customers:
http://www.myitdepartment.net/gethelp/

Why do mathematicians always confuse Halloween and Christmas?
Because 31 Oct = 25 Dec.
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Reply via email to