[Freeswitch-users] Conference silence timeouts

Fri Aug 14 12:17:35 PDT 2009

That sounds horrible.  There are settings both in sip/rtp and in  
conference to do this already.

http://wiki.freeswitch.org/wiki/Sofia_Configuration_Files#enable-timer
http://wiki.freeswitch.org/wiki/Sofia_Configuration_Files#session-timeout
http://wiki.freeswitch.org/wiki/Sofia_Configuration_Files#rtp-timeout-sec
http://wiki.freeswitch.org/wiki/Sofia_Configuration_Files#rtp-hold-timeout-sec
http://wiki.freeswitch.org/wiki/VAD_and_CNG

Mike

On Aug 14, 2009, at 2:41 PM, Bradley Brashier wrote:

> I didn't see any SIP session timers in the wiki. Since I'm already  
> using the event socket for control, my current plan is to use  
> sched_api to play a file with a short (20ms?) clip of silence,  
> capture the play_file event and use it to reschule another one for a  
> couple of seconds later.
>
> I'll let you know what happens.
>
> BB
>
> On Thu, Aug 13, 2009 at 10:47 PM, Michael Jerris <mike at jerris.com>  
> wrote:
> 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 <bjbrashier at 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 <bjbrashier at 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 <mike at 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  
>>> <msc at 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 <bjbrashier at 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 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
>
>
> _______________________________________________
> 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/20090814/7c6f6501/attachment-0002.html 