Hi.<br>
<br>
I am hopeful that I might be able to engage someones assistance in a testing and debugging effort. <br>
<br>
I have a configuration thus:<br>
<br>
PRI ==> ASTERISK (CVS-D2005.05.19) ==> IAX2 ==> ASTERISK (CVS-HEAD) ==> AMI ==> Dialer application<br>
<br>
The Dialer relies on knowing why a call was hung up. Unfortunately, I
am not seeing much useful information appearing in the IAX2 inbound
stream. <br>
<br>
Inter-Asterisk eXchange v2<br>
Packet type: Full packet (1)<br>
.000 0000 0000 1110 = Source call: 14<br>
.000 0000 0000 0010 = Destination call: 2<br>
0... .... .... .... = Retransmission: False<br>
Timestamp: 1258<br>
Outbound <a href="http://seq.no">seq.no</a>.: 4<br>
Inbound <a href="http://seq.no">seq.no</a>.: 3<br>
Type: IAX (6)<br>
IAX type: HANGUP (5)<br>
Information Element: Hangup cause (0x2A)<br>
IE id: Hangup cause (0x2A)<br>
Length: 1<br>
Hangup cause: Unknown (0x00)<br>
<br>
is the output from Ethereal. <br>
<br>
Evidently, the channel->hangupcause is not being set. <br>
<br>
I have traced through various parts of channel.c, chan_zap.c and
chan_iax2.c and can see various places where the hangupcause appears to
get set, but without a PRI to test with, I am somewhat stumped. <br>
<br>
This is a bit of a showstopper for me unfortunately and I would be very
grateful if someone could assist me with finding the reason why this
hangupcause isn't being set by chan_zap.c and the value finding its way
back into the IAX2 packet.<br>
<br>I am starting to form an opinion that this might be a mismatch
between versions of Asterisk and would be grateful if someone could
assist me in my investigations by helping me understand the typical
sequence of events in a PRI and in chan_zap.c when an Unobtainable or
Busy number is called. This would greatly help me determine if for some
reason the hangupcause is not being set by chan_zap in the asterisk
channel structure.<br>
<br>
cheers,<br>
<br>
Mark.<br>