I think our wiki is less accurate than our code:  Our cause mappings are straight from RFC 4497 <a href="http://tools.ietf.org/html/rfc4497">http://tools.ietf.org/html/rfc4497</a><br><br>Here is an excerpt:<br><br><pre class="newpage" style="font-size:1em;margin-top:0px;margin-bottom:0px">
 408 Request timeout                 102 Recovery on timer expiry</pre><pre class="newpage" style="font-size:1em;margin-top:0px;margin-bottom:0px"> 504 Gateway time-out                102 Recovery on timer expiry</pre><pre class="newpage" style="font-size:1em;margin-top:0px;margin-bottom:0px">
<br></pre><pre class="newpage" style="font-size:1em;margin-top:0px;margin-bottom:0px"><br></pre><br><br><div class="gmail_quote">On Fri, Sep 7, 2012 at 3:39 AM, Sias Mey <span dir="ltr">&lt;<a href="mailto:sias@cpdata.co.za" target="_blank">sias@cpdata.co.za</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, Im sure this subject has been beaten to death .. but many googles and many email searches hasent really managed to find me something.<br>

<br>
Im a dev for a small company that writes call center software. Freeswitch was a godsend, thank you.<br>
<br>
Now .. the confusion.<br>
<br>
We are getting a lot of what seem to be strange hangup codes from a new provider big fights about loads of failled calls ensued blah blah.. much sip packet logging and manual inspection later.. I found the following.<br>

<br>
from xmlcdr.<br>
<br>
<br>
    &lt;sip_hangup_disposition&gt;recv_refuse&lt;/sip_hangup_disposition&gt;<br>
    &lt;sip_term_status&gt;408&lt;/sip_term_status&gt;<br>
    &lt;proto_specific_hangup_cause&gt;sip%3A408&lt;/proto_specific_hangup_cause&gt;<br>
    &lt;sip_term_cause&gt;102&lt;/sip_term_cause&gt;<br>
    &lt;hangup_cause&gt;RECOVERY_ON_TIMER_EXPIRE&lt;/hangup_cause&gt;<br>
    &lt;hangup_cause_q850&gt;102&lt;/hangup_cause_q850&gt;<br>
<br>
this just to show its the same call<br>
    &lt;sip_call_id&gt;0d4d4e76-735a-1230-d2ac-000423b5571b&lt;/sip_call_id&gt;<br>
<br>
and from the sip messages.<br>
<br>
SIP/2.0 408 Request Timeout<br>
Call-ID: 0d4d4e76-735a-1230-d2ac-000423b5571b<br>
Reason: Q.850;cause=18;text=&quot;no user responding&quot;<br>
<br>
And according to the very useful wiki page on Q.850 codes 408 should = 18 like it does in the providers response.<br>
<br>
Why then is the q850 hangup cause in the CDR 102? and where does that translation come from.<br>
<br>
This is a single example but I also have loads and loads where the CDR claims q850 code 18 but the sip messages provide 31 or a range of other codes.<br>
I can understand if the q850 code from the sip message is not being read by FS since FS has to be a bit more agnostic than that and in the pas I have almost exclusively worked with direct connections to TDM hardware so my knowledge and understanding of the sip messages is rather limited. But even in that case, shouldent the q850 code in the cdr at least conform to the translation from the wiki page?<br>

<br>
Oh I am not currently running the latest git release, having some libtiff issues on ubuntu to compile. I will respond to this again if I manage that and it helps matters.<br>
<br>
Thank you for your time and help,<br>
Regards<br>
<span class="HOEnZb"><font color="#888888">Sias<br>
</font></span><br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
Twitter: <a href="http://twitter.com/FreeSWITCH_wire">http://twitter.com/FreeSWITCH_wire</a><br><br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:+19193869900<br>