[Freeswitch-users] call disconnects after 32 seconds

Sat Nov 17 18:21:22 MSK 2012

The only reason that there would be a failure to get the ACK would be if
the 2 endpoints have lost communication.
If you can't get an ACK to the host, you can't get a BYE to them either.
 Even if you hacked it to tolerate no ACK, the session timers would fail in
another 30 seconds.

You are just focused on your business needs and just disregarding logic.
 You ask if you are missing something and several individuals are telling
you YES.  This is the 4th time I am telling you that you should focus
your enthusiasm on learning rather than affirming a m00t point because we
are not going to change the behavior.

I have not seen a seen a single case of missing ACK that did not point out
a real problem that can be simply fixed by either using some NAT related
configuration and proper formed Contact hosts.

If this argument continues it will be ended with moderation.....

On Fri, Nov 16, 2012 at 6:07 PM, Yiftach Golan <yiftah at choochee.com> wrote:

> Here is the reason from the RFC3261 :
>    "...The reason for this separation is rooted in the importance of
>       delivering all 200 (OK) responses to an INVITE to the UAC.  To
>       deliver them all to the UAC, the UAS alone takes responsibility
>       for retransmitting them (see Section 13.3.1.4), and the UAC alone
>       takes responsibility for acknowledging them with ACK (see Section
>       13.2.2.4).  Since this ACK is retransmitted only by the UAC, it is
>       effectively considered its own transaction..."
>
>
> On Fri, Nov 16, 2012 at 3:50 PM, Yiftach Golan <yiftah at choochee.com>wrote:
>
>> Yes I you are right if the RTP is not tied with SIP this theory is not
>> really valid
>> But this is again true about BYE that does not reach to the destination
>> so the risk of not closing the dialog still exist
>> In most of the voice implementation that I saw there are three options :
>> 1. Softswitch (FreeSWITCH, Asterisk, etc)
>> 2. MGW (Avaya, Cisco, etc)
>> 3. Media release but only between two phones
>> You can tie your RTP to the SIP with option 1 and option 2
>> Option 3 is the problematic one but you will never release your media for
>> billing purpose so usually your risk will be extension to extension open
>> dialog which is less riskier
>> Again as I said it is pretty philosophical debate but from my long
>> experience in SIP I do not think that there is a practical use for it but
>> maybe I am missing something
>>
>> On Fri, Nov 16, 2012 at 2:31 PM, Sergey Okhapkin <
>> sos at sokhapkin.dyndns.org> wrote:
>>
>>>  Don't mix signaling (SIP) and media (RTP). Signaling and media could run
>>> different ways. Why do you think FS will always be in media path?
>>>
>>> On Friday 16 November 2012 14:56:58 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
>
>

-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
pstn:+19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20121117/8659903d/attachment-0001.html 