[Freeswitch-dev] ARM cross compile
I'm trying to get freeswitch to cross compile on arm (linux 2.6.21), build o/s linux, using OpenWRT buildroot. I've gotten as far as getting the console running and loading all the modules (no calls attempted yet), the switch will be SIP only with a custom (yet to be developed) endpoint module for an analog line interface. I'm using these modules: mod_console mod_syslog mod_commands mod_conference mod_dptools mod_limit mod_expr mod_esf mod_fsv mod_ilbc mod_dialplan_asterisk mod_sofia mod_event_socket mod_sndfile mod_tone_stream mod_lua Is there a way to disable the c++ code in freeswitch without totally breaking it? I'm in an embedded environment and libstdc++ is large and takes up valuable flash space. Is there a way to specify a different install and runtime location for the modules (like you can do for log conf and db?) Could be runtime or build time, I found --with-modinstdir but this seems to affect the install location and the runtime search location. In switch_core_state_machine.c backtrace_symbols() fails, not supported in my arm environment. I hacked this to use the alternative version of print_trace. In pcre, libtool failed with the host build tools, had to add --tag=CC in LINK_FOR_BUILD. LINK_FOR_BUILD = $(LIBTOOL) --mode=link --tag=CC $(CC_FOR_BUILD) $(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) -I. -I$(top_srcdir) Although I don't need it the voipcodecs lib it will not load, causes freeswitch to exit, lrintf & rintf are not available in my arm environment and the voipcodecs configure does not test for them (libsndfile handles this correctly). My configure command line: export config_TARGET_CC="$(TARGET_CC)"; \ export config_BUILD_CC="$(HOSTCC)"; \ export config_TARGET_CFLAGS="$(TARGET_CFLAGS)"; \ export config_TARGET_LIBS="-L$(STAGING_DIR)/usr/lib"; \ export CC_FOR_BUILD="$(HOSTCC)"; \ export ac_cv_file__dev_zero=no; \ export apr_cv_tcp_nodelay_with_cork=yes; \ export ac_cv_sizeof_ssize_t=4; \ export ac_cv_file_dbd_apr_dbd_mysql_c=yes; \ export ac_cv_path__libcurl_config=$(BUILD_DIR)/curl-7.18.2/install/bin/curl-config; \ export apr_cv_mutex_recursive=yes; \ (cd $(TOPDIR)/ooma/freeswitch; rm -rf config.{cache,status} ; \ $(TARGET_CONFIGURE_OPTS) \ CFLAGS='$(TARGET_CFLAGS)' \ CPPFLAGS="-I$(STAGING_DIR)/usr/include" \ LDFLAGS="-L$(STAGING_DIR)/usr/lib" \ ./configure \ --prefix=$(PKG_BUILD_DIR) \ --target=$(GNU_TARGET_NAME) \ --host=$(GNU_TARGET_NAME) \ --build=$(GNU_HOST_NAME) \ --with-libcurl=$(BUILD_DIR)/curl-7.18.2/install \ --with-devrandom=/dev/urandom \ --with-modinstdir=/mod \ Thanks, Simon
See questions/comments inline On Jun 29, 2008, at 1:19 PM, Simon Capper wrote:
I'm trying to get freeswitch to cross compile on arm (linux 2.6.21), build o/s linux, using OpenWRT buildroot.
I've gotten as far as getting the console running and loading all the modules (no calls attempted yet), the switch will be SIP only with a custom (yet to be developed) endpoint module for an analog line interface.
I'm using these modules: mod_console mod_syslog mod_commands mod_conference mod_dptools mod_limit mod_expr mod_esf mod_fsv mod_ilbc mod_dialplan_asterisk mod_sofia mod_event_socket mod_sndfile mod_tone_stream mod_lua
Is there a way to disable the c++ code in freeswitch without totally breaking it? I'm in an embedded environment and libstdc++ is large and takes up valuable flash space.
We could fairly easily get rid of the cpp wrapper we use for embedded languages, but its used in mod_lua. The other thing you would have to disable would be portions of the switch_xml which uses cpp for the globbing routines which would have to be re-written in c or all of the globbing includes in the xml would have to not be used.
Is there a way to specify a different install and runtime location for the modules (like you can do for log conf and db?) Could be runtime or build time, I found --with-modinstdir but this seems to affect the install location and the runtime search location.
I am sure there is a way with modifications to the build system, but why?
In switch_core_state_machine.c backtrace_symbols() fails, not supported in my arm environment. I hacked this to use the alternative version of print_trace.
Is there a better ifdef we can use here so you don't need to hack?
In pcre, libtool failed with the host build tools, had to add -- tag=CC in LINK_FOR_BUILD. LINK_FOR_BUILD = $(LIBTOOL) --mode=link --tag=CC $(CC_FOR_BUILD) $(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) -I. -I$(top_srcdir)
We should (but clearly do not) do this from the top level configure. Can you open a bug on jira for this please.
Although I don't need it the voipcodecs lib it will not load, causes freeswitch to exit, lrintf & rintf are not available in my arm environment and the voipcodecs configure does not test for them (libsndfile handles this correctly).
Can you open a bug on jira for this as well
My configure command line: export config_TARGET_CC="$(TARGET_CC)"; \ export config_BUILD_CC="$(HOSTCC)"; \ export config_TARGET_CFLAGS="$(TARGET_CFLAGS)"; \ export config_TARGET_LIBS="-L$(STAGING_DIR)/usr/lib"; \ export CC_FOR_BUILD="$(HOSTCC)"; \
We should modify our top level configure to push these down to the appropriate libs.
export ac_cv_file__dev_zero=no; \ export apr_cv_tcp_nodelay_with_cork=yes; \ export ac_cv_sizeof_ssize_t=4; \ export ac_cv_file_dbd_apr_dbd_mysql_c=yes; \
This I assume would be typical in any cross compile situation. You can use a config.cache file for this.
export ac_cv_path__libcurl_config=$(BUILD_DIR)/curl-7.18.2/install/bin/curl- config; \
We have configure options for this one --with-libcurl
export apr_cv_mutex_recursive=yes; \
typical cross stuff, should be able to use config.cache
(cd $(TOPDIR)/ooma/freeswitch; rm -rf config.{cache,status} ; \
Why?
$(TARGET_CONFIGURE_OPTS) \ CFLAGS='$(TARGET_CFLAGS)' \ CPPFLAGS="-I$(STAGING_DIR)/usr/include" \ LDFLAGS="-L$(STAGING_DIR)/usr/lib" \
why?
./configure \ --prefix=$(PKG_BUILD_DIR) \ --target=$(GNU_TARGET_NAME) \ --host=$(GNU_TARGET_NAME) \ --build=$(GNU_HOST_NAME) \ --with-libcurl=$(BUILD_DIR)/curl-7.18.2/install \ --with-devrandom=/dev/urandom \ --with-modinstdir=/mod \
Thanks,
Simon
_______________________________________________ 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
Comments inline On 6/29/08 4:06 PM, "Michael Jerris" <mike@jerris.com> wrote:
See questions/comments inline
Is there a way to disable the c++ code in freeswitch without totally breaking it? I'm in an embedded environment and libstdc++ is large and takes up valuable flash space.
We could fairly easily get rid of the cpp wrapper we use for embedded languages, but its used in mod_lua. The other thing you would have to disable would be portions of the switch_xml which uses cpp for the globbing routines which would have to be re-written in c or all of the globbing includes in the xml would have to not be used.
I'm not stuck on lua, I thought it would be the smallest. Do you have any advice here, C maybe (I couldn't find a "mod_c"). Can I try anything to get rid of the other cpp files?
Is there a way to specify a different install and runtime location for the modules (like you can do for log conf and db?) Could be runtime or build time, I found --with-modinstdir but this seems to affect the install location and the runtime search location.
I am sure there is a way with modifications to the build system, but why?
In the cross compile environment the files are installed into a staging area rather than the absolute location they are run from, the staging area becomes root of the flash filesystem. The workaround I have is to copy the files out of the build area by hand rather than using install. A runtime option like -conf or -db would also work well.
In switch_core_state_machine.c backtrace_symbols() fails, not supported in my arm environment. I hacked this to use the alternative version of print_trace.
Is there a better ifdef we can use here so you don't need to hack?
You could test for the presence of backtrace_symbols() or execinfo.h in configure and have your own macro. I don't know of a macro that would work well for different architectures. Or you could just disable it for cross compile.
export ac_cv_path__libcurl_config=$(BUILD_DIR)/curl-7.18.2/install/bin/curl- config; \
We have configure options for this one --with-libcurl
I did use the --with-libcurl but it did not work, I'll investigate more.
(cd $(TOPDIR)/ooma/freeswitch; rm -rf config.{cache,status} ; \
Why?
Cut and paste, this is how many of the openwrt modules build, I will remove it, a config.cache would work well.
$(TARGET_CONFIGURE_OPTS) \ CFLAGS='$(TARGET_CFLAGS)' \ CPPFLAGS="-I$(STAGING_DIR)/usr/include" \ LDFLAGS="-L$(STAGING_DIR)/usr/lib" \
why?
On the build machine the build environment variables are set for cross compilation at build time by a build script, all the ARM cross compile tools, compilers, linkers, libs, headers etc are in $(STAGING_DIR), this just makes sure they are all set correctly, the freeswitch makefile picks up these values OK. This is normal. I'm still very new to freeswitch, less than a week, so any advice about using it in the embedded world would be really useful. Thanks, Simon
I thought of moving this thread over here. We’re trying to make the FS work with MS Exchange 2007 (in a non-RFC4733-compliant mode). For this to work, we need to get the Duration count start from 0 instead of starting from 160 (or any other sample rate). We assume these are the lines needed to be changed:
From /src/switch_rtp.c
1042 rtp_session->dtmf_data.out_digit_sofar = samples; 1043 rtp_session->dtmf_data.out_digit_sub_sofar = samples; To /src/switch_rtp.c 1042 rtp_session->dtmf_data.out_digit_sofar = 0; 1043 rtp_session->dtmf_data.out_digit_sub_sofar = 0; Are we missing anything? Are we breaking anything? (except compliancy) -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of UV Sent: Sunday, June 29, 2008 7:45 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Exchange 2007 UM - DTMF problem Apparently, not only MS do not comply with RFC4733 but also SJphone, Xlite (eyebeam) and Cisco (Call manager, IP phones, etc) amongst others. Is there anyway I can make FS's Duration to start from 0? I'm happy to change the code myself with a little guidance. -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Steve Underwood Sent: Sunday, June 29, 2008 3:42 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Exchange 2007 UM - DTMF problem Hi, Brian West wrote:
So if you can tell me where this is wrong as per 2833 and the
clarification via 4733 ?
rfc4733 obsoletes rfc2833 and says this:
The special duration value of zero is reserved to indicate that the
event lasts "forever", i.e., is a state and is considered to be
effective until updated. A sender MUST NOT transmit a zero duration
for events other than those defined as states. The receiver SHOULD
ignore an event report with zero duration if the event is not a
state.
/b
As well as that definition in RFC4733, they also have an example working in the way the text describes. They send DTMF with a packet rate of one every 50ms. The first packet of the DTMF sequence contains a duration of 400. What does FS actually do when a sequence starts at 0? Does it just drop the first packet, or the whole sequence? If it just drops the first packet, and the far end cares, that's seriously broken on their part. It means a single lost packet screws up the whole sequence. Not good. If FS drops the whole sequence, that might be a little too aggressive. Some will argue that a gateway should be totally transparent in these situations, but total transparency is only workable in simplistic cases. In the end, if MS are doing this you can be sure it will not be fixed, and must be tolerated. Regards, Steve
Have you confirmed for sure that having it start at zero is the whole problem? 2008/6/30 UV <uv@talknet.com.au>:
I thought of moving this thread over here.
We're trying to make the FS work with MS Exchange 2007 (in a non-RFC4733-compliant mode). For this to work, we need to get the Duration count start from 0 instead of starting from 160 (or any other sample rate).
We assume these are the lines needed to be changed:
From /src/switch_rtp.c
1042 rtp_session->dtmf_data.out_digit_sofar = samples;
1043 rtp_session->dtmf_data.out_digit_sub_sofar = samples;
To /src/switch_rtp.c
1042 rtp_session->dtmf_data.out_digit_sofar = 0;
1043 rtp_session->dtmf_data.out_digit_sub_sofar = 0;
Are we missing anything? Are we breaking anything? (except compliancy)
-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of UV Sent: Sunday, June 29, 2008 7:45 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Exchange 2007 UM - DTMF problem
Apparently, not only MS do not comply with RFC4733 but also SJphone, Xlite (eyebeam) and Cisco (Call manager, IP phones, etc) amongst others.
Is there anyway I can make FS's Duration to start from 0? I'm happy to change the code myself with a little guidance.
-----Original Message-----
From: freeswitch-users-bounces@lists.freeswitch.org
[mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Steve
Underwood
Sent: Sunday, June 29, 2008 3:42 PM
To: freeswitch-users@lists.freeswitch.org
Subject: Re: [Freeswitch-users] Exchange 2007 UM - DTMF problem
Hi,
Brian West wrote:
So if you can tell me where this is wrong as per 2833 and the
clarification via 4733 ?
rfc4733 obsoletes rfc2833 and says this:
The special duration value of zero is reserved to indicate that the
event lasts "forever", i.e., is a state and is considered to be
effective until updated. A sender MUST NOT transmit a zero duration
for events other than those defined as states. The receiver SHOULD
ignore an event report with zero duration if the event is not a
state.
/b
As well as that definition in RFC4733, they also have an example working
in the way the text describes. They send DTMF with a packet rate of one
every 50ms. The first packet of the DTMF sequence contains a duration of
400.
What does FS actually do when a sequence starts at 0? Does it just drop
the first packet, or the whole sequence? If it just drops the first
packet, and the far end cares, that's seriously broken on their part. It
means a single lost packet screws up the whole sequence. Not good. If FS
drops the whole sequence, that might be a little too aggressive.
Some will argue that a gateway should be totally transparent in these
situations, but total transparency is only workable in simplistic cases.
In the end, if MS are doing this you can be sure it will not be fixed,
and must be tolerated.
Regards,
Steve
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
The only way to confirm my hypothesis (which is based on comparative analysis between working “pass-rfc2833=true” and non-working “pass-rfc2833=false” scenarios) is to actually change the code and retest it. We’ll be testing it later today. The code will be changed as described in the previous email. Any comments / recommendations on that? _____ From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Tuesday, July 01, 2008 12:01 AM To: freeswitch-dev@lists.freeswitch.org Subject: Re: [Freeswitch-dev] Exchange 2007 UM - DTMF problem Have you confirmed for sure that having it start at zero is the whole problem? 2008/6/30 UV <uv@talknet.com.au>: I thought of moving this thread over here. We're trying to make the FS work with MS Exchange 2007 (in a non-RFC4733-compliant mode). For this to work, we need to get the Duration count start from 0 instead of starting from 160 (or any other sample rate). We assume these are the lines needed to be changed:
From /src/switch_rtp.c
1042 rtp_session->dtmf_data.out_digit_sofar = samples; 1043 rtp_session->dtmf_data.out_digit_sub_sofar = samples; To /src/switch_rtp.c 1042 rtp_session->dtmf_data.out_digit_sofar = 0; 1043 rtp_session->dtmf_data.out_digit_sub_sofar = 0; Are we missing anything? Are we breaking anything? (except compliancy) -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of UV Sent: Sunday, June 29, 2008 7:45 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Exchange 2007 UM - DTMF problem Apparently, not only MS do not comply with RFC4733 but also SJphone, Xlite (eyebeam) and Cisco (Call manager, IP phones, etc) amongst others. Is there anyway I can make FS's Duration to start from 0? I'm happy to change the code myself with a little guidance. -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Steve Underwood Sent: Sunday, June 29, 2008 3:42 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Exchange 2007 UM - DTMF problem Hi, Brian West wrote:
So if you can tell me where this is wrong as per 2833 and the
clarification via 4733 ?
rfc4733 obsoletes rfc2833 and says this:
The special duration value of zero is reserved to indicate that the
event lasts "forever", i.e., is a state and is considered to be
effective until updated. A sender MUST NOT transmit a zero duration
for events other than those defined as states. The receiver SHOULD
ignore an event report with zero duration if the event is not a
state.
/b
As well as that definition in RFC4733, they also have an example working in the way the text describes. They send DTMF with a packet rate of one every 50ms. The first packet of the DTMF sequence contains a duration of 400. What does FS actually do when a sequence starts at 0? Does it just drop the first packet, or the whole sequence? If it just drops the first packet, and the far end cares, that's seriously broken on their part. It means a single lost packet screws up the whole sequence. Not good. If FS drops the whole sequence, that might be a little too aggressive. Some will argue that a gateway should be totally transparent in these situations, but total transparency is only workable in simplistic cases. In the end, if MS are doing this you can be sure it will not be fixed, and must be tolerated. Regards, Steve _______________________________________________ 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 -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400 No virus found in this incoming message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.3/1525 - Release Date: 29/06/2008 15:09
Amazing. We’ve been running around Microsoft RFC4733 incompatibility issue the whole day after the problem mysteriously disappeared this morning just to find out that this well-encountered bug is solved on restart… Yes, FreeSWITCH DTMF problem with Microsoft Exchange 2007 Unified Messaging Server is solved with a simple server restart (for the Exchange, not the FS). Go figure… BTW, we’ve also confirmed that having it start at zero is the whole problem. But that is not required anymore. _____ From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of UV Sent: Tuesday, July 01, 2008 12:24 AM To: freeswitch-dev@lists.freeswitch.org Subject: Re: [Freeswitch-dev] Exchange 2007 UM - DTMF problem The only way to confirm my hypothesis (which is based on comparative analysis between working “pass-rfc2833=true” and non-working “pass-rfc2833=false” scenarios) is to actually change the code and retest it. We’ll be testing it later today. The code will be changed as described in the previous email. Any comments / recommendations on that? _____ From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Tuesday, July 01, 2008 12:01 AM To: freeswitch-dev@lists.freeswitch.org Subject: Re: [Freeswitch-dev] Exchange 2007 UM - DTMF problem Have you confirmed for sure that having it start at zero is the whole problem? 2008/6/30 UV <uv@talknet.com.au>: I thought of moving this thread over here. We're trying to make the FS work with MS Exchange 2007 (in a non-RFC4733-compliant mode). For this to work, we need to get the Duration count start from 0 instead of starting from 160 (or any other sample rate). We assume these are the lines needed to be changed:
From /src/switch_rtp.c
1042 rtp_session->dtmf_data.out_digit_sofar = samples; 1043 rtp_session->dtmf_data.out_digit_sub_sofar = samples; To /src/switch_rtp.c 1042 rtp_session->dtmf_data.out_digit_sofar = 0; 1043 rtp_session->dtmf_data.out_digit_sub_sofar = 0; Are we missing anything? Are we breaking anything? (except compliancy) -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of UV Sent: Sunday, June 29, 2008 7:45 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Exchange 2007 UM - DTMF problem Apparently, not only MS do not comply with RFC4733 but also SJphone, Xlite (eyebeam) and Cisco (Call manager, IP phones, etc) amongst others. Is there anyway I can make FS's Duration to start from 0? I'm happy to change the code myself with a little guidance. -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Steve Underwood Sent: Sunday, June 29, 2008 3:42 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Exchange 2007 UM - DTMF problem Hi, Brian West wrote:
So if you can tell me where this is wrong as per 2833 and the
clarification via 4733 ?
rfc4733 obsoletes rfc2833 and says this:
The special duration value of zero is reserved to indicate that the
event lasts "forever", i.e., is a state and is considered to be
effective until updated. A sender MUST NOT transmit a zero duration
for events other than those defined as states. The receiver SHOULD
ignore an event report with zero duration if the event is not a
state.
/b
As well as that definition in RFC4733, they also have an example working in the way the text describes. They send DTMF with a packet rate of one every 50ms. The first packet of the DTMF sequence contains a duration of 400. What does FS actually do when a sequence starts at 0? Does it just drop the first packet, or the whole sequence? If it just drops the first packet, and the far end cares, that's seriously broken on their part. It means a single lost packet screws up the whole sequence. Not good. If FS drops the whole sequence, that might be a little too aggressive. Some will argue that a gateway should be totally transparent in these situations, but total transparency is only workable in simplistic cases. In the end, if MS are doing this you can be sure it will not be fixed, and must be tolerated. Regards, Steve _______________________________________________ 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 -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400 No virus found in this incoming message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.3/1525 - Release Date: 29/06/2008 15:09 No virus found in this incoming message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.3/1525 - Release Date: 29/06/2008 15:09
Wiki updated: http://wiki.freeswitch.org/wiki/Exchange_2007_UM _____ From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of UV Sent: Tuesday, July 01, 2008 4:35 AM To: freeswitch-dev@lists.freeswitch.org Subject: Re: [Freeswitch-dev] Exchange 2007 UM - DTMF problem Amazing. We’ve been running around Microsoft RFC4733 incompatibility issue the whole day after the problem mysteriously disappeared this morning just to find out that this well-encountered bug is solved on restart… Yes, FreeSWITCH DTMF problem with Microsoft Exchange 2007 Unified Messaging Server is solved with a simple server restart (for the Exchange, not the FS). Go figure… BTW, we’ve also confirmed that having it start at zero is the whole problem. But that is not required anymore. _____ From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of UV Sent: Tuesday, July 01, 2008 12:24 AM To: freeswitch-dev@lists.freeswitch.org Subject: Re: [Freeswitch-dev] Exchange 2007 UM - DTMF problem The only way to confirm my hypothesis (which is based on comparative analysis between working “pass-rfc2833=true” and non-working “pass-rfc2833=false” scenarios) is to actually change the code and retest it. We’ll be testing it later today. The code will be changed as described in the previous email. Any comments / recommendations on that? _____ From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Tuesday, July 01, 2008 12:01 AM To: freeswitch-dev@lists.freeswitch.org Subject: Re: [Freeswitch-dev] Exchange 2007 UM - DTMF problem Have you confirmed for sure that having it start at zero is the whole problem? 2008/6/30 UV <uv@talknet.com.au>: I thought of moving this thread over here. We're trying to make the FS work with MS Exchange 2007 (in a non-RFC4733-compliant mode). For this to work, we need to get the Duration count start from 0 instead of starting from 160 (or any other sample rate). We assume these are the lines needed to be changed:
From /src/switch_rtp.c
1042 rtp_session->dtmf_data.out_digit_sofar = samples; 1043 rtp_session->dtmf_data.out_digit_sub_sofar = samples; To /src/switch_rtp.c 1042 rtp_session->dtmf_data.out_digit_sofar = 0; 1043 rtp_session->dtmf_data.out_digit_sub_sofar = 0; Are we missing anything? Are we breaking anything? (except compliancy) -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of UV Sent: Sunday, June 29, 2008 7:45 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Exchange 2007 UM - DTMF problem Apparently, not only MS do not comply with RFC4733 but also SJphone, Xlite (eyebeam) and Cisco (Call manager, IP phones, etc) amongst others. Is there anyway I can make FS's Duration to start from 0? I'm happy to change the code myself with a little guidance. -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Steve Underwood Sent: Sunday, June 29, 2008 3:42 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Exchange 2007 UM - DTMF problem Hi, Brian West wrote:
So if you can tell me where this is wrong as per 2833 and the
clarification via 4733 ?
rfc4733 obsoletes rfc2833 and says this:
The special duration value of zero is reserved to indicate that the
event lasts "forever", i.e., is a state and is considered to be
effective until updated. A sender MUST NOT transmit a zero duration
for events other than those defined as states. The receiver SHOULD
ignore an event report with zero duration if the event is not a
state.
/b
As well as that definition in RFC4733, they also have an example working in the way the text describes. They send DTMF with a packet rate of one every 50ms. The first packet of the DTMF sequence contains a duration of 400. What does FS actually do when a sequence starts at 0? Does it just drop the first packet, or the whole sequence? If it just drops the first packet, and the far end cares, that's seriously broken on their part. It means a single lost packet screws up the whole sequence. Not good. If FS drops the whole sequence, that might be a little too aggressive. Some will argue that a gateway should be totally transparent in these situations, but total transparency is only workable in simplistic cases. In the end, if MS are doing this you can be sure it will not be fixed, and must be tolerated. Regards, Steve _______________________________________________ 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 -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400 No virus found in this incoming message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.3/1525 - Release Date: 29/06/2008 15:09 No virus found in this incoming message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.3/1525 - Release Date: 29/06/2008 15:09 No virus found in this incoming message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.3/1526 - Release Date: 30/06/2008 08:43
Michael, I've looked at the c++ code. Unix has a glob() function in libc that does what the SimpleGlob library does. Seems to work OK. Patch attached (for unix), requires the switch_xml to go from cpp to c, not sure how you want to handle that or if you are willing. I also pulled out switch_cpp.cpp and the language modules from the build and the freeswitch server still starts up OK and loads the other modules. I did not try any calls yet, but the 2.5MBytes libstdc++ is no longer required (I'm trying to squeeze the whole thing into 3MBytes). Do you think you will be able to modify the languages to use plain C as you suggested below. One language would be enough for the embedded world, lua would be my first choice. If not I can always stick to writing C apps. Thanks, Simon
See questions/comments inline
On Jun 29, 2008, at 1:19 PM, Simon Capper wrote:
Is there a way to disable the c++ code in freeswitch without totally breaking it? I'm in an embedded environment and libstdc++ is large and takes up valuable flash space.
We could fairly easily get rid of the cpp wrapper we use for embedded languages, but its used in mod_lua. The other thing you would have to disable would be portions of the switch_xml which uses cpp for the globbing routines which would have to be re-written in c or all of the globbing includes in the xml would have to not be used.
participants (4)
-
Anthony Minessale
-
Michael Jerris
-
Simon Capper
-
UV