mod_xml_cdr not saving file correctly -- PLease help
I posted recently but my description may have been to complex for others to replicate, so I have boiled the problem down to the simplest of configurations and still need some help Running version is FreeSWITCH Version 1.0.head (git-f25c5aa 2012-01-29 17-37-56 -0600) Calls are answered with a LUA script that has been working well on another server 1) any call coming in on a softphone (with caller id of 1000) that is registered to the server will post to url and save correctly to the log directory 2)Calls with a 10 digit US caller_id coming in on public dialplan to same script receive an error 500 when posting the cdr using mod_xml_cdr and post a garbled file in the errors directory (see below) 3) calls coming in on public dialplan with a UK caller id post to url and save correctly encode is set to true in the mod_xml conf file It appears that there may be 2 issues here 1) mod_xml_cdr (with encode=true) is trying to send file (and save in error log with bad formatting) 2) when it writes the file to the main log directory it is saved correctly I end up with a failed post and 2 cdr's that are saved differently. see examples below THIS IS THE FILE IN THE MAIN LOG DIRECTORY /usr/local/freeswitch/log/xml_cdr/a_f4eb00ab-a364-4c95-a86d-df6eafa3bf98.cdr.xml <?xml version="1.0"?> <cdr> <channel_data> <state>CS_REPORTING</state> <direction>inbound</direction> <state_number>11</state_number> <flags>0=1;1=1;35=1;36=1;38=1;41=1;51=1</flags> <caps>1=1;2=1;3=1;4=1;5=1;6=1</caps> </channel_data> <variables> <direction>inbound</direction> <uuid>f4eb00ab-a364-4c95-a86d-df6eafa3bf98</uuid> AND THIS IS THEY WAY THE FILE IS SAVED IN THE ERROR LOG %3C%3Fxml%20version%3D%221.0%22%3F%3E%0A%3Ccdr%3E%0A%20%20%3Cchannel_data%3E%0A%20%20%20%20%3Cstate%3ECS_REPORTING%3C/state%3E%0A%20%20%20%20%3Cdirection%3Einbound%3C/direction%3E%0A%20%20%20%20%3Cstate_number%3E11%3C/state_number%3E%0A%20%20%20%20%3Cflags%3E0%3D1%3B1%3D1%3B35%3D1%3B36%3D1%3B38%3D1%3B41%3D1%3B51%3D1%3C/flags%3E%0A%20%20%20%20%3Ccaps%3E1%3D1%3B2%3D1%3B3%3D1%3B4%3D1%3B5%3D1%3B6%3D1%3C/caps%3E%0A%20%20%3C/channel_data%3E%0A%20%20%3Cvariables%3E%0A%20%20%20%20%3Cdirection%3Einbound%3C/direction%3E%0A%20%20%20%20%3Cuuid%3Ef4eb00ab-a364-4c95-a86d-df6eafa3bf98%3C/uuid%3E%0A%20%20%20%20%3Csession_id%3E6%3C/session_id%3E%0A%20%20%20%20%3Csip_local_network_addr%3E192.168.100.82%3C/sip_local_network_addr%3E%0A%20%20%20%20%3Csip_network_ip%3E72.249.14.242%3C/sip_network_ip%3E%0A%20%20%20%20%3Csip_network_port%3E5060%3C/sip_network_port%3E%0A%20%20%20%20%3Csip_received_ip%3E72.249.14.242%3C/sip_received_ip%3E%0A%20%20%20%20%3Csip_received_port%3E5060%3C/sip_received_port%3E%0A%20%20%20%20%3Csip_via_protocol%3Eudp%3C/sip_via_protocol%3E%0A%20%20%20%20%3Csip_from_user%3E4088924027%3C/sip_from_user%3E%0A%20%20%20%20%3Csip_from_uri%3E4088924027%254072.249.14.242%3C/sip_from_uri%3E%0A%20%20%20%20%3Csip_from_host%3E72.249.14.242%3C/sip_from_host%3E%0A%20%20%20%20%3Csip_from_user_stripped%3E4088924027%3C/sip_from_user_stripped%3E%0A%20%20%20%20%3Csofia_profile_name%3Eexternal%3C/sofia_profile_name%3E%0A%20%20%20%20%3Csip_req_user%3E8132007296%3C/sip_req_user%3E%0A%20%20%20%20%3Csip_req_port%3E5080%3C/sip_req_port%3E%0A%20%20%20%20%3Csip_req_uri%3E8132007296%2540192.168.100.82%253A5080%3C/sip_req_uri%3E%0A%20%20%20%20%3Csip_req_host%3E192.168.100.82%3C/sip_req_host%3E%0A%20%20%20%20%3Csip_to_user%3E8132007296%3C/sip_to_user%3E%0A%20%20%20%20%3Csip_to_port%3E5080%3C/sip_to_port%3E%0A%20%20%20%20%3Csip_to_uri%3E8132007296%2540192.168.100.82%253A5080%3C/sip_to_uri%3E%0A%20%20%20%20%3Csip_to_host%3E192.168.100.82%3C/sip_to_host%3E%0A%20%20%20%20%3Csip_contact_user%3E4088924027%3C/sip_contact_user%3E%0A%20%20%20%20%3Csip_contact_uri%3E4088924027%254072.249.14.242%3C/sip_contact_uri%3E%0A%20%20%20%20%3Csip_contact_host%3E72.249.14.242%3C/sip_contact_host%3E%0A%20%20%20%20% -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/mod-xml-cdr-not-saving-file-co... Sent from the freeswitch-users mailing list archive at Nabble.com.
have you looked in the error log of the web server or checked the cgi handler to see what the problem is? The data you pasted looks identical to me. The encoded format is urlencoded: See this command like that decodes it: echo "%3C%3Fxml%20version%3D%221.0%22%3F%3E%0A%3Ccdr%3E%0A%20%20%3Cchannel_data%3E%0A%20%20%20%20%3Cstate%3ECS_REPORTING%3C/state%3E%0A%20%20%20%20%3Cdirection%3Einbound%3C/direction%3E%0A%20%20%20%20%3Cstate_number%3E11%3C/state_number%3E%0A%20%20%20%20%3Cflags%3E0%3D1%3B1%3D1%3B35%3D1%3B36%3D1%3B38%3D1%3B41%3D1%3B51%3D1%3C/flags%3E%0A%20%20%20%20%3Ccaps%3E1%3D1%3B2%3D1%3B3%3D1%3B4%3D1%3B5%3D1%3B6%3D1%3C/caps%3E%0A%20%20%3C/channel_data%3E%0A%20%20%3Cvariables%3E%0A%20%20%20%20%3Cdirection%3Einbound%3C/direction%3E%0A%20%20%20%20%3Cuuid%3Ef4eb00ab-a364-4c95-a86d-df6eafa3bf98%3C/uuid%3E%0A%20%20%20%20%3Csession_id%3E6%3C/session_id%3E%0A%20%20%20%20%3Csip_local_network_addr%3E192.168.100.82%3C/sip_local_network_addr%3E%0A%20%20%20%20%3Csip_network_ip%3E72.249.14.242%3C/sip_network_ip%3E%0A%20%20%20%20%3Csip_network_port%3E5060%3C/sip_network_port%3E%0A%20%20%20%20%3Csip_received_ip%3E72.249.14.242%3C/sip_received_ip%3E%0A%20%20%20%20%3Csip_received_port%3E5060%3C/sip_received_port%3E%0A%20%20%20%20%3Csip_via_protocol%3Eudp%3C/sip_via_protocol%3E%0A%20%20%20%20%3Csip_from_user%3E4088924027%3C/sip_from_user%3E%0A%20%20%20%20%3Csip_from_uri%3E4088924027%254072.249.14.242%3C/sip_from_uri%3E%0A%20%20%20%20%3Csip_from_host%3E72.249.14.242%3C/sip_from_host%3E%0A%20%20%20%20%3Csip_from_user_stripped%3E4088924027%3C/sip_from_user_stripped%3E%0A%20%20%20%20%3Csofia_profile_name%3Eexternal%3C/sofia_profile_name%3E%0A%20%20%20%20%3Csip_req_user%3E8132007296%3C/sip_req_user%3E%0A%20%20%20%20%3Csip_req_port%3E5080%3C/sip_req_port%3E%0A%20%20%20%20%3Csip_req_uri%3E8132007296%2540192.168.100.82%253A5080%3C/sip_req_uri%3E%0A%20%20%20%20%3Csip_req_host%3E192.168.100.82%3C/sip_req_host%3E%0A%20%20%20%20%3Csip_to_user%3E8132007296%3C/sip_to_user%3E%0A%20%20%20%20%3Csip_to_port%3E5080%3C/sip_to_port%3E%0A%20%20%20%20%3Csip_to_uri%3E8132007296%2540192.168.100.82%253A5080%3C/sip_to_uri%3E%0A%20%20%20%20%3Csip_to_host%3E192.168.100.82%3C/sip_to_host%3E%0A%20%20%20%20%3Csip_contact_user%3E4088924027%3C/sip_contact_user%3E%0A%20%20%20%20%3Csip_contact_uri%3E4088924027%254072.249.14.242%3C/sip_contact_uri%3E%0A%20%20%20%20%3Csip_contact_host%3E72.249.14.242%3C/sip_contact_host%3E%0A%20%20%20%20%" | perl -ne 's/%(..)/chr hex $1/eg; print ' <?xml version="1.0"?> <cdr> <channel_data> <state>CS_REPORTING</state> <direction>inbound</direction> <state_number>11</state_number> <flags>0=1;1=1;35=1;36=1;38=1;41=1;51=1</flags> <caps>1=1;2=1;3=1;4=1;5=1;6=1</caps> </channel_data> <variables> <direction>inbound</direction> <uuid>f4eb00ab-a364-4c95-a86d-df6eafa3bf98</uuid> <session_id>6</session_id> <sip_local_network_addr>192.168.100.82</sip_local_network_addr> <sip_network_ip>72.249.14.242</sip_network_ip> <sip_network_port>5060</sip_network_port> <sip_received_ip>72.249.14.242</sip_received_ip> <sip_received_port>5060</sip_received_port> <sip_via_protocol>udp</sip_via_protocol> <sip_from_user>4088924027</sip_from_user> <sip_from_uri>4088924027%4072.249.14.242</sip_from_uri> <sip_from_host>72.249.14.242</sip_from_host> <sip_from_user_stripped>4088924027</sip_from_user_stripped> <sofia_profile_name>external</sofia_profile_name> <sip_req_user>8132007296</sip_req_user> <sip_req_port>5080</sip_req_port> <sip_req_uri>8132007296%40192.168.100.82%3A5080</sip_req_uri> <sip_req_host>192.168.100.82</sip_req_host> <sip_to_user>8132007296</sip_to_user> <sip_to_port>5080</sip_to_port> <sip_to_uri>8132007296%40192.168.100.82%3A5080</sip_to_uri> <sip_to_host>192.168.100.82</sip_to_host> <sip_contact_user>4088924027</sip_contact_user> <sip_contact_uri>4088924027%4072.249.14.242</sip_contact_uri> <sip_contact_host>72.249.14.242</sip_contact_host> % On Mon, Jan 30, 2012 at 2:16 AM, Paul <paul@iamfine.com> wrote:
I posted recently but my description may have been to complex for others to replicate, so I have boiled the problem down to the simplest of configurations and still need some help
Running version is FreeSWITCH Version 1.0.head (git-f25c5aa 2012-01-29 17-37-56 -0600)
Calls are answered with a LUA script that has been working well on another server 1) any call coming in on a softphone (with caller id of 1000) that is registered to the server will post to url and save correctly to the log directory 2)Calls with a 10 digit US caller_id coming in on public dialplan to same script receive an error 500 when posting the cdr using mod_xml_cdr and post a garbled file in the errors directory (see below) 3) calls coming in on public dialplan with a UK caller id post to url and save correctly
encode is set to true in the mod_xml conf file
It appears that there may be 2 issues here 1) mod_xml_cdr (with encode=true) is trying to send file (and save in error log with bad formatting) 2) when it writes the file to the main log directory it is saved correctly
I end up with a failed post and 2 cdr's that are saved differently.
see examples below THIS IS THE FILE IN THE MAIN LOG DIRECTORY /usr/local/freeswitch/log/xml_cdr/a_f4eb00ab-a364-4c95-a86d-df6eafa3bf98.cdr.xml <?xml version="1.0"?> <cdr> <channel_data> <state>CS_REPORTING</state> <direction>inbound</direction> <state_number>11</state_number> <flags>0=1;1=1;35=1;36=1;38=1;41=1;51=1</flags> <caps>1=1;2=1;3=1;4=1;5=1;6=1</caps> </channel_data> <variables> <direction>inbound</direction> <uuid>f4eb00ab-a364-4c95-a86d-df6eafa3bf98</uuid>
AND THIS IS THEY WAY THE FILE IS SAVED IN THE ERROR LOG
%3C%3Fxml%20version%3D%221.0%22%3F%3E%0A%3Ccdr%3E%0A%20%20%3Cchannel_data%3E%0A%20%20%20%20%3Cstate%3ECS_REPORTING%3C/state%3E%0A%20%20%20%20%3Cdirection%3Einbound%3C/direction%3E%0A%20%20%20%20%3Cstate_number%3E11%3C/state_number%3E%0A%20%20%20%20%3Cflags%3E0%3D1%3B1%3D1%3B35%3D1%3B36%3D1%3B38%3D1%3B41%3D1%3B51%3D1%3C/flags%3E%0A%20%20%20%20%3Ccaps%3E1%3D1%3B2%3D1%3B3%3D1%3B4%3D1%3B5%3D1%3B6%3D1%3C/caps%3E%0A%20%20%3C/channel_data%3E%0A%20%20%3Cvariables%3E%0A%20%20%20%20%3Cdirection%3Einbound%3C/direction%3E%0A%20%20%20%20%3Cuuid%3Ef4eb00ab-a364-4c95-a86d-df6eafa3bf98%3C/uuid%3E%0A%20%20%20%20%3Csession_id%3E6%3C/session_id%3E%0A%20%20%20%20%3Csip_local_network_addr%3E192.168.100.82%3C/sip_local_network_addr%3E%0A%20%20%20%20%3Csip_network_ip%3E72.249.14.242%3C/sip_network_ip%3E%0A%20%20%20%20%3Csip_network_port%3E5060%3C/sip_network_port%3E%0A%20%20%20%20%3Csip_received_ip%3E72.249.14.242%3C/sip_received_ip%3E%0A%20%20%20%20%3Csip_received_port%3E5060%3C/sip_received_port%3E%0A%20%20%20%20%3Csip_via_protocol%3Eudp%3C/sip_via_protocol%3E%0A%20%20%20%20%3Csip_from_user%3E4088924027%3C/sip_from_user%3E%0A%20%20%20%20%3Csip_from_uri%3E4088924027%254072.249.14.242%3C/sip_from_uri%3E%0A%20%20%20%20%3Csip_from_host%3E72.249.14.242%3C/sip_from_host%3E%0A%20%20%20%20%3Csip_from_user_stripped%3E4088924027%3C/sip_from_user_stripped%3E%0A%20%20%20%20%3Csofia_profile_name%3Eexternal%3C/sofia_profile_name%3E%0A%20%20%20%20%3Csip_req_user%3E8132007296%3C/sip_req_user%3E%0A%20%20%20%20%3Csip_req_port%3E5080%3C/sip_req_port%3E%0A%20%20%20%20%3Csip_req_uri%3E8132007296%2540192.168.100.82%253A5080%3C/sip_req_uri%3E%0A%20%20%20%20%3Csip_req_host%3E192.168.100.82%3C/sip_req_host%3E%0A%20%20%20%20%3Csip_to_user%3E8132007296%3C/sip_to_user%3E%0A%20%20%20%20%3Csip_to_port%3E5080%3C/sip_to_port%3E%0A%20%20%20%20%3Csip_to_uri%3E8132007296%2540192.168.100.82%253A5080%3C/sip_to_uri%3E%0A%20%20%20%20%3Csip_to_host%3E192.168.100.82%3C/sip_to_host%3E%0A%20%20%20%20%3Csip_contact_user%3E4088924027%3C/sip_contact_user%3E%0A%20%20%20%20%3Csip_contact_uri%3E4088924027%254072.249.14.242%3C/sip_contact_uri%3E%0A%20%20%20%20%3Csip_contact_host%3E72.249.14.242%3C/sip_contact_host%3E%0A%20%20%20%20%
-- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/mod-xml-cdr-not-saving-file-co... Sent from the freeswitch-users mailing list archive at Nabble.com.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
Yes we did check that that receiving web server it confirms that one of the cdr's posts correctly and the other fails with a 500 error This is what we see in CLI - that mod_xml_cdr can post when the call is not a US 10 digit caller id and Fails when it is a 10 digit caller id here are the 2 items from access.log on apache2 and there are no errors in the error.log IP ADDRESS REMOVED - - [30/Jan/2012:18:42:07 +0000] "POST /index.php/fs/cdr_save?uuid=a_325804a1-6703-4566-b0f1-899ea89dd983 HTTP/1.1" 200 609 "-" "freeswitch-xml/1.0" IP ADDRESS REMOVED - - [30/Jan/2012:18:51:12 +0000] "POST /index.php/fs/cdr_save?uuid=a_8525a70a-1674-4bb6-8cf0-07bf2aa37638 HTTP/1.1" 500 2777 "-" "freeswitch-xml/1.0" I ran tcpdump on the incoming server and i see that the data is coming in from freeswitch but in one case it is encoded and the other it is not (i think) -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/mod-xml-cdr-not-saving-file-co... Sent from the freeswitch-users mailing list archive at Nabble.com.
What I was asking, was if you can get more details. a 500 error on your server means your CGI died or errored out. So if you can find the exact error from the webserver error log you can see what happens in the script to make it fail. So you should be concentrating on the web server and CGI not on FS. On Mon, Jan 30, 2012 at 12:54 PM, Paul <paul@iamfine.com> wrote:
Yes we did check that that receiving web server it confirms that one of the cdr's posts correctly and the other fails with a 500 error
This is what we see in CLI - that mod_xml_cdr can post when the call is not a US 10 digit caller id and Fails when it is a 10 digit caller id
here are the 2 items from access.log on apache2 and there are no errors in the error.log
IP ADDRESS REMOVED - - [30/Jan/2012:18:42:07 +0000] "POST /index.php/fs/cdr_save?uuid=a_325804a1-6703-4566-b0f1-899ea89dd983 HTTP/1.1" 200 609 "-" "freeswitch-xml/1.0" IP ADDRESS REMOVED - - [30/Jan/2012:18:51:12 +0000] "POST /index.php/fs/cdr_save?uuid=a_8525a70a-1674-4bb6-8cf0-07bf2aa37638 HTTP/1.1" 500 2777 "-" "freeswitch-xml/1.0"
I ran tcpdump on the incoming server and i see that the data is coming in from freeswitch but in one case it is encoded and the other it is not (i think)
-- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/mod-xml-cdr-not-saving-file-co... Sent from the freeswitch-users mailing list archive at Nabble.com.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
participants (2)
-
Anthony Minessale
-
Paul