My suggestion is to use sip session timers not rtp timeouts as rtp is
supposed to be discontinuous. That being said, we have several
settings to continuously send media, but then you are doing exactly
what you said you didn't want to do.
Mike
On Aug 13, 2009, at 6:24 PM, Bradley Brashier wrote:
OK, I finally got a moment to do a packet capture and take a look at
the streams. It became very clear very quickly that what happens is
that during silence the gateway still sends RTP packets to
Freeswitch, but Freeswitch doesn't send any back to the gateway.
After 10s of this, the gateway says "Oh, the RPT must be broken" and
it hangs up.
We found a way to turn off this behavior in the gateway, and the
good news is that it did indeed fix the problem. But we'd rather not
rely on that as a long-term solution because then we can't detect
and drop RTP streams that really are broken.
So now I'm back to looking at Freeswitch to figure out how to send
just a single packet every second or so during silence. If anyone
knows of a way to do this, let me know, otherwise I'll get back to
you if and when I find one.
BB
On Thu, Aug 13, 2009 at 2:48 PM, Bradley Brashier <bjbrash...@gmail.com
> wrote:
I took a closer look at the SIP messages on the console. From it, I
understand that it's not Freeswitch timing out, but rather FS is
getting the "BYE" msg from somewhere else. I've tested phones and
tested calling without going through the FS conference, though, and
everything works fine. Then I saw something else odd inside the BYE
msg:
Reason: Q.850 ;cause=31 ;text="RTP Broken Connection"
So I Googled "RTP Broken Connection" and saw several sites talking
about AudioCodes gateways and Asterisk -- and our gateway is an
AudioCodes. From these sites it sounds like AudioCodes is rather
aggressive in detecting RTP breaks, and is interpreting the silence
from FS as a break.
So now I'm looking into ways to maybe send "I'm still here" RTP
packets from FS or to tune the gateway to be less aggressive. I
can't stop and get a clean packet capture right now because I've got
a bunch of testers working on it today. I'll do that sometime when
the system is less busy.
BB
On Thu, Aug 13, 2009 at 1:45 PM, Bradley Brashier <bjbrash...@gmail.com
> wrote:
I had just thought of the exact same thing. I'm trying to test that
now. Thanks for your input.
BB
On Thu, Aug 13, 2009 at 1:20 PM, Michael Jerris <m...@jerris.com>
wrote:
My guess is that its the other end killing the call due to rtp
timeouts, not us killing the call. If you can confirm this the best
method would be to get them not to do rtp timeouts.
On Aug 13, 2009, at 1:47 PM, Bradley Brashier wrote:
I'm sure that would work, but I'm worried about it sucking up
bandwidth, especially since you'd need it on every caller (since
otherwise the one person who had it could hang up and you'd be back
to square 1).
Any other ideas, or should I hunt through the code to try to
override the behavior manually?
BB
On Thu, Aug 13, 2009 at 9:50 AM, Michael Collins
<m...@freeswitch.org> wrote:
Check out the 'waste' member flag. I think if at least one member
has that set then RTP will get sent out even during silence. Let us
know if that helps...
-MC
On Thu, Aug 13, 2009 at 11:37 AM, Bradley Brashier <bjbrash...@gmail.com
> wrote:
Hi all.
The solution to this one should be short.
My conference hangs up when there's 2+ users and silence for 5 sec
or so. I'm trying to find a parameter that changes that (I'd rather
it be, say, 60 seconds).
I didn't see a parameter like this specific to conferences, so I
looked abroad a bit. I found rtp-timeout-sec in sip_profiles, but
it's set to 300 (the default), so I'm pretty sure that's not the
problem. I also searched through the mod_conference.c code and
didn't see it, though I was only skimming.
I'm not 100% convinced that this is limited to conferences, but I
don't currently have a way to test in a non-conference environment.
Anybody know how to increase the conference silence-hangup timeout?
BB
_____
_______________________________________________
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