> Well, unfortunately for you, that is the exact opposite of > the philosophy of the Asterisk codebase. Every attempt is > made to genericize the channel driver interface so that you > do not need to know the details of the underlying driver. > Where we have failed to do so in the past, we are attempting > to rectify in current approaches. > > The only place where it is reasonable to customize is in the > specification of the channel in the configuration file. That > is where you would customize, for example, whether DTMF is > inband, SIP INFO, or RFC 2833, as well as what codecs will be > negotiated for that particular user/peer. >
But you already have the SIP_HEADER function, which is quite contradictory to what you say. This allows users who know what they are doing to examine headers directly. We use this a lot. What would be the harm in having a SIP_RESPONSE function or something alike? It would allow for those who want to have this information to get it and act accordingly in the dialplan. I know I have missed this possibility, and instead tried to puzzle together information from DIAL_STATUS and HANGUP_CAUSE. I do agree with the general assumption that the dialplan should be generic, but in reality this is often not the case. You add a SIP-header to tell the client to auto-answer or to change the ring tone, or something like that. I guess that there are similiar ways customize things in IAX or ZAP, and thereby making the dialplans not so generic. Our dialplans often depend heavliy on SIP, but that is of course a result of us working in a SIP-only environment. // T _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
