Sias Mey
2012-09-07 08:39:37 UTC
Hi, Im sure this subject has been beaten to death .. but many googles and many email searches hasent really managed to find me something.
Im a dev for a small company that writes call center software. Freeswitch was a godsend, thank you.
Now .. the confusion.
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.
from xmlcdr.
<sip_hangup_disposition>recv_refuse</sip_hangup_disposition>
<sip_term_status>408</sip_term_status>
<proto_specific_hangup_cause>sip%3A408</proto_specific_hangup_cause>
<sip_term_cause>102</sip_term_cause>
<hangup_cause>RECOVERY_ON_TIMER_EXPIRE</hangup_cause>
<hangup_cause_q850>102</hangup_cause_q850>
this just to show its the same call
<sip_call_id>0d4d4e76-735a-1230-d2ac-000423b5571b</sip_call_id>
and from the sip messages.
SIP/2.0 408 Request Timeout
Call-ID: 0d4d4e76-735a-1230-d2ac-000423b5571b
Reason: Q.850;cause=18;text="no user responding"
And according to the very useful wiki page on Q.850 codes 408 should = 18 like it does in the providers response.
Why then is the q850 hangup cause in the CDR 102? and where does that translation come from.
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.
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?
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.
Thank you for your time and help,
Regards
Sias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: calltrace.pcap
Type: application/vnd.tcpdump.pcap
Size: 2390 bytes
Desc: not available
Url : http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20120907/251ba836/attachment.bin
Im a dev for a small company that writes call center software. Freeswitch was a godsend, thank you.
Now .. the confusion.
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.
from xmlcdr.
<sip_hangup_disposition>recv_refuse</sip_hangup_disposition>
<sip_term_status>408</sip_term_status>
<proto_specific_hangup_cause>sip%3A408</proto_specific_hangup_cause>
<sip_term_cause>102</sip_term_cause>
<hangup_cause>RECOVERY_ON_TIMER_EXPIRE</hangup_cause>
<hangup_cause_q850>102</hangup_cause_q850>
this just to show its the same call
<sip_call_id>0d4d4e76-735a-1230-d2ac-000423b5571b</sip_call_id>
and from the sip messages.
SIP/2.0 408 Request Timeout
Call-ID: 0d4d4e76-735a-1230-d2ac-000423b5571b
Reason: Q.850;cause=18;text="no user responding"
And according to the very useful wiki page on Q.850 codes 408 should = 18 like it does in the providers response.
Why then is the q850 hangup cause in the CDR 102? and where does that translation come from.
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.
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?
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.
Thank you for your time and help,
Regards
Sias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: calltrace.pcap
Type: application/vnd.tcpdump.pcap
Size: 2390 bytes
Desc: not available
Url : http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20120907/251ba836/attachment.bin