[Freeswitch-users] call disconnects after 32 seconds

Sun Nov 18 00:45:52 MSK 2012

Great.. The best news is that the reporter found his problem and fixed it
despite the tangents......
On Nov 17, 2012 2:33 PM, "Yiftach Golan" <yiftah at choochee.com> wrote:

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