On Sat, 2004-02-21 at 19:30, Costa Tsaousis wrote: > I believe there are three possible paths for asterisk: > 1. Stick to the switched world (as the common denominator for telephony). > This means that * can have any number of gateways on it, but always, it > will be a "switching-like" PBX with some VoIP functionality, build in > software. > Example: forget about SIP, H.323 and the like, focus on switched telephony > with the ability to place and receive calls via VoIP making them as > switching-friendly as possible, of course with limitations. > 2. Open up the possible scenarios and let the administrator choose the > primary protocol. This means that although asterisk will not address in > its core artificially intelligent thinks such as callerid convertion, it > could be configured to follow either schema. In this case, the > administrator should have the means to configure some aspects of the > secondary protocols. > Example: Support a number of protocols as primary and configure asterisk > according to them. This means that various building blocks (like callerid > handling) will be multiplied, one variation per primary protocol and the > whole system will support only one protocol for such functions. When there > are interfaces with other protocols the administrator should make hard > decisions about the properties that cannot be converted automatically. > This is my case today. I want SIP as primary and I know I will have to > provide numeric callerids in the configuration when interfacing with other > protocols. What I need is a SIP PBX and IVR, not a SIP proxy. I cannot do > what I need with SER (at least not that easy...).
This is also my situation. > 3. Build asterisk as a superset of all protocols, internally. In our case > this could mean that the callerid could be defined as: > callerid=TEXT <internet address> <number> > or even: > callerid=Your Name <sip:[EMAIL PROTECTED]> <h323:...> <mgcp:...> > or just provide directory services for callerid convertions between non > compatible protocols. > As a superset of all protocols, asterisk will be able to be a fully > functional member of each of the supported worlds and will be able to also > handle all the protocols as primary at the same time. > Path 3 is the perfect path. Path 2 is a good one. Path 1 demotes asterisk. > If it is going to be Path 1 I believe we, all, are going to use asterisk > as a secondary component in our telephony infrastructures that will > provide some valuable services, but it will never be the heart of it, > unless all that we need is a plain old switched-like PBX with some VoIP > functionality. I agree that these are the possible paths & would personally be quite happy with (2) if the incompatibilities are well-documented. > > We need to work together to handle the multi-domain scenario. Please > > send me whatever you have and let's continue discussing this so we get > > a solid architecture. I do want Asterisk to be in the forefront in > > preventing > > use of Asterisk as a open SIP spam relay to use mail terms. Mail servers > > are > > picky of which domains they server for inbound and outbound messages, in > > some > > cases also on what domain is used for outbound messages. We need to have > > configuration that follows this line of thinking for SIP. If someone is > > using > > our domain for outbound calls - authenticate. If someone is randomly > > placing > > calls to extensions in any domain they invent *into* our PBX, don't > > answer. > I agree with you, but still I think all these should be configuration > decisions, not implementation ones. Yes, of course - in a purely internal network, you may legitimately wish to run an open relay. However, the default settings (*.conf.sample) should be configured safely if at all possible... F _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
