[Freeswitch-users] call disconnects after 32 seconds

Sat Nov 17 21:17:33 MSK 2012

Again Anthony I am not trying to push you to change anything just wanted to
have a discussion if I want to change anything I would change in the code
by myself
You are looking for an ulterior motive when there is none
I get it that you want this forum to be more questions and answers about
FreeSWITCH configurations and as I stated  before I will not correct people
or give my thoughts on what I think even if they are missing some facts in
their assumptions (including in this mail) which they consider as premise

On Sat, Nov 17, 2012 at 7:21 AM, Anthony Minessale <
anthony.minessale at gmail.com> wrote:

> 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
>
> _________________________________________________________________________
> 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/14bf6893/attachment-0001.html 