Via AGI
$ResponseCode = $agi->get_variable(‘MASTER_CHANNEL(HASH(SIP_CAUSE,${CDR(dstchannel)}))’,‘true’);
OR
Via Dial Plan
Set(ResponseCode=${MASTER_CHANNEL(HASH(SIP_CAUSE,${CDR(dstchannel)}))});
The problem is this is NOT working with a VoIP provider that uses re invite on all calls that I send to them. Other VoIP providers it is working fine, but this one provider that uses re invite it is constantly returning 302 (re invite code) when numbers are actually 404 Not Found.
If I dial via Softphone (SJ Phone) it shows the correct 404 Not Found on the message popup mesage on my computer (SJ Phone popup), however I can not work out how to get that in the dial plan or in my AGI files.
I suspect that Asterisk is then failing to find the new target extension. In that case, 302 IS the SIP response code, and the subsequent not found is an internal, Asterisk, non-SIP event. In that case, you need to read ${HANGUPCAUSE}, which uses ISDN cause codes, not SIP ones, or you want to re-interpret 302 as not found.
I found this: voip-info.org/wiki/view/Aste … angupcause
ISUP Cause value SIP response:
1 unallocated number 404 Not Found
2 no route to network 404 Not found
3 no route to destination 404 Not found
16 normal call clearing — (*)
17 user busy 486 Busy here
18 no user responding 408 Request Timeout
19 no answer from the user 480 Temporarily unavailable
20 subscriber absent 480 Temporarily unavailable
21 call rejected 403 Forbidden (+)
22 number changed (w/o diagnostic) 410 Gone
22 number changed (w/ diagnostic) 301 Moved Permanently
23 redirection to new destination 410 Gone
26 non-selected user clearing 404 Not Found (=)
27 destination out of order 502 Bad Gateway
28 address incomplete 484 Address incomplete
29 facility rejected 501 Not implemented
31 normal unspecified 480 Temporarily unavailable
I am now getting code 17 for busy numbers, and 1 for disconnected numbers.
en.wikipedia.org/wiki/List_of_SIP_response_codes
Besides the SIP Response code list being 10 times as long, and maybe giving a better idea as to call outcome in some situations this there any reason why one would not really just use this ${HANGUPCAUSE} method which seems to work with redirect where the other method does not.
Just saying if there is any reason why I should not just use this for my system programming or is there some other good reason why not to do that?
Hangup cause provides standard codes across all channel types, but has to be translated too and from SIP cause codes when using SIP. That loses some information and some people want that information.