Hi Michael, Thanks for the response. I am sending the application executions in the sequence in my last mail and have just enabled event lock for the answer and confirmed that this has not made a difference to my call. It sounds like your suggestion of nat auto-correction explains the problem and is not something i had considered although i had realised that a 1 second pause solved the issue. I presume that the record application will only work if the RTP stream is ready when the application starts, and this is the reason why my packet capture contains the audio and the recorded file does not? I have attached a complete debug trace from fs_cli in case it helps to further explain my configuration. Many thanks, Callum ______________________________ Callum Guy Developer X-on Framlingham Technology Centre Station Road, Framlingham, Suffolk, IP13 9EZ T 0333 332 0116 E callum.guy@x-on.co.uk X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD Company Registration No. 2578478 This email has been sent from X-on.The contents and attachments are confidential to the sender and the intended addressees.If the message is received by anyone other than the addressee please return the message to the sender by replying to it and then delete the message from your computer without copying or disclosing the contents to anyone.Opinions, conclusions and statements of intent in this email are those of the sender and do not bind X-on unless confirmed by authorised representatives independently of this message.While best endeavours have been taken to avoid transmission of viruses, it is the responsibility of the recipient to scan for these.Please note emails sent to and from X-on are routinely monitored for record keeping and quality control, to ensure regulatory compliance and prevent unauthorised use of our systems. Please consider the environment before printing this email. On 1 October 2013 16:15, Anthony Minessale <anthony.minessale@gmail.com>wrote:
Are you running the answer application before you call the record app? It appears as you are not as the codec negotiation seems to take place after you call record. Also you are behind nat and you need to wait for the nat auto-correction to trigger before the media stream is correct so the 10ms is not enough. You need to exchange audio for about 1 seconds for it to fix the problem for you. If you fixed the other end to not need server side nat it would also help your issue.
On Tue, Oct 1, 2013 at 10:05 AM, Callum Guy <callum.guy@x-on.co.uk> wrote:
I have just checked and although my test configuration recorded an empty file the packets captured with tcpdump can be successfully played back in Wireshark. The audio in the capture is exactly as I would have expected the recording to be.
Are we suggesting that there is a bug of some description here? Is there anything else I can test to confirm?
To provide some clarity on my setup here is a list of what i have:
1. Registered Linksys SPA941 on OpenSIPS 2. Direct call from OpenSIPS to FreeSWITCH 3. XML dialplan with ESL outbound connection to socket server 4. Socket server issues SendMsg answer 5. Socket server issues SendMsg park 6. Socket client intercepts CHANNEL_PARK 7. Socket client issues SendMsg record (filepath/test.wav 15 200)
______________________________
Callum Guy Developer
X-on Framlingham Technology Centre Station Road, Framlingham, Suffolk, IP13 9EZ
T 0333 332 0116 E callum.guy@x-on.co.uk
X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD Company Registration No. 2578478
This email has been sent from X-on.The contents and attachments are confidential to the sender and the intended addressees.If the message is received by anyone other than the addressee please return the message to the sender by replying to it and then delete the message from your computer without copying or disclosing the contents to anyone.Opinions, conclusions and statements of intent in this email are those of the sender and do not bind X-on unless confirmed by authorised representatives independently of this message.While best endeavours have been taken to avoid transmission of viruses, it is the responsibility of the recipient to scan for these.Please note emails sent to and from X-on are routinely monitored for record keeping and quality control, to ensure regulatory compliance and prevent unauthorised use of our systems. Please consider the environment before printing this email.
On 1 October 2013 15:33, Michael Jerris <mike@jerris.com> wrote:
Your saying you see media flowing in both directions even when the record doesn't work, and when you play the stream in wireshark, there is media in that stream, and its not silent?
On Oct 1, 2013, at 10:23 AM, Callum Guy <callum.guy@x-on.co.uk> wrote:
I'm calling in from a Linksys SPA941 and I will be the only user on the FreeSWITCH server. I have been using tcpdump to capture my RTP traffic using the following command:
tcpdump -i any -n dst portrange 10000-50000
I configured two test scripts as below:
*Script 1: Answer call, generate 1000ms silence (as above) and then record. * This showed a steady stream of UDP data throughout the call and resulted in a recording.
*Script 2: Answer call, sleep for 1 second and then record. * This showed a steady stream of UDP data throughout the call but resulted in a blank recording.
This is interesting and indicates to me that there is probably something that the FreeSWITCH file play operation is doing (even when its a silence stream) that is not carried out by the record application. I would expect that its unusual for a telephony application to want to answer and record without any play operations first.
Thanks again,
Callum
_________________________________________________________________________ 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
_________________________________________________________________________ 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
_________________________________________________________________________ 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