[asterisk-users] Getting SIP Response Code from HANGUPCAUSE

[Tilghman Lesher]

On Saturday 27 October 2007 08:14:05 Torbjörn Abrahamsson wrote:
> > 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

If you read all of what I said, you'd see that it's not contradictory at all.
I said that there are places where we've failed to maintain that segregation
and that we're working to rectify that, where possible.

> 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.

Not all of us are working in a SIP-only environment.

-- 
Tilghman