On Nov 17, 2007 12:47 PM, Matthew Mackes <[EMAIL PROTECTED]> wrote: > When using SER in front of Asterisk, do you setup your sip profiles for > each phone/ extention in Ser, and then Ser points those extensions to the > correct Asterisk Server?
The users in Asterisk are the same as the users in OpenSER. Let me explain. OpenSER is the registration endpoint. There is a 'subscriber' table that OpenSER reads to check for credentials (authentication). Once the phone registers, it is saved in the 'location' table so when that peer is requested, OpenSER knows where to route the call. Asterisk then uses a table in the database using the realtime driver. The peers are not cached in my setup for a few reasons, of which I won't get into here, but you setup the peers and users (friends) in extconfig.conf to point to the ODBC connector. Both of these "tables" are actually views in PostgreSQL. These views are created from a single user management table in the database which the GUI updates. So when you add a user (or inactivate a user) in that table, it is automatically populated into the views, and both OpenSER and Asterisk are then aware of the change using their respective table formats. Call flow works like this: Uplink provider --> OpenSER --> Asterisk Cluster --> perform dialplan logic --> determine destination --> OpenSER --> End-point The OpenSER listed above is the same box. It's simply the registration endpoint for all the Asterisk boxes in the cluster. OpenSER can send the call to any Asterisk in the cluster, and it won't matter because they all share the same information (same database connection). The dialplan relies very heavily on func_odbc and various other dialplan tools. All virtual PBXs live in the same space, and are distributed across all the Asterisk boxes evenly. There is also DUNDi involved in passing information across the boxes. For example, you can't distribute the Queue() application various Asterisk boxes, so when a Queue() or MeetMe() room is created for the first time, then one of the Asterisk systems instantiates the application, then advertises that to the other boxes. When a call comes in to one of the other boxes and requests the same MeetMe() or Queue(), then it does a lookup via DUNDi and redirects the call to the box hosting it. You could add more complex (or simple, depending how you want to look at it) logic that would use 1, or a group of dedicated "conference" boxes, but that is really just an organizational decision. My approach actually ends up being more complex dialplan wise, but with the size of installation (2 DB, 2 OpenSER (1 master, 1 live standby with HA), and 2 Asterisk boxes), it didn't make sense to have dedicated conferencing/queue boxes. And I liked the challenge to make the entire thing fully distributed. > And, if so, is this so that you can make moves/changes/adds to your > Asterisk systems without re-pointing your phones to a new IP address? We just use the power of the DNS system. We point the phones at a DNS address, then if we need to change the IP address for some reason, then we just change the DNS entry, and everything (eventually) updates itself. With HA, you actually share a 'virtual' IP address (which must actually a real IP address on the Internet), then the two boxes ping each other, and when one goes down, the other one takes over that IP address. The phones don't really even know anything happened -- worst case scenario, someone has to hit 'redial' on their phone. > I would love to know more about using SER in front of Asterisk. I hear that > if SER is using infront of Asterisk it will handle most internal > Phone-to-Phone traffic, is this true? I don't have it setup like that -- but if OpenSER doesn't have to talk to something behind NAT, then yes -- either that, or from what I've heard, you need to have a local proxy that everything goes through so it can route it inside your internal network. I don't believe it can do it if your company is behind NAT and all the phones are exposed as only a single IP address. -- Leif Madsen. http://www.leifmadsen.com http://www.oreilly.com/catalog/asterisk --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
