RTP Audio Stream Initialise
I am trying to understand how audio streams are initialised in FreeSWITCH. I'm working with ESL (inbound and outbound) and trying to record some audio. Through testing i have proven that audio is working correctly for bridged calls, conferences and file playback however not for single legged audio recording - that is, until I play a file first. In my example the playback application is executed from an outbound socket, the call is then parked and the inbound socket captures the park event and starts recording. With the playback in place i get audio, and without it I simply get a silent file of the correct duration presumably meaning that the the RTP stream is not active. My question therefore is: How can I initialise the RTP stream for recording, without having played a file first? Is there a command for this, or an argument I can pass to the record application? My objective is to understand how RTP streams are initialised in FreeSWITCH and any input would be greatly appreciated.
On Oct 1, 2013, at 5:51 AM, Callum Guy <callum.guy@x-on.co.uk> wrote:
I am trying to understand how audio streams are initialised in FreeSWITCH. I'm working with ESL (inbound and outbound) and trying to record some audio. Through testing i have proven that audio is working correctly for bridged calls, conferences and file playback however not for single legged audio recording - that is, until I play a file first.
In my example the playback application is executed from an outbound socket, the call is then parked and the inbound socket captures the park event and starts recording. With the playback in place i get audio, and without it I simply get a silent file of the correct duration presumably meaning that the the RTP stream is not active.
You can try a brief silence_stream at the start of the call to address this.
My question therefore is: How can I initialise the RTP stream for recording, without having played a file first? Is there a command for this, or an argument I can pass to the record application?
FreeSWITCH already does this, its likely whatever your talking to does not. What is on the other end of the call.
My objective is to understand how RTP streams are initialised in FreeSWITCH and any input would be greatly appreciated.
Hi Michael, Thanks you for your input. I can confirm that inserting a silence stream prior to the recording works in the same way that playing some actual audio does, resulting in a successful recording. Worth noting is that there appears to be a duration threshold where if the duration is too short (in my case <100ms) then the recording come out blank - presumably this is because the stream has not had enough time to prepare the channel before recording starts. In response to your question the call is a remotely registered VOIP handset (OpenSIPS) dialling directly into FreeSWITCH with all call control handled by ESL. When I stated "initialise the RTP stream for recording" that is my way of trying to communicate that its my understanding that this is what playing the audio file (or silence stream following your comment) was performing in FreeSWITCH. I feel that you have answered my question however i wanted to post some fs_cli output to confirm that this is expected behaviour (or something I should learn to expect!). The lines in red are what i have called "RTP stream initialise". *Call with a silence stream (This records successfully)* 2013-10-01 15:10:35.830044 [DEBUG] switch_ivr.c:612 sofia/internal/ 3333320116@x-onsip.com Command Execute playback(silence_stream://1000) EXECUTE sofia/internal/3333320116@x-onsip.complayback(silence_stream://1000) 2013-10-01 15:10:35.830044 [DEBUG] switch_ivr_play_say.c:1308 Codec Activated L16@8000hz 1 channels 20ms 2013-10-01 15:10:35.860032 [DEBUG] switch_core_session.c:998 Send signal sofia/internal/3333320116@x-onsip.com [BREAK] 2013-10-01 15:10:35.860032 [DEBUG] switch_core_session.c:998 Send signal sofia/internal/3333320116@x-onsip.com [BREAK] 2013-10-01 15:10:35.860032 [DEBUG] switch_core_session.c:998 Send signal sofia/internal/3333320116@x-onsip.com [BREAK] 2013-10-01 15:10:35.880047 [DEBUG] switch_rtp.c:3704 Correct ip/port confirmed. 2013-10-01 15:10:35.880047 [DEBUG] sofia.c:5685 Channel sofia/internal/ 3333320116@x-onsip.com entering state [ready][200] 2013-10-01 15:10:36.820081 [DEBUG] switch_ivr_play_say.c:1693 done playing file silence_stream://1000 2013-10-01 15:10:36.820081 [DEBUG] switch_ivr.c:612 sofia/internal/ 3333320116@x-onsip.com Command Execute record(/usr/share/sounds/recordings/test.wav 10 200) EXECUTE sofia/internal/3333320116@x-onsip.comrecord(/usr/share/sounds/recordings/test.wav 10 200) 2013-10-01 15:10:36.820081 [DEBUG] switch_ivr_play_say.c:599 Raw Codec Activated 2013-10-01 15:10:36.820081 [DEBUG] switch_core_codec.c:219 sofia/internal/ 3333320116@x-onsip.com Push codec L16:70 2013-10-01 15:10:39.920081 [DEBUG] switch_core_session.c:998 Send signal sofia/internal/3333320116@x-onsip.com [BREAK] 2013-10-01 15:10:39.940081 [NOTICE] sofia.c:716 Hangup sofia/internal/ 3333320116@x-onsip.com [CS_EXECUTE] [NORMAL_CLEARING] *Call without a silence stream (This records silence)* 2013-10-01 15:13:06.660045 [DEBUG] switch_ivr.c:612 sofia/internal/ 3333320116@x-onsip.com Command Execute playback(silence_stream://10) EXECUTE sofia/internal/3333320116@x-onsip.com playback(silence_stream://10) 2013-10-01 15:13:06.660045 [DEBUG] switch_ivr_play_say.c:1308 Codec Activated L16@8000hz 1 channels 20ms 2013-10-01 15:13:06.680011 [DEBUG] switch_ivr_play_say.c:1693 done playing file silence_stream://10 2013-10-01 15:13:06.680011 [DEBUG] switch_ivr.c:612 sofia/internal/ 3333320116@x-onsip.com Command Execute record(/usr/share/sounds/recordings/test.wav 10 200) EXECUTE sofia/internal/3333320116@x-onsip.comrecord(/usr/share/sounds/recordings/test.wav 10 200) 2013-10-01 15:13:06.680011 [DEBUG] switch_ivr_play_say.c:599 Raw Codec Activated 2013-10-01 15:13:06.680011 [DEBUG] switch_core_codec.c:219 sofia/internal/ 3333320116@x-onsip.com Push codec L16:70 2013-10-01 15:13:06.760081 [DEBUG] switch_core_session.c:998 Send signal sofia/internal/3333320116@x-onsip.com [BREAK] 2013-10-01 15:13:06.760081 [DEBUG] switch_core_session.c:998 Send signal sofia/internal/3333320116@x-onsip.com [BREAK] 2013-10-01 15:13:06.760081 [DEBUG] switch_core_session.c:998 Send signal sofia/internal/3333320116@x-onsip.com [BREAK] 2013-10-01 15:13:06.780071 [DEBUG] switch_rtp.c:3704 Correct ip/port confirmed. 2013-10-01 15:13:06.780071 [DEBUG] sofia.c:5685 Channel sofia/internal/ 3333320116@x-onsip.com entering state [ready][200] 2013-10-01 15:13:09.680081 [DEBUG] switch_core_codec.c:244 sofia/internal/ 3333320116@x-onsip.com Restore previous codec PCMA:8. 2013-10-01 15:13:09.680081 [DEBUG] switch_ivr.c:612 sofia/internal/ 3333320116@x-onsip.com Command Execute park() Please do let me know if there is anything interesting about the output i am seeing above or that i should apply caution to! 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 13:21, Michael Jerris <mike@jerris.com> wrote:
On Oct 1, 2013, at 5:51 AM, Callum Guy <callum.guy@x-on.co.uk> wrote:
I am trying to understand how audio streams are initialised in FreeSWITCH. I'm working with ESL (inbound and outbound) and trying to record some audio. Through testing i have proven that audio is working correctly for bridged calls, conferences and file playback however not for single legged audio recording - that is, until I play a file first.
In my example the playback application is executed from an outbound socket, the call is then parked and the inbound socket captures the park event and starts recording. With the playback in place i get audio, and without it I simply get a silent file of the correct duration presumably meaning that the the RTP stream is not active.
You can try a brief silence_stream at the start of the call to address this.
My question therefore is: How can I initialise the RTP stream for recording, without having played a file first? Is there a command for this, or an argument I can pass to the record application?
FreeSWITCH already does this, its likely whatever your talking to does not. What is on the other end of the call.
My objective is to understand how RTP streams are initialised in FreeSWITCH and any input would be greatly appreciated.
_________________________________________________________________________ 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
You an confirm 100% with a packet trace, but I suspect the difference is, in the case that doesn't work, you are not actually getting any rtp data from the remote side. What type of voip handset is it talking to? Mike On Oct 1, 2013, at 9:00 AM, Callum Guy <callum.guy@x-on.co.uk> wrote:
Hi Michael,
Thanks you for your input.
I can confirm that inserting a silence stream prior to the recording works in the same way that playing some actual audio does, resulting in a successful recording. Worth noting is that there appears to be a duration threshold where if the duration is too short (in my case <100ms) then the recording come out blank - presumably this is because the stream has not had enough time to prepare the channel before recording starts.
In response to your question the call is a remotely registered VOIP handset (OpenSIPS) dialling directly into FreeSWITCH with all call control handled by ESL. When I stated "initialise the RTP stream for recording" that is my way of trying to communicate that its my understanding that this is what playing the audio file (or silence stream following your comment) was performing in FreeSWITCH.
I feel that you have answered my question however i wanted to post some fs_cli output to confirm that this is expected behaviour (or something I should learn to expect!). The lines in red are what i have called "RTP stream initialise".
Call with a silence stream (This records successfully)
2013-10-01 15:10:35.830044 [DEBUG] switch_ivr.c:612 sofia/internal/3333320116@x-onsip.com Command Execute playback(silence_stream://1000) EXECUTE sofia/internal/3333320116@x-onsip.com playback(silence_stream://1000) 2013-10-01 15:10:35.830044 [DEBUG] switch_ivr_play_say.c:1308 Codec Activated L16@8000hz 1 channels 20ms 2013-10-01 15:10:35.860032 [DEBUG] switch_core_session.c:998 Send signal sofia/internal/3333320116@x-onsip.com [BREAK] 2013-10-01 15:10:35.860032 [DEBUG] switch_core_session.c:998 Send signal sofia/internal/3333320116@x-onsip.com [BREAK] 2013-10-01 15:10:35.860032 [DEBUG] switch_core_session.c:998 Send signal sofia/internal/3333320116@x-onsip.com [BREAK] 2013-10-01 15:10:35.880047 [DEBUG] switch_rtp.c:3704 Correct ip/port confirmed. 2013-10-01 15:10:35.880047 [DEBUG] sofia.c:5685 Channel sofia/internal/3333320116@x-onsip.com entering state [ready][200] 2013-10-01 15:10:36.820081 [DEBUG] switch_ivr_play_say.c:1693 done playing file silence_stream://1000 2013-10-01 15:10:36.820081 [DEBUG] switch_ivr.c:612 sofia/internal/3333320116@x-onsip.com Command Execute record(/usr/share/sounds/recordings/test.wav 10 200) EXECUTE sofia/internal/3333320116@x-onsip.com record(/usr/share/sounds/recordings/test.wav 10 200) 2013-10-01 15:10:36.820081 [DEBUG] switch_ivr_play_say.c:599 Raw Codec Activated 2013-10-01 15:10:36.820081 [DEBUG] switch_core_codec.c:219 sofia/internal/3333320116@x-onsip.com Push codec L16:70 2013-10-01 15:10:39.920081 [DEBUG] switch_core_session.c:998 Send signal sofia/internal/3333320116@x-onsip.com [BREAK] 2013-10-01 15:10:39.940081 [NOTICE] sofia.c:716 Hangup sofia/internal/3333320116@x-onsip.com [CS_EXECUTE] [NORMAL_CLEARING]
Call without a silence stream (This records silence)
2013-10-01 15:13:06.660045 [DEBUG] switch_ivr.c:612 sofia/internal/3333320116@x-onsip.com Command Execute playback(silence_stream://10) EXECUTE sofia/internal/3333320116@x-onsip.com playback(silence_stream://10) 2013-10-01 15:13:06.660045 [DEBUG] switch_ivr_play_say.c:1308 Codec Activated L16@8000hz 1 channels 20ms 2013-10-01 15:13:06.680011 [DEBUG] switch_ivr_play_say.c:1693 done playing file silence_stream://10 2013-10-01 15:13:06.680011 [DEBUG] switch_ivr.c:612 sofia/internal/3333320116@x-onsip.com Command Execute record(/usr/share/sounds/recordings/test.wav 10 200) EXECUTE sofia/internal/3333320116@x-onsip.com record(/usr/share/sounds/recordings/test.wav 10 200) 2013-10-01 15:13:06.680011 [DEBUG] switch_ivr_play_say.c:599 Raw Codec Activated 2013-10-01 15:13:06.680011 [DEBUG] switch_core_codec.c:219 sofia/internal/3333320116@x-onsip.com Push codec L16:70 2013-10-01 15:13:06.760081 [DEBUG] switch_core_session.c:998 Send signal sofia/internal/3333320116@x-onsip.com [BREAK] 2013-10-01 15:13:06.760081 [DEBUG] switch_core_session.c:998 Send signal sofia/internal/3333320116@x-onsip.com [BREAK] 2013-10-01 15:13:06.760081 [DEBUG] switch_core_session.c:998 Send signal sofia/internal/3333320116@x-onsip.com [BREAK] 2013-10-01 15:13:06.780071 [DEBUG] switch_rtp.c:3704 Correct ip/port confirmed. 2013-10-01 15:13:06.780071 [DEBUG] sofia.c:5685 Channel sofia/internal/3333320116@x-onsip.com entering state [ready][200] 2013-10-01 15:13:09.680081 [DEBUG] switch_core_codec.c:244 sofia/internal/3333320116@x-onsip.com Restore previous codec PCMA:8. 2013-10-01 15:13:09.680081 [DEBUG] switch_ivr.c:612 sofia/internal/3333320116@x-onsip.com Command Execute park()
Please do let me know if there is anything interesting about the output i am seeing above or that i should apply caution to!
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 13:21, Michael Jerris <mike@jerris.com> wrote:
On Oct 1, 2013, at 5:51 AM, Callum Guy <callum.guy@x-on.co.uk> wrote:
I am trying to understand how audio streams are initialised in FreeSWITCH. I'm working with ESL (inbound and outbound) and trying to record some audio. Through testing i have proven that audio is working correctly for bridged calls, conferences and file playback however not for single legged audio recording - that is, until I play a file first.
In my example the playback application is executed from an outbound socket, the call is then parked and the inbound socket captures the park event and starts recording. With the playback in place i get audio, and without it I simply get a silent file of the correct duration presumably meaning that the the RTP stream is not active.
You can try a brief silence_stream at the start of the call to address this.
My question therefore is: How can I initialise the RTP stream for recording, without having played a file first? Is there a command for this, or an argument I can pass to the record application?
FreeSWITCH already does this, its likely whatever your talking to does not. What is on the other end of the call.
My objective is to understand how RTP streams are initialised in FreeSWITCH and any input would be greatly appreciated.
_________________________________________________________________________ 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
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
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
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
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
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
participants (3)
-
Anthony Minessale
-
Callum Guy
-
Michael Jerris