[Freeswitch-users] call disconnects after 32 seconds

Sat Nov 17 02:18:23 MSK 2012

What if RTP does not flow via FreeSWITCH but directly between the
endpoints. Then ACK is the only way to send a signal that endpoint started
to send RTP.
Not sure if it sends ACK before starting sending RTP or after... or it is
really not related to RTP, if so - why indeed ACK is needed?

2012/11/16 Yiftach Golan <yiftah at choochee.com>

> This is where I am getting a bit confused, if the 200OK arrived to the
> other side and we checked that the RTP exists (with mod_sofia option) we
> will not get to hours of calls (unless the other side did not hanged up)
> In any case there is a good chance that the BYE is getting lost, so the
> danger exist even without the ACK
>
> I am guessing that the designers of the SIP protocol came up with the ACK
> because there is a potential for open dialog that is not bound with time
> and they therefore wanted to know that the other side actually ACKs the
> request, but since ACK is tied to INVITE only (AFAIK) and INVITE always
> tied with RTP (at least in most normal SIP implementations) I'm not sure
> that this ACK is that needed
> but again as I said it is more of philosophical debate, maybe a potential
> request in the new RFC
>
> On Fri, Nov 16, 2012 at 12:58 PM, Ken Rice <krice at freeswitch.org> wrote:
>
>>  In this case masking the issue can lead to massive bills... Imaging
>> paying by the minute... All of a sudden you are now leaving 2 minute calls
>> up for hours on end... And continuing to get billed for them... Or you are
>> not continuing to bill a customer for them... And now you have unexpected
>> HUGE bills coming in... Masking it is far worse then just fixing it...
>>
>> If we mask this one issue, we might as well mask memory leaks, or
>> passwords that don’t work, etc... Sure sometimes we might have to mask an
>> issue for production to work in the short term, but that is never the
>> correct answer fix a problem
>>
>>
>> On 11/16/12 2:19 PM, "Yiftach Golan" <yiftah at choochee.com> wrote:
>>
>> While I agree on the details I disagree on the solution
>> Sometimes masking the problems can be a good solution but I guess it is a
>> philosophical debate
>>
>>
>> On Fri, Nov 16, 2012 at 10:27 AM, Ken Rice <krice at freeswitch.org> wrote:
>>
>> That leaves to big a risk of open sessions and only masks the true issue
>> which is a problem with FS getting the ACK back...
>>
>> Theres a reason FS is not getting the ACK, and FS will make several
>> attempts to get an ack by retransmitting the 200 OK several times before
>> that timeout occurs.
>>
>> The real fix here is to fix the underlying cause, not masking it....
>>
>>
>> On 11/16/12 11:45 AM, "Yiftach Golan" <yiftah at choochee.com <
>> http://yiftah@choochee.com> > wrote:
>>
>> I know that it is kind out of the what RFC3261 instructs, but did anyone
>> think on giving the option in configuration not to hang up calls in case of
>> an ACK does not arrive?
>> I know that it has the risk of open sessions but there some other ways to
>> handle those cases
>>
>> On Thu, Nov 15, 2012 at 6:35 PM, Ken Rice <krice at freeswitch.org <
>> http://krice@freeswitch.org> > wrote:
>>
>> This is probably the same scenario as this is exactly what to expect...
>> Call gets answered far end doesn’t ACK FS sending them a 200OK , fs hangsup
>> the call....
>>
>> Quite common on networks with NAT issues or broken endpoints
>>
>>
>> On 11/15/12 7:43 PM, "Vitalie Colosov" <vetali100 at gmail.com <
>> http://vetali100@gmail.com>  <http://vetali100@gmail.com> > wrote:
>>
>> I saw this happened earlier when the remote party does not send SIP ACK
>> after receiving SIP OK, so the call is being disconnected after exactly 32
>> seconds.
>> Not sure if this is exact same scenario here, but just something to
>> consider...
>>
>> Regards.
>> Vitalie
>>
>>
>> 2012/11/15 kaleem rehman <k4kaleem at gmail.com <http://k4kaleem@gmail.com>
>>  <http://k4kaleem@gmail.com> >
>>
>> Hi All,
>>
>> my inbound calls are fine with no issues, my outbound calls get
>> disconnected after 32 seconds and its on all calls. i tried 2 different
>> suppliers and its same result.
>> please find the attached log file with sofia in debug mode. - caller was
>> extension 1234 and desination was 01908321682
>>
>> your help will be greately appreciated.
>>
>> regards,
>> Kaleem
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org <http://consulting@freeswitch.org>  <
>> http://consulting@freeswitch.org>
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org <
>> http://FreeSWITCH-users@lists.freeswitch.org>  <
>> http://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 at freeswitch.org <http://consulting@freeswitch.org>  <
>> http://consulting@freeswitch.org>
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org <
>> http://FreeSWITCH-users@lists.freeswitch.org>  <
>> http://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
>>
>>
>> --
>> Ken
>> *http://www.FreeSWITCH.org
>> http://www.ClueCon.com
>> http://www.OSTAG.org
>> *irc.freenode.net #freeswitch
>>
>> _________________________________________________________________________
>> 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
>>
>> 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
>
> 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/20121116/9ca4ecb0/attachment.html 