[Freeswitch-users] RTP media issue

Mr Nathan Downes nathandownes at hotmail.com
Mon May 28 17:50:56 MSD 2012 

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 at lists.freeswitch.org
[mailto:freeswitch-users-bounces at 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 at 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 at lists.freeswitch.org
[freeswitch-users-bounces at lists.freeswitch.org] f&#246;r Mr Nathan Downes
[nathandownes at 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 at lists.freeswitch.org
[mailto:freeswitch-users-bounces at 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 at 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 at gmail.com
> To: freeswitch-users at lists.freeswitch.org
> CC: nathan at 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 at 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 at freeswitch.org
> http://www.freeswitchsolutions.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 at 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 at freeswitch.org
> http://www.freeswitchsolutions.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 at 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 at hotmail.com
<mailto:MSN%3Aanthony_minessale at hotmail.com> 
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
<mailto:PAYPAL%3Aanthony.minessale at gmail.com> 
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
<mailto:sip%3A888 at conference.freeswitch.org> 
googletalk:conf+888 at conference.freeswitch.org
<mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org> 
pstn:+19193869900 <tel:%2B19193869900> 

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting at freeswitch.org
http://www.freeswitchsolutions.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 at 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 at freeswitch.org
http://www.freeswitchsolutions.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 at 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 at freeswitch.org
http://www.freeswitchsolutions.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 at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20120528/f30fddb3/attachment-0001.html

Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users mailing list