You are arrogantly refusing to cooperate with my questions (why are people so stubborn!!!!) My patience is limited when dealing with someone playing games like this intentionally ignoring all my questions then writing a whole new paragraph of other non-related statements ....... This is what causes people to be mean on forums and mailing lists and I am doing my best to hold on to my patience. I am asking you question to try and weed out what your problem is, not to argue with you in any way. I bet when the cable guy tells you to reboot your device, you only pretend to and tell him you did it....... Why are you adding the manual-rtp-bugs if you don't even know what they do? They are all documented in the header file RTP_BUG_SEND_LINEAR_TIMESTAMPS = (1 << 3), /* Our friends at Sonus get real mad when the timestamps are not in perfect sequence even during periods of silence. With this flag, we will only increment the timestamp when write packets even if they are eons apart. */ RTP_BUG_NEVER_SEND_MARKER = (1 << 5), /* Our friends at Sonus are on a roll, They also get easily dumbfounded by marker bits. This flag will never send any. Sheesh.... */ If your packets are out of order it means your network is saturated or your network stack on your box is overloaded. Are you taking packet captures from your box sending the packets or the one receiving of a switch in between or both? Somewhere you have a problem...... if you want to use a jitter buffer to fix it, you can but you need it on the receiving box by using the jitterbuffer_ms variable set to the desired size in ms 60-80 recommended. <action application="set" data="jitterbuffer_msec=60"/> BEFORE you answer the call. once its up, at the cli you can do uuid_jitterbuffer <uuid> debug:DEBUG to get live stats...... This mailing list thread has turned into a bug report about a bug with no data to even look at and I hate putting issues on this mailing list. Within a few hours this email will be 5 pages outside the top of my inbox and I will have a hard time keeping track of it. I think I write 3 emails a day begging people to keep issues on Jira. That way we can at least get some confirmation what version the FS is and all the other On Fri, Feb 10, 2012 at 5:31 PM, Holger Freyther <holger@freyther.de> wrote:
Anthony Minessale <anthony.minessale@...> writes:
You are pushing RTP up against TDM, RTP can start and stop, TDM cannot, When there is no RTP the TDM will carry on sending the IDLE_FLAG byte over the wire.
I made both the RTP stack and the TDM endpoint from scratch so you should assume I may have some insight.
What I am arguing with... is that if I say a word like 'two' and RTP looks a bit like this.
RTP: Wall Time Seq.No Time 'Sound' 0.0 1 0 'T' 20ms* 2 160 'W' 40ms* 3 320 'O' ... some skew 100 100*160 'T' +20ms 101 101*160 'W' +20ms 102 102*160 'O'
and on the remote it arrives as: 'TW(?)O'..'T'..'O'
something is wrong with the playback speed/queue/buffer of the audio stack. All I ask for is (because I didn't see anything in the wiki about that):
1.) How do I check if the jitter buffer is enabled on a call. 2.) How do I check if arriving RTP packets arrived too late for the speed of the FreeTDM voice queue.
More details: I started with a setup like this:
RTP/AMR -> FreeSWITCH (sangoma transcoder) -> FreeTDM..
For debugging I changed it to:
AMR -> FreeSWITCH -> RTP/PCMA -> FreeSWITCH -> FreeTDM. (SIP on 5060) (SIP on 5062)
The idea was that the first FreeSWITCH has to deal with the jitter and the second receives a clean linear in wall clock time RTP stream. My sofia sip profile includes these params: <param name="rtp-timer-name" value="soft"/> <param name="manual-rtp-bugs" value="SEND_LINEAR_TIMESTAMPS|NEVER_SEND_MARKER|\n IGNORE_DTMF_DURATION" /> <param name="rtp-rewrite-timestamps" value="true"/>
The resulting output of the frontend FreeSWITCH is not linear though (so no idea what rtp-timer-name soft should do): But the resulting stream has packets like this: P.No Wall Time Codec 723 12.761045 G.711 PCMA, Seq=18533, Time=90720 731 12.841107 G.711 PCMA, Seq=18534, Time=90880
so somehow the expected arrival time was 17.78 but it ended up being 12.84 and I think FreeSWITCH/FreeTDM/STFU do not deal well with that.
any ideas? holger
* add a little jitter
_________________________________________________________________________ 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