[Freeswitch-users] call disconnects after 32 seconds

Sat Nov 17 03:40:10 MSK 2012

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20121116/c0a1d07b/attachment.html 