Ken,
Well basically, in the TDM world, you usually order one or several lines.One analog line can't support DIDs (except in the US where they have/used to have a such product).
Nowadays, as you know, ISDN is the right choice when you need DIDs.
Physically, a DID on ISDN is just that a different number (DNIS) is sent in the called number field of the Q931 packet, as 4 digits or the whole number, depending on the specific ISDN protocol used and on the telco.
In the SIP world, there is only one protocol: SIP.
Even if sometimes you feel that there are different type of SIP accounts, they are actually all the same.
You can have a SIP account allowing 1 call with one number (generally, they don't allow to send a custom outbound caller-id).
But a SIP account can also be used to provide a SIP trunk allowing 200 calls and 2000 DIDs (on those, you can obviously send a custom outbound caller-id, but it can still be restricted to be one of your 2000 DIDs, or not restricted. It depends on the kind of contract you have with the carrier, wholesale vs business).
Account, trunk, what's the difference ?
Technically, there is none, but let's say a trunk is generally a SIP account (but it can also be a raw SIP trunk without authentication) with several DIDs.
If you only have one DID on the SIP account, it's not really meaningful to call that a trunk.
On a SIP trunk, a DID is just sent as the dialed number, generally in the INVITE To and/or Request-Line fields.
It's pretty much the same than ISDN.
The main differences are:
-in SIP, a DID is far more decorrelated from the physical media (you can have a SIP account without any DID, so you won't be reachable)
-in SIP, a DID could be anything, not just a phone number, but because most of the traffic comes from the PSTN and regular phones, we mainly use digits at the moment.
So in SIP, when you have 6 SIP accounts, each other with a different DID, you may replace that with one SIP account (SIP trunk) with the 6 DIDs routed on it by the carrier.
I think it's easier to manage.
Then in FreeSWITCH, as you won't be able to distinguish by the SIP account receiving the call (you can bind a SIP account to a specific context/dialplan in FS), you'll have to distinguish by the called-number in a common dialplan, which is very easy.
I hope I did not confuse you more :)
David Ponzone Direction Technique
tel: 01 74 03 18 97
gsm: 06 66 98 76 34
Service Client IPeva
tel: 0811 46 26 26
Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur.
Le 25/08/2010 à 11:46, Ken Gillett a écrit :
On 24 Aug 2010, at 15:26, Tim St. Pierre wrote:
This can be very important when each SIP account represents a different company/business. Although one person is dealing with all those businesses, when an outgoing call is made it is imperative that the correct SIP account is used to make that call so that the recipient is correctly informed who is making the call.
So really, your issue is with presented identity in terms of caller ID name and number then?
Yes, that's about it.
Can you set outgoing caller ID name nad number on the 6 provider accounts?
Only the name. Each account has the outgoing number set by the provider (not unreasonable).
If you can, you may have some better options.
On our platform, we use the dialplan to route all calls to the most appropriate provider, based on
the number that was dialed, and what the rates are for each carrier in a given area (least cost
routing), although reliability in certain areas is also factored.
Each extension registers with a single registration, and has it's own internal caller ID name and
number (the user's name and extension).
We use the Aastra phones, and built a little XML app that lets the user pick from a list of possible
caller ID name and number combinations. This tool updates the database value that will be used for
effective_caller_id name and number. With this setup, one user (one SIP registration) can have an
unlimited number "businesses". For incoming calls, we prefix the caller ID name with a short string
that identifies the incoming number or "business". Sometimes, a combination of registrations and
the selector tool is best. If you don't have XML browsers on the phone, you could just as easily do
this with an IVR tool, a web page, or with prefixes. Whatever is easiest. You can have more than
one option.
This is all helpful info, thanks.
If your upstream providers can give you DID numbers, you can have more than one business on the same
provider account, which is a lot easier to manage (one gateway entry, but lots of "lines").
I still don't fully grasp DID with VOIP. Some years ago I had a company with a call centre that used a PBX over ISDN30 and I did a lot of the configuration myself so I am familiar with most PBX concepts. But not all of it is directly applicable to VOIP which itself can be handled in many different ways. So what I am trying to do is apply my previous PBX knowledge to what I now know about SIP and VOIP in general and in particular how I can best make use of FreeSwitch to do what I want.
So where does DID fit into the VOIP world? Having separate SIP accounts, one for each 'business', each with its own number seems to provide all that DID did (I had to say that:-), but I know my (and other) provider offers 'aliases' which can be used for DID, but I don't fully grasp how this is different from simply different accounts. Maybe in SIP terms it isn't. But if someone cares to enlighten me on this issue, I'm all ears.
This is getting into serious PBX stuff though, and I get the impression you don't really want a PBX.
Or do you?
Oh yes indeed. But I am still in a learning process and asking questions is how I learn. My own current requirements are relatively simple, but I need to understand the greater picture and be able to make it work for more complex scenarios. First step though is to configure it for my own use.
Ken G i l l e t t
_/_/_/_/_/_/_/_/
_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org