Going back a step, to where Jon was seeing more packets than there
should have been, I've just encountered a similar issue having upgraded
to the latest, from what was probably a fairly old release - months old,
rather than weeks.
I've got two FS boxes (let's call them FS1 and FS2), each of which are
plumbed in to carrier C. There's an IVR service running on FS1; FS2
bridges any calls which it gets for said IVR over to FS1. What I've
just had
is:
- calls from C to FS1 directly work fine;
- calls from C to FS2, thence to FS1 were silent. Looking at a
capture from
FS2, everything looks OK except the RTP between FS1 and FS2. On answer,
there's a prompt played. What I see is three packets in a lump from
FS1, then
four packets sent back from FS2 to FS1, four packets in a lump from
FS1, then
five going back from FS2 to FS1, and so on.
The lumps are 20ms apart (codec is G711 with 20ms packets) - what
seems to be
happening is that FS2 sends FS1 back the packets received from it
unchanged
plus an extra packet which has arrived from C in the meantime.
FS2 ought to be sending these packets to C instead; it sends C nothing.
I've made the problem go away by commenting out the bit in
switch_rtp.c which
auto-adjusts addresses (around line 1280.)
All of the machines have public IPs; there's not a NAT in sight.
I'll have a further look in the morning.
--Dave
%(60000,0,300) means to generate a 60 second long 300hz tone
%(5,0,300) means a 5 ms long 300hz tone
if you are just trying to send a tone you are better off with
<action application="gentones" data="%(1000,0,300)|60"/>
which only generates 1 second of audio then buffers and loops it via
the application
rather than allocating enough room for 60 seconds of signed linear
audio and generating
the whole 60 seconds into memory for no reason vs 1 second sample
looped 60 times.
No matter what you do it will not effect the bandwidth used, it's a
factor of what codec you are using.
On Mon, Oct 6, 2008 at 4:15 AM, Jon Bruel <[EMAIL PROTECTED]> wrote:
Resolved: I have made further tests, and my final conclusion is that
the
previous stated test results were screwed by the application
'gentones'.
This application does in some cases send more rtp than expected. If I
used:
<action application="gentones" data="%(5,0,300)"/>
<action application="gentones" data="%(5,0,300)"/>
<action application="gentones" data="%(60000,0,300)"/>
the expected rtp of 8600 kB/s was transmitted. If I used
<action application="gentones" data="%(60000,0,300)"/>
<action application="gentones" data="%(5,0,300)"/>
<action application="gentones" data="%(5,0,300)"/>.
the rtp was 34600 kB/s, and the memory is heavily consumed. The only
difference being the sequence of the gentones commands. I don't know
if
this is the expected behaviour of 'gentones' or not, but it certainly
screwed up the results previously posted. /Jon
_______________________________________________
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
--
Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
AIM: anthm
MSN:[EMAIL PROTECTED]
GTALK/JABBER/PAYPAL:[EMAIL PROTECTED]
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:[EMAIL PROTECTED]
iax:[EMAIL PROTECTED]/888
googletalk:[EMAIL PROTECTED]
pstn:213-799-1400
_______________________________________________
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
_______________________________________________
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
