Re: [Freeswitch-users] RTP media issue
Hi, Made current as requested but nothing works afterwards, freeswitch.log has this in it 2012-05-28 23:39:41.704128 [CRIT] switch_loadable_module.c:1300 Error Loading module /usr/local/freeswitch/mod/mod_sofia.so **/usr/local/freeswitch/mod/mod_sofia.so: undefined symbol: tls_version** Had to copy older version back, lost a few changes from last month L From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Sunday, 27 May 2012 10:29 AM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] RTP media issue Also update, you are running git head so you have to update frequently, you rev is a month old. On May 26, 2012 7:43 AM, "Peter Olsson" <peter.olsson@visionutveckling.se> wrote: I think the first step is to check the actual signalling. Just as Anthony mentions, the call setup looks weird. Between FS and the ATA (if I understood the different IP's/peers correctly) it seems FS sends early media (183), and it takes the ATA 10 seconds to ACK this. During the time the call is answered on the other end, which dosn't seem to be passed to the ATA (probably because it's so late with the ACK - I'm not sure about that though). So, first check this - it seems to me that FS might still be in "early media" state during the entire call. About the actual RTP, I see one problem here, it's packet 8146 in outbound.pcap. This is a packet that is probably generated by FS (since by that exact time, you're missing one packet from the provider), the problem here is that the timestamp if way off (I'm not sure where FS gets this ts from). It's because of this faulty timestamp that a few packets after this is dropped, since FS won't send packets with a lower timestamp than before. This is also why packet 8152 seems to have a strange timestamp, but it's actually just passed from the other leg, and is the first timestamp that is greater then packet 8146. One possible solution would be to enable rewrite of timestamps (rtp-rewrite-timestamps in the sofia config), also mentioned here: http://wiki.freeswitch.org/wiki/RTP_Issues#Dropped_Audio However, I think you also need to check the strangness in the SIP signalling. /Peter ________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Mr Nathan Downes [nathandownes@hotmail.com] Skickat: den 26 maj 2012 00:03 Till: 'FreeSWITCH Users Help' Ämne: Re: [Freeswitch-users] RTP media issue Hi Anthony, FS version = FreeSWITCH Version 1.1.beta1 (git-f1b5044 2012-04-26 11-28-47 -0500) I don't have a debug log, but I could probably get it with another trace of both sides of the call, but it would be hard to capture as there is constant calls to this, unless there is a way to do it on a per call basis? I can also only do testing onsite as we don't have the same fibre equipment. I already have jitterbuffer set in both profiles in an attempt to try and stop it using <param name="auto-jitterbuffer-msec" value="60"/>, is there a way to set the cng_plc in the profile itself rather than diaplpan as there are 70 or so numbers in it. In the outbound dialplans I also added <action application="set" data="sip_jitter_buffer_during_bridge=true" /> because I kept seeing PAUSE JITTERBUFFER in the FS logs when calls were made outbound so I wasn't sure it was doing something and read somewhere it pauses it when it bridges the call The inbound dialplan for all of those people consists of <extension name="02-xxxx-9365" > <condition field="context" expression="public"/> <condition field="destination_number" expression="^02xxxx9365;.*$"> <action application="sleep" data="3000"/> <action application="set" data="domain=mgst.xxxxxxxx.com.au"/> <action application="set" data="domain_name=${domain}"/> <action application="set" data="call_direction=inbound"/> <action application="transfer" data="117 XML mgst.xxxxxxxxx.com.au"/> </condition> </extension> It doesn't affect SIP phones or normal ATA devices we have connected and only affects these FTTH GPON ATA's, but with almost 100 residents in this retirement village and them constantly complaining we have been given til Wednesday to come up with a solution or risk losing our position as the internet/phone provider for that retirement village. It appeared to me that what happens in that trace isn't normal behaviour, I did try rewriting timestamps last week, but as you suggested that appeared to mask the issue but not stop it from happening. That was when I was losing a packet from them each second or so, which by the time it arrived to end user sounded horrible. It has settled down a lot now and maybe 1 or 2 packets per call, but if what is in this trace is the cause each time, that would explain the poor end users experience. -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Saturday, 26 May 2012 2:06 AM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] RTP media issue What version of FS are you running? Do you have the debug logs of those calls? you could try using the jitterbuffer. <action application="cng_plc"/> <action application="set" data="jitterbuffer_msec=60"/> in the inbound DP to FS *before* you answer. Also it looks a little odd to me in this trace if this is the same call, it seems like you answered the call before placing the call to the phone and that phone never answers.... On Thu, May 24, 2012 at 9:51 PM, Nathan Downes <nathandownes@hotmail.com> wrote:
Hi,
enable-soa
<param name="enable-soa" value="true"/>
Set the value to "false" to diable SIP SOA from sofia to tell sofia not to touch the exchange of SDP
I don't think this is related to the exchange of an SDP message.. Can you elaborate more before I try it? I can't make things worse or change things I don't understand.
________________________________ From: djbinter@gmail.com To: freeswitch-users@lists.freeswitch.org CC: nathan@nortec.com.au Subject: Re: [Freeswitch-users] RTP media issue Date: Fri, 25 May 2012 11:19:46 +1000
<param name="enable-soa" value="false"/>
Sent from my iPad
On May 24, 2012, at 5:01 PM, Nathan Downes <nathandownes@hotmail.com> wrote:
Hi,
I had previous reported an issue with poor voice quality, appearing to stem from occasion wrong timestamps coming from provider, but the end user's experience was much worse than what I could see/hear in the trace.
I have finally captured an event inbound and outbound. The thing I don't understand is I thought even though FS proxied the media it didn't touch it or change anything, but it appears it is.
The 2 traces are http://www.nortec.com.au/inbound.pcap.gz and http://www.nortec.com.au/outbound.pcap.gz
Inbound is from my trunk provider to FS box and outbound is FS box to ATA in FTTH GPON.
The event I am talking about, if both traces are open, is in the inbound one inbetween packet 8114 and 8117 the provider drops a packet or I don't receive it. In the corresponding outbound trace, between packet 8144 and 8152, it appears FS misses a whole heap of packets (.1 seconds) between 8146 and 8152 then it increases the timestamp only by 40 rather than 160 on packet 8152. This seems to not affect SIP phones themselves but causes issues with the FTTH GPON ATA.
This causes a gap in the audio for the end user, and when they miss a high number of packets even though it sounds good on the inbound trace the end users experience is horrible. This trace is actually a good one, but the wrong timestamp can occur once per second, causing end user to lose 10%+ of incoming audio only. The issue only affects the audio coming from provider to FS to end user.
I am chasing it up with the voice provider to try and eliminate the occasional packet loss, but if I could stop/fix FS from doing its adjustment/gap/something the end user wouldn't even notice it.
______________________________________________________________________ ___
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
Join Us At ClueCon - Aug 7-9, 2012
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-use rs 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
Join Us At ClueCon - Aug 7-9, 2012
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-use rs 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 <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> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900 <tel:%2B19193869900> _________________________________________________________________________ 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 Join Us At ClueCon - Aug 7-9, 2012 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 Join Us At ClueCon - Aug 7-9, 2012 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 !DSPAM:4fbfffef32764666710318! _________________________________________________________________________ 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 Join Us At ClueCon - Aug 7-9, 2012 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
Did you really do "make current"? Seems there is a linking problem somewhere, but I know for sure current git builds and loads fine. Anyway, about the original issue, did you try using rtp-rewrite-timestamps, to see if that helped? /Peter 28 maj 2012 kl. 16:02 skrev "Mr Nathan Downes" <nathandownes@hotmail.com<mailto:nathandownes@hotmail.com>>: Hi, Made current as requested but nothing works afterwards, freeswitch.log has this in it 2012-05-28 23:39:41.704128 [CRIT] switch_loadable_module.c:1300 Error Loading module /usr/local/freeswitch/mod/mod_sofia.so **/usr/local/freeswitch/mod/mod_sofia.so: undefined symbol: tls_version** Had to copy older version back, lost a few changes from last month… :( From: freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org> [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Sunday, 27 May 2012 10:29 AM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] RTP media issue Also update, you are running git head so you have to update frequently, you rev is a month old. On May 26, 2012 7:43 AM, "Peter Olsson" <peter.olsson@visionutveckling.se<mailto:peter.olsson@visionutveckling.se>> wrote: I think the first step is to check the actual signalling. Just as Anthony mentions, the call setup looks weird. Between FS and the ATA (if I understood the different IP's/peers correctly) it seems FS sends early media (183), and it takes the ATA 10 seconds to ACK this. During the time the call is answered on the other end, which dosn't seem to be passed to the ATA (probably because it's so late with the ACK - I'm not sure about that though). So, first check this - it seems to me that FS might still be in "early media" state during the entire call. About the actual RTP, I see one problem here, it's packet 8146 in outbound.pcap. This is a packet that is probably generated by FS (since by that exact time, you're missing one packet from the provider), the problem here is that the timestamp if way off (I'm not sure where FS gets this ts from). It's because of this faulty timestamp that a few packets after this is dropped, since FS won't send packets with a lower timestamp than before. This is also why packet 8152 seems to have a strange timestamp, but it's actually just passed from the other leg, and is the first timestamp that is greater then packet 8146. One possible solution would be to enable rewrite of timestamps (rtp-rewrite-timestamps in the sofia config), also mentioned here: http://wiki.freeswitch.org/wiki/RTP_Issues#Dropped_Audio However, I think you also need to check the strangness in the SIP signalling. /Peter ________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org> [freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] för Mr Nathan Downes [nathandownes@hotmail.com<mailto:nathandownes@hotmail.com>] Skickat: den 26 maj 2012 00:03 Till: 'FreeSWITCH Users Help' Ämne: Re: [Freeswitch-users] RTP media issue Hi Anthony, FS version = FreeSWITCH Version 1.1.beta1 (git-f1b5044 2012-04-26 11-28-47 -0500) I don't have a debug log, but I could probably get it with another trace of both sides of the call, but it would be hard to capture as there is constant calls to this, unless there is a way to do it on a per call basis? I can also only do testing onsite as we don't have the same fibre equipment. I already have jitterbuffer set in both profiles in an attempt to try and stop it using <param name="auto-jitterbuffer-msec" value="60"/>, is there a way to set the cng_plc in the profile itself rather than diaplpan as there are 70 or so numbers in it. In the outbound dialplans I also added <action application="set" data="sip_jitter_buffer_during_bridge=true" /> because I kept seeing PAUSE JITTERBUFFER in the FS logs when calls were made outbound so I wasn't sure it was doing something and read somewhere it pauses it when it bridges the call The inbound dialplan for all of those people consists of <extension name="02-xxxx-9365" > <condition field="context" expression="public"/> <condition field="destination_number" expression="^02xxxx9365;.*$"> <action application="sleep" data="3000"/> <action application="set" data="domain=mgst.xxxxxxxx.com.au<http://mgst.xxxxxxxx.com.au>"/> <action application="set" data="domain_name=${domain}"/> <action application="set" data="call_direction=inbound"/> <action application="transfer" data="117 XML mgst.xxxxxxxxx.com.au<http://mgst.xxxxxxxxx.com.au>"/> </condition> </extension> It doesn't affect SIP phones or normal ATA devices we have connected and only affects these FTTH GPON ATA's, but with almost 100 residents in this retirement village and them constantly complaining we have been given til Wednesday to come up with a solution or risk losing our position as the internet/phone provider for that retirement village. It appeared to me that what happens in that trace isn't normal behaviour, I did try rewriting timestamps last week, but as you suggested that appeared to mask the issue but not stop it from happening. That was when I was losing a packet from them each second or so, which by the time it arrived to end user sounded horrible. It has settled down a lot now and maybe 1 or 2 packets per call, but if what is in this trace is the cause each time, that would explain the poor end users experience. -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org> [mailto:freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of Anthony Minessale Sent: Saturday, 26 May 2012 2:06 AM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] RTP media issue What version of FS are you running? Do you have the debug logs of those calls? you could try using the jitterbuffer. <action application="cng_plc"/> <action application="set" data="jitterbuffer_msec=60"/> in the inbound DP to FS *before* you answer. Also it looks a little odd to me in this trace if this is the same call, it seems like you answered the call before placing the call to the phone and that phone never answers.... On Thu, May 24, 2012 at 9:51 PM, Nathan Downes <nathandownes@hotmail.com<mailto:nathandownes@hotmail.com>> wrote:
Hi,
enable-soa
<param name="enable-soa" value="true"/>
Set the value to "false" to diable SIP SOA from sofia to tell sofia not to touch the exchange of SDP
I don't think this is related to the exchange of an SDP message.. Can you elaborate more before I try it? I can't make things worse or change things I don't understand.
________________________________ From: djbinter@gmail.com<mailto:djbinter@gmail.com> To: freeswitch-users@lists.freeswitch.org<mailto:freeswitch-users@lists.freeswitch.org> CC: nathan@nortec.com.au<mailto:nathan@nortec.com.au> Subject: Re: [Freeswitch-users] RTP media issue Date: Fri, 25 May 2012 11:19:46 +1000
<param name="enable-soa" value="false"/>
Sent from my iPad
On May 24, 2012, at 5:01 PM, Nathan Downes <nathandownes@hotmail.com<mailto:nathandownes@hotmail.com>> wrote:
Hi,
I had previous reported an issue with poor voice quality, appearing to stem from occasion wrong timestamps coming from provider, but the end user's experience was much worse than what I could see/hear in the trace.
I have finally captured an event inbound and outbound. The thing I don't understand is I thought even though FS proxied the media it didn't touch it or change anything, but it appears it is.
The 2 traces are http://www.nortec.com.au/inbound.pcap.gz and http://www.nortec.com.au/outbound.pcap.gz
Inbound is from my trunk provider to FS box and outbound is FS box to ATA in FTTH GPON.
The event I am talking about, if both traces are open, is in the inbound one inbetween packet 8114 and 8117 the provider drops a packet or I don't receive it. In the corresponding outbound trace, between packet 8144 and 8152, it appears FS misses a whole heap of packets (.1 seconds) between 8146 and 8152 then it increases the timestamp only by 40 rather than 160 on packet 8152. This seems to not affect SIP phones themselves but causes issues with the FTTH GPON ATA.
This causes a gap in the audio for the end user, and when they miss a high number of packets even though it sounds good on the inbound trace the end users experience is horrible. This trace is actually a good one, but the wrong timestamp can occur once per second, causing end user to lose 10%+ of incoming audio only. The issue only affects the audio coming from provider to FS to end user.
I am chasing it up with the voice provider to try and eliminate the occasional packet loss, but if I could stop/fix FS from doing its adjustment/gap/something the end user wouldn't even notice it.
______________________________________________________________________ ___
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto: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
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-use rs http://www.freeswitch.org
______________________________________________________________________ ___ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto: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
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-use rs 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<mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net<http://irc.freenode.net> #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org<mailto:sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900<tel:%2B19193869900> _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto: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 Join Us At ClueCon - Aug 7-9, 2012 FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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<mailto: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 Join Us At ClueCon - Aug 7-9, 2012 FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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<mailto: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 Join Us At ClueCon - Aug 7-9, 2012 FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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 !DSPAM:4fc3827732761296161717! _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto: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 Join Us At ClueCon - Aug 7-9, 2012 FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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 !DSPAM:4fc3827732761296161717!
Lost changes in what? This is the reason I don't like dealing with issues on the list instead of Jira. You need to be able to run git head to reproduce an issue its our standard policy. You should really examine your environment and find out why you can't it may be a clue, you should download and build a fresh git checkout. On May 28, 2012 8:53 AM, "Mr Nathan Downes" <nathandownes@hotmail.com> wrote:
Hi,****
** **
Made current as requested but nothing works afterwards, freeswitch.log has this in it****
** **
2012-05-28 23:39:41.704128 [CRIT] switch_loadable_module.c:1300 Error Loading module /usr/local/freeswitch/mod/mod_sofia.so****
**/usr/local/freeswitch/mod/mod_sofia.so: undefined symbol: tls_version*** ***
** **
Had to copy older version back, lost a few changes from last month… L****
** **
** **
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Anthony Minessale *Sent:* Sunday, 27 May 2012 10:29 AM *To:* FreeSWITCH Users Help *Subject:* Re: [Freeswitch-users] RTP media issue****
** **
Also update, you are running git head so you have to update frequently, you rev is a month old.****
On May 26, 2012 7:43 AM, "Peter Olsson" <peter.olsson@visionutveckling.se> wrote:****
I think the first step is to check the actual signalling.
Just as Anthony mentions, the call setup looks weird. Between FS and the ATA (if I understood the different IP's/peers correctly) it seems FS sends early media (183), and it takes the ATA 10 seconds to ACK this. During the time the call is answered on the other end, which dosn't seem to be passed to the ATA (probably because it's so late with the ACK - I'm not sure about that though). So, first check this - it seems to me that FS might still be in "early media" state during the entire call.
About the actual RTP, I see one problem here, it's packet 8146 in outbound.pcap. This is a packet that is probably generated by FS (since by that exact time, you're missing one packet from the provider), the problem here is that the timestamp if way off (I'm not sure where FS gets this ts from). It's because of this faulty timestamp that a few packets after this is dropped, since FS won't send packets with a lower timestamp than before. This is also why packet 8152 seems to have a strange timestamp, but it's actually just passed from the other leg, and is the first timestamp that is greater then packet 8146.
One possible solution would be to enable rewrite of timestamps (rtp-rewrite-timestamps in the sofia config), also mentioned here: http://wiki.freeswitch.org/wiki/RTP_Issues#Dropped_Audio
However, I think you also need to check the strangness in the SIP signalling.
/Peter
________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [ freeswitch-users-bounces@lists.freeswitch.org] för Mr Nathan Downes [ nathandownes@hotmail.com] Skickat: den 26 maj 2012 00:03 Till: 'FreeSWITCH Users Help' Ämne: Re: [Freeswitch-users] RTP media issue
Hi Anthony,
FS version = FreeSWITCH Version 1.1.beta1 (git-f1b5044 2012-04-26 11-28-47 -0500)
I don't have a debug log, but I could probably get it with another trace of both sides of the call, but it would be hard to capture as there is constant calls to this, unless there is a way to do it on a per call basis? I can also only do testing onsite as we don't have the same fibre equipment. I already have jitterbuffer set in both profiles in an attempt to try and stop it using <param name="auto-jitterbuffer-msec" value="60"/>, is there a way to set the cng_plc in the profile itself rather than diaplpan as there are 70 or so numbers in it. In the outbound dialplans I also added <action application="set" data="sip_jitter_buffer_during_bridge=true" /> because I kept seeing PAUSE JITTERBUFFER in the FS logs when calls were made outbound so I wasn't sure it was doing something and read somewhere it pauses it when it bridges the call
The inbound dialplan for all of those people consists of
<extension name="02-xxxx-9365" > <condition field="context" expression="public"/> <condition field="destination_number" expression="^02xxxx9365;.*$"> <action application="sleep" data="3000"/> <action application="set" data="domain=mgst.xxxxxxxx.com.au"/> <action application="set" data="domain_name=${domain}"/> <action application="set" data="call_direction=inbound"/> <action application="transfer" data="117 XML mgst.xxxxxxxxx.com.au "/> </condition> </extension>
It doesn't affect SIP phones or normal ATA devices we have connected and only affects these FTTH GPON ATA's, but with almost 100 residents in this retirement village and them constantly complaining we have been given til Wednesday to come up with a solution or risk losing our position as the internet/phone provider for that retirement village.
It appeared to me that what happens in that trace isn't normal behaviour, I did try rewriting timestamps last week, but as you suggested that appeared to mask the issue but not stop it from happening. That was when I was losing a packet from them each second or so, which by the time it arrived to end user sounded horrible. It has settled down a lot now and maybe 1 or 2 packets per call, but if what is in this trace is the cause each time, that would explain the poor end users experience.
-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Saturday, 26 May 2012 2:06 AM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] RTP media issue
What version of FS are you running? Do you have the debug logs of those calls?
you could try using the jitterbuffer. <action application="cng_plc"/> <action application="set" data="jitterbuffer_msec=60"/>
in the inbound DP to FS *before* you answer.
Also it looks a little odd to me in this trace if this is the same call, it seems like you answered the call before placing the call to the phone and that phone never answers....
On Thu, May 24, 2012 at 9:51 PM, Nathan Downes <nathandownes@hotmail.com> wrote:
Hi,
enable-soa
<param name="enable-soa" value="true"/>
Set the value to "false" to diable SIP SOA from sofia to tell sofia not to touch the exchange of SDP
I don't think this is related to the exchange of an SDP message.. Can you elaborate more before I try it? I can't make things worse or change things I don't understand.
________________________________ From: djbinter@gmail.com To: freeswitch-users@lists.freeswitch.org CC: nathan@nortec.com.au Subject: Re: [Freeswitch-users] RTP media issue Date: Fri, 25 May 2012 11:19:46 +1000
<param name="enable-soa" value="false"/>
Sent from my iPad
On May 24, 2012, at 5:01 PM, Nathan Downes <nathandownes@hotmail.com> wrote:
Hi,
I had previous reported an issue with poor voice quality, appearing to stem from occasion wrong timestamps coming from provider, but the end user's experience was much worse than what I could see/hear in the trace.
I have finally captured an event inbound and outbound. The thing I don't understand is I thought even though FS proxied the media it didn't touch it or change anything, but it appears it is.
The 2 traces are http://www.nortec.com.au/inbound.pcap.gz and http://www.nortec.com.au/outbound.pcap.gz
Inbound is from my trunk provider to FS box and outbound is FS box to ATA in FTTH GPON.
The event I am talking about, if both traces are open, is in the inbound one inbetween packet 8114 and 8117 the provider drops a packet or I don't receive it. In the corresponding outbound trace, between packet 8144 and 8152, it appears FS misses a whole heap of packets (.1 seconds) between 8146 and 8152 then it increases the timestamp only by 40 rather than 160 on packet 8152. This seems to not affect SIP phones themselves but causes issues with the FTTH GPON ATA.
This causes a gap in the audio for the end user, and when they miss a high number of packets even though it sounds good on the inbound trace the end users experience is horrible. This trace is actually a good one, but the wrong timestamp can occur once per second, causing end user to lose 10%+ of incoming audio only. The issue only affects the audio coming from provider to FS to end user.
I am chasing it up with the voice provider to try and eliminate the occasional packet loss, but if I could stop/fix FS from doing its adjustment/gap/something the end user wouldn't even notice it.
______________________________________________________________________ ___
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
Join Us At ClueCon - Aug 7-9, 2012
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-use rs 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
Join Us At ClueCon - Aug 7-9, 2012
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-use rs 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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
!DSPAM:4fbfffef32764666710318!
_________________________________________________________________________ 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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
-
Mr Nathan Downes
-
Peter Olsson