- FreeSWITCH-dev - FreeSWITCH Mailing Lists

rtp question
by Seven Du 04 Jul '12

04 Jul '12

Hi, libx264 encoded NALUs exceeding packet window and some phones don't like it so I need to manually split with FU-A, I tried frame->m but looks like all packets has marker = 1 even frame->m = 0; by looking at mod_fsv.c, I added the following and generate my own rtp header switch_set_flag((&vid_frame), SFF_RAW_RTP); switch_set_flag((&vid_frame), SFF_PROXY_PACKET); but looks like it doens't send my rtp header, switch_rtp.c has a check also on SWITCH_RTP_FLAG_RAW_WRITE which I don't see in mod_fsv.c fwd = (switch_test_flag(rtp_session, SWITCH_RTP_FLAG_RAW_WRITE) && switch_test_flag(frame, SFF_RAW_RTP)) ? 1 : 0; I also tried set SFF_RTP_HEADER, but it tends to send double as packets looks if (switch_test_flag(frame, SFF_RTP_HEADER)) { in switch_rtp.c doesn't stop and what the purpose of this param? Any highlights? Thanks. -- About: http://about.me/dujinfang Blog: http://www.dujinfang.com Proj: http://www.freeswitch.org.cn Sent with Sparrow (http://www.sparrowmailapp.com)

2 2

Re: [Freeswitch-dev] Question about RTP marker
by Peter Olsson 04 Jul '12

04 Jul '12

I've added FS-4382, please check there for further info. /Peter -----Ursprungligt meddelande----- Från: freeswitch-dev-bounces(a)lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] För Peter Olsson Skickat: den 3 juli 2012 18:07 Till: freeswitch-dev(a)lists.freeswitch.org Ämne: Re: [Freeswitch-dev] Question about RTP marker Thank you for your replies, both Tony and Kristian - it made things a little bit clearer for me :) I will submit a proposed patch to Jira later on (probably tomorrow), and you can review my changes there, it's a small change. /Peter -----Ursprungligt meddelande----- Från: freeswitch-dev-bounces(a)lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] För Kristian Kielhofner Skickat: den 3 juli 2012 17:33 Till: freeswitch-dev(a)lists.freeswitch.org Ämne: Re: [Freeswitch-dev] Question about RTP marker +1 The use of the RTP marker has been broken and misunderstood by many implementations... The references the OP found about "talkspurts" are probably referring to the use of markers with VAD (voice activity detection). When VAD detects speech the first RTP packet is supposed to have the marker set, almost as a way of saying "Hey! I'm talking again". Of course with VAD a new talkspurt will also have a different timestamp... FreeSWITCH (out of respect for jitter buffers, as Anthony said) tries to pass original (read: meaningful) timestamps and use markers wherever possible. Consider the following scenario: Call -> IVR (FS starts generating RTP) IVR -> bridge to external SIP device (device starts generating RTP) In this scenario FS will generate the initial RTP stream with it's own timestamps. When the call is bridged to the remote device FS will set the marker and pass the timestamps from the B leg to the A leg. This allows the far end jitterbuffers (not FS) to buffer jitter based on the actual end to end RTP stream. Unfortunately this can cause all kinds of confusion with broken implementations. While changing the SSRC is (of course) a hack if it improves compatibility while maintaining the usefulness and integrity of timestamps (and jitter buffers) I'm for it. On Tue, Jul 3, 2012 at 11:18 AM, Anthony Minessale <anthony.minessale(a)gmail.com> wrote: > The line is really blurry between what is right and what works better. > I think the only real rule about the marker bit is that you are > supposed to set it any time the timestamp is not the next expected > timestamp. > > This is supposed to help you to understand that you are purposely > sending a packet that has a different timestamp base or that you are > resuming after intentionally not sending packets for a period of time. > This tells the remote end to flush its jitter buffer which probably > explains the drop in audio. > > If changing the SSRC is an acceptable workaround for when the rtp > streams change that do not result in audio gaps, I'm more than happy > to accept it as a default and we can always make it a config option if > it presents any problems. > > > > On Tue, Jul 3, 2012 at 9:39 AM, Peter Olsson > <peter.olsson(a)visionutveckling.se> wrote: >> When I've been debugging RTP streams in Wireshark, I've noticed that >> Whireshark will get "everything wrong" when the timestamp changes (is >> reset). For instance, if I call a conference, by the time I get into >> the conference, the RTP timestamps will start over, and FS will send >> the marker bit By that time Wireshark will report strange figures for jitter etc. >> >> >> >> After some Googling I've found that the meaning of the RTP marker is >> to indicate "the beginning of a talkspurt". Which is not very clear >> to me... :) >> >> >> >> So my question is - is RTP marker really enough when starting a "new >> RTP stream" (not really new, but since the timestamps are reset we >> can think of it like that) - according to what I've been able to >> find, maybe the SSRC should also be changed? >> >> >> >> I have created a patch that will change the SSRC when a reset like >> this occurs, and after that Wireshark detects my audio streams >> without problems (though, it will detect more streams), but no strange jitter figures etc. >> are reported. >> >> >> >> The reason I started digging into this was because a PBX I was >> connecting to lost about the first second of audio after connecting >> to the conference, after also changing the SSRC the problem seems resolved. >> >> >> >> I could make a RTP_BUG setting for this, but I'm not really sure if I >> should really care - that's why I'm asking here, if anyone has more >> knowledge about this? >> >> >> >> /Peter >> >> >> >> >> _____________________________________________________________________ >> ____ Professional FreeSWITCH Consulting Services: >> consulting(a)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 >> >> Join Us At ClueCon - Aug 7-9, 2012 >> >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev(a)lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de >> v >> 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(a)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 > > Join Us At ClueCon - Aug 7-9, 2012 > > FreeSWITCH-dev mailing list > FreeSWITCH-dev(a)lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org -- Kristian Kielhofner _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting(a)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 Join Us At ClueCon - Aug 7-9, 2012 FreeSWITCH-dev mailing list FreeSWITCH-dev(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting(a)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 Join Us At ClueCon - Aug 7-9, 2012 FreeSWITCH-dev mailing list FreeSWITCH-dev(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org !DSPAM:4ff3184a32761575917611!

2 1

ClueCon 2012 - Last Chance for 16 Entries
by Michael Collins 03 Jul '12

03 Jul '12

Hello all! I am happy to report that a number of people have taken advantage of this opportunity and have registered in time to get their 16 entries. Remember that you can register <http://www.cluecon.com/register?cc12-0703>any time on July 3rd and still qualify for the extra entries. The bits will shift at midnight Central time so don't delay! Only 34 more days and we'll all be in Chicago. See you then! -- Michael S Collins ClueCon Team http://www.cluecon.com 877-7-4ACLUE

1 0

Re: [Freeswitch-dev] Question about RTP marker
by Peter Olsson 03 Jul '12

03 Jul '12

Thank you for your replies, both Tony and Kristian - it made things a little bit clearer for me :) I will submit a proposed patch to Jira later on (probably tomorrow), and you can review my changes there, it's a small change. /Peter -----Ursprungligt meddelande----- Från: freeswitch-dev-bounces(a)lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] För Kristian Kielhofner Skickat: den 3 juli 2012 17:33 Till: freeswitch-dev(a)lists.freeswitch.org Ämne: Re: [Freeswitch-dev] Question about RTP marker +1 The use of the RTP marker has been broken and misunderstood by many implementations... The references the OP found about "talkspurts" are probably referring to the use of markers with VAD (voice activity detection). When VAD detects speech the first RTP packet is supposed to have the marker set, almost as a way of saying "Hey! I'm talking again". Of course with VAD a new talkspurt will also have a different timestamp... FreeSWITCH (out of respect for jitter buffers, as Anthony said) tries to pass original (read: meaningful) timestamps and use markers wherever possible. Consider the following scenario: Call -> IVR (FS starts generating RTP) IVR -> bridge to external SIP device (device starts generating RTP) In this scenario FS will generate the initial RTP stream with it's own timestamps. When the call is bridged to the remote device FS will set the marker and pass the timestamps from the B leg to the A leg. This allows the far end jitterbuffers (not FS) to buffer jitter based on the actual end to end RTP stream. Unfortunately this can cause all kinds of confusion with broken implementations. While changing the SSRC is (of course) a hack if it improves compatibility while maintaining the usefulness and integrity of timestamps (and jitter buffers) I'm for it. On Tue, Jul 3, 2012 at 11:18 AM, Anthony Minessale <anthony.minessale(a)gmail.com> wrote: > The line is really blurry between what is right and what works better. > I think the only real rule about the marker bit is that you are > supposed to set it any time the timestamp is not the next expected > timestamp. > > This is supposed to help you to understand that you are purposely > sending a packet that has a different timestamp base or that you are > resuming after intentionally not sending packets for a period of time. > This tells the remote end to flush its jitter buffer which probably > explains the drop in audio. > > If changing the SSRC is an acceptable workaround for when the rtp > streams change that do not result in audio gaps, I'm more than happy > to accept it as a default and we can always make it a config option if > it presents any problems. > > > > On Tue, Jul 3, 2012 at 9:39 AM, Peter Olsson > <peter.olsson(a)visionutveckling.se> wrote: >> When I've been debugging RTP streams in Wireshark, I've noticed that >> Whireshark will get "everything wrong" when the timestamp changes (is >> reset). For instance, if I call a conference, by the time I get into >> the conference, the RTP timestamps will start over, and FS will send >> the marker bit By that time Wireshark will report strange figures for jitter etc. >> >> >> >> After some Googling I've found that the meaning of the RTP marker is >> to indicate "the beginning of a talkspurt". Which is not very clear >> to me... :) >> >> >> >> So my question is - is RTP marker really enough when starting a "new >> RTP stream" (not really new, but since the timestamps are reset we >> can think of it like that) - according to what I've been able to >> find, maybe the SSRC should also be changed? >> >> >> >> I have created a patch that will change the SSRC when a reset like >> this occurs, and after that Wireshark detects my audio streams >> without problems (though, it will detect more streams), but no strange jitter figures etc. >> are reported. >> >> >> >> The reason I started digging into this was because a PBX I was >> connecting to lost about the first second of audio after connecting >> to the conference, after also changing the SSRC the problem seems resolved. >> >> >> >> I could make a RTP_BUG setting for this, but I'm not really sure if I >> should really care - that's why I'm asking here, if anyone has more >> knowledge about this? >> >> >> >> /Peter >> >> >> >> >> _____________________________________________________________________ >> ____ Professional FreeSWITCH Consulting Services: >> consulting(a)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 >> >> Join Us At ClueCon - Aug 7-9, 2012 >> >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev(a)lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de >> v >> 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(a)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 > > Join Us At ClueCon - Aug 7-9, 2012 > > FreeSWITCH-dev mailing list > FreeSWITCH-dev(a)lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org -- Kristian Kielhofner _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting(a)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 Join Us At ClueCon - Aug 7-9, 2012 FreeSWITCH-dev mailing list FreeSWITCH-dev(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org !DSPAM:4ff3106232761496470876!

2 1

Question about RTP marker
by Peter Olsson 03 Jul '12

03 Jul '12

When I've been debugging RTP streams in Wireshark, I've noticed that Whireshark will get "everything wrong" when the timestamp changes (is reset). For instance, if I call a conference, by the time I get into the conference, the RTP timestamps will start over, and FS will send the marker bit By that time Wireshark will report strange figures for jitter etc. After some Googling I've found that the meaning of the RTP marker is to indicate "the beginning of a talkspurt". Which is not very clear to me... :) So my question is - is RTP marker really enough when starting a "new RTP stream" (not really new, but since the timestamps are reset we can think of it like that) - according to what I've been able to find, maybe the SSRC should also be changed? I have created a patch that will change the SSRC when a reset like this occurs, and after that Wireshark detects my audio streams without problems (though, it will detect more streams), but no strange jitter figures etc. are reported. The reason I started digging into this was because a PBX I was connecting to lost about the first second of audio after connecting to the conference, after also changing the SSRC the problem seems resolved. I could make a RTP_BUG setting for this, but I'm not really sure if I should really care - that's why I'm asking here, if anyone has more knowledge about this? /Peter

3 2

Reminder: Last chance for 16 tickets before the bits shift!
by Michael Collins 02 Jul '12

02 Jul '12

Just a friendly reminder: July 3rd is the last day to get all 16 tickets in the great ClueCon giveway. Be sure to get registered<http://www.cluecon.com/register?cc12-0702a>by the end of the day on Tuesday, July 3rd to maximize your chance to win big! Looking forward to seeing you all in Chicago next month. -- Michael S Collins ClueCon Team http://www.cluecon.com 877-7-4ACLUE

1 0

Issue while creating a session for an incoming call in managed application
by Papineni, Suneel 02 Jul '12

02 Jul '12

Hi, I am having a third party VoIP client which exposes API in .NET to communicate with my application. I want to use this client as an endpoint in Freeswitch (like how it is implemented in "mod_skypopen" module), so that calls coming to this client can be handled at Freeswitch and (if required) bridge calls to clients connected to Freeswitch. To implement this, I have written a managed module in which "ILoadNotificationPlugin" is implemented where config (client's interface config) is loaded. When there is an incoming call (ringing state) to the client, I get handle in managed module and trying to establish a session at freeswitch. While doing this I am getting exception as "Attempted to read or write protected memory. This is often an indication that other memory is corrupt." Here is the code that I am using... Could someone guide me if I am doing this correctly. Note: I am following "mod_skypopen" as an example... public static int new_inbound_channel(private_object pobject) { SWIGTYPE_p_switch_core_session session = null; SWIGTYPE_p_switch_channel channel = null; switch_endpoint_interface intf = new switch_endpoint_interface(); intf.interface_name = "NET_interface"; intf.io_routines = io_routines; intf.state_handler = state_handlers; freeswitch.switch_core_set_globals(); Api fsApi = new Api(); String uuid = fsApi.ExecuteString("create_uuid"); try { session = freeswitch.switch_core_session_request_uuid(intf, switch_call_direction_t.SWITCH_CALL_DIRECTION_INBOUND, 0, null, uuid); //I am getting the above issue here.... if (session != null) { freeswitch.switch_core_session_add_stream(session, null); channel = freeswitch.switch_core_session_get_channel(session); if (channel == null) { freeswitch.switch_core_session_destroy_state(session); return 0; } freeswitch.switch_channel_set_variable_name_printf(channel, "waste", "false"); pobject.caller_profile = freeswitch.switch_caller_profile_new(freeswitch.switch_core_session_get_pool(session), "NETClient", "dialplan", "callid_name", "callid_number", null, null, null, null, "mod_netclient", "context", "destination"); if (pobject.caller_profile != null) { freeswitch.switch_channel_set_name(channel, "name"); freeswitch.switch_channel_set_caller_profile(channel, pobject.caller_profile); } freeswitch.switch_channel_set_state_flag(channel, switch_channel_flag_t.CF_GEN_RINGBACK); switch_status_t session_status = freeswitch.switch_core_session_thread_launch(session); if (session_status != switch_status_t.SWITCH_STATUS_SUCCESS) { freeswitch.switch_core_session_destroy_state(session); return 0; } } } catch (Exception exp) { string expstring = exp.Message; } return 0; } Thanks & Regards Suneel

5 7

Trunk: cc1: error: unrecognized command line option "-Wunused-but-set-variable"
by Carsten Bock 02 Jul '12

02 Jul '12

Hi, i am not sure, if it was an update with latest debian or some changes in latest trunk version of Freeswitch, but since today i am getting the following error when trying to build debian packages: I am using the latest, clean GIT-Version of Freeswitch. [...] Making all in src make[8]: Entering directory `/root/dev/freeswitch/freeswitch/libs/spandsp/src' make[9]: Entering directory `/root/dev/freeswitch/freeswitch/libs/spandsp/src' libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libxml2 -I/root/dev/freeswitch/freeswitch/libs/tiff-3.8.2/libtiff -DNDEBUG -msse2 -std=gnu99 -ffast-math -Wall -Wunused-variable -Wunused-but-set-variable -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fvisibility=hidden -DHAVE_VISIBILITY=1 -ggdb3 -O2 -c ademco_contactid.c -fPIC -DPIC -o ademco_contactid.o cc1: error: unrecognized command line option "-Wunused-but-set-variable" make[9]: *** [ademco_contactid.lo] Fehler 1 My GCC-Version is 4.4.5 (Debian stable): root@devel:~/dev# gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.5 (Debian 4.4.5-8) Any hints are welcome.... Thanks, Carsten

1 0

FreeSWITCH Weekly News and Notes
by Michael Collins 02 Jul '12

02 Jul '12

Welcome to July! We hope the leap second didn't crash any of your servers. Some folks were not so fortunate<http://www.bbc.co.uk/news/technology-18672173> . On last week's conference call we had an open discussion on topics chosen by members of the community. One topic that got a fair amount of traction was how to address NAT when FreeSWITCH has a public IP address and the clients themselves are behind NAT. Dave Kompel shared his strategy of using "aggressive-nat-detection" on the SIP profile and then optionally setting "NDLB-connectile-dysfunction" for the directory entry. We also discussed other topics like IPv6 and using FreeSWITCH in the cloud with Amazon. The audio is available here<http://torrents.freeswitch.org/conf_call_2012-06-27.torrent?cc12-0702> . Darren Schreiber's company, 2600hz, made a very interesting announcement<http://www.prnewswire.com/news-releases/2600hz-launches-new-service-kazoo-b…>regarding "Kazoo BETA." This new cloud-based PBX solution uses a lot of open source software under the hood, including FreeSWITCH. Stay tuned for a more in-depth discussion with Darren about this new platform. On the ClueCon front we are happy to report that many have taken advantage of the fact that they can get 2^4 tickets (i.e. 16 tickets) for the drawings at ClueCon 2012. The bits will shift at the end of the day tomorrow, July 3, so don't delay! You can register quickly and easily here<http://www.cluecon.com/register?cc12-0702>on the ClueCon site. After July 3rd registrants will receive 2^3 or 8 tickets. Don't delay - we are giving away a total of ten 7" Android tablets among many other prizes supplied by our sponsors<http://www.cluecon.com/sponsors?cc12-0702> . Only 35 days until ClueCon 2012! -- Michael S Collins ClueCon Team http://www.cluecon.com 877-7-4ACLUE cc12-0702

1 0

Support for TLS and SRTP with SPA 3102
by Prasd D 30 Jun '12

30 Jun '12

SPA 3102 has TLS support but SRTP with different type of key exchange I think (called Mikey) instead of SDP. It would be very useful to have support for this as an added module or profile if needed. Thanks, Prasd

3 3