[Freeswitch-users] call disconnects after 32 seconds

Sat Nov 17 18:57:52 MSK 2012

Check SIP session timers which are fully supported in FreeSWITCH.

On Sat, Nov 17, 2012 at 1:40 AM, Yiftach Golan <yiftah at choochee.com> wrote:

> Lawrence it still does not give an answer what do you do when the BYE does
> not arrive
> In this case only one end knows when the call ended
> The 30 sec disconnecting is very annoying to the users and it creates many
> problems with your customers
> When you disconnect the call it is much more problematic then a call that
> did not established, further more most of the HA systems are working well
> before the call is established, once it is established the HA no longer
> available
> As I said there is a lot of philosophy behind it, but I feel that they
> make a mistake in this point
>
> On Fri, Nov 16, 2012 at 3:23 PM, Lawrence Conroy <lconroy at insensate.co.uk>wrote:
>
>> Hi There,
>>  um ... the folk who thought up SIP used the Z-pattern for session
>> initiation
>> to ensure synchronisation between the parties. That's also the reason the
>> path
>> for the ACK is party-to-party direct, unlike the INVITE/200.
>>
>> There's a real good reason for that -- it's a call, so both *ends* need
>> to know
>> what state they're in -- as everyone here has been telling you.
>>
>> Trust me -- I was there, and the discussions were intense/painful.
>> What you're proposing is exactly what was ditched back in 1997 --
>> RTP-based
>> call completion. This is brittle -- it's being carried over UDP.
>>
>> No-RTP call abort is useful (check out 3GPP's discussion on this and how
>> IMS
>> works -- in particular, the discussion on call handling when one end goes
>> into
>> a tunnel), but it is only a fallback, and is nasty when call & media go
>> different routes.
>>
>> Might I respectfully suggest that, if you think anyone is going to go over
>> that again to produce a new RFC, you really should cut down on the crack.
>>
>> Ignoring failure to receive ACK (after a whole series of attempts) is
>> ignoring
>> your call control channel being, to use the technical term, b*gg*r*d.
>> Just say no.
>>
>> all the best,
>>   Lawrence
>>
>> On 16 Nov 2012, at 21:56, Yiftach Golan wrote:
>>
>> > 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
>>
>>
>> _________________________________________________________________________
>> 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/20121117/8e7ad956/attachment-0001.html 