[Asterisk-Users] SIP config documentation

[Fran Boon]

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:name at example.com> <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