[Freeswitch-users] call disconnects after 32 seconds

[Lawrence Conroy]

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