Mathieu Rene schrieb:

Hi,

Lange nicht gesprochen. What can happen, usually, is network congestion causing a delay buildup over time (FS times its reads at every 20ms and returns a comfort noise frame if it can't get an RTP frame immediately). If frames come in 2-3 ms delayed because of congestion, delay can build up over time. If you are in a C module, you can send a message to the channel so it drops frames (essentially reads until EWOULDBLOCK).

zB:

switch_core_session_message_t msg = { 0 }; msg.message_id = SWITCH_MESSAGE_INDICATE_AUDIO_SYNC; msg.from = __FILE__; switch_core_session_receive_message(session, &msg);

Hope that fixes it

Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca

On 2010-08-24, at 1:54 PM, Achim Stamm wrote:

...

Hello!

I have following problem:

My current session is connected to a thirdParty Application by using an own FreeSwitch application "DoingReadAndWriteFrames". The communication between FreeSwitch Session and thirdParty Application is done by reading and writing frames in a while loop. At start of FreeSwitch Session the communication works without delay. After three or more hours i get a communication delay of one or more seconds. If i hang up and make a new call (a new freeswitch session), than the delay disappears, but after several hours the delay comes up again.

It is possible, that i get an old frame (one second ago) with switch_core_session_read_frame ?

Is there a solution (for example an freeswitch core api call) to avoid the delay ?

Greetings

Achim Stamm

-- Achim Stamm, Dipl.-Inform. (FH)

Lyncker & Theis GmbH Wilhelmstr. 16 65185 Wiesbaden Germany

Fon +49 611/9006951 Fax +49 611/9406125

Handelsregister: HRB 23156 Amtsgericht Wiesbaden Steuernummer: 04323897052 USt-IdNr.: DE255806399

Geschäftsführer: Filip Lyncker, Armin Theis

_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

Thanks for your suggestion. The fix works, but when should i do the fix ? Best way for me is to call "Audio Sync" every hour (or every ten minutes) after session is started and when silence is on channel. First try was to place audio synchronisation, when i get a silent Frame: if (switch_test_flag(read_frame, SFF_CNG) || !read_frame->samples) { switch_core_session_message_t msg = { 0 }; msg.message_id = SWITCH_MESSAGE_INDICATE_AUDIO_SYNC; msg.from = __FILE__; switch_core_session_receive_message(session, &msg); } Here the problem is, that i don't get an silence Frame, so audio synchronisation is never called. How can i recognize silent on channel ? Next try was to call every 10 minutes to do the "Audio Sync". But if somebody says something at same time doing audio synchronisation, this frames will be droped. How can i get the session running time ? Greetings Achim Stamm -- Achim Stamm, Dipl.-Inform. (FH) Lyncker & Theis GmbH Wilhelmstr. 16 65185 Wiesbaden Germany Fon +49 611/9006951 Fax +49 611/9406125 Handelsregister: HRB 23156 Amtsgericht Wiesbaden Steuernummer: 04323897052 USt-IdNr.: DE255806399 Geschäftsführer: Filip Lyncker, Armin Theis

On Thu, 2010-08-26 at 05:11 -0700, Bret McDanel wrote:

On Thu, 2010-08-26 at 13:19 +0200, Achim Stamm wrote:

...

Mathieu Rene schrieb:

...

Hi,

Lange nicht gesprochen. What can happen, usually, is network congestion causing a delay buildup over time (FS times its reads at every 20ms and returns a comfort noise frame if it can't get an RTP frame immediately). If frames come in 2-3 ms delayed because of congestion, delay can build up over time. If you are in a C module, you can send a message to the channel so it drops frames (essentially reads until EWOULDBLOCK).

I am unsure if your explanation is correct. If there is a delay of 2-3 ms 1 comfort noise frame should be generated (unless its doing discontinuous media), after that it should have a buffer built up of received frames so another delay of 2-3 ms would not cause an interleaving of CNG and audio (which would degrade call quality).

Have to agree with Bret here - the thing which causes noticeable delays to start to appear on long calls is a mismatch in clocks between two points on the chain. One end sending packets slightly faster than the other processes them will result in an indefinite buildup in delay over time, unless: - the jitter buffering's clever enough to notice this, and chuck packets away; - the sender has silence suppression on (as in send nothing, not send CNG frames), and the party at that end occasionally stops talking (cue mother-in-law joke) at which point things get back in sync; - (possibly) there's a non-zero amount of packet loss, and the receiver doesn't try to fill the gaps by duplicating previous packets. --Dave -- David Knell, Director, 3C Limited T: +44 20 3298 2000 E: dave@3c.co.uk W: http://www.3c.co.uk