I am not trying to promote any site and our Start Up does not even sell directly to the customer we just develop the technology
We actually trying to promote FreeSWITCH and we have been paying a lot of money to its consultant
I wanted to have an open minded discussion and question every aspect of technology apparently it is not welcomed in here and people get offended by questioning and raising doubts then I will stop

Thanks,
Yiftach.


On Fri, Nov 16, 2012 at 6:44 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:
Why do you keep hijacking peoples threads and starting arguments?  An attempt to promote your site maybe?

This is not even slightly philosophical... No endpoint will tolerate not geting the ACK.  The whole point of it is to make sure 2-way communication has been established.  The ACK contains vial information to set up the call properly and until you have it, you have not completed the call setup..... We will absolutely not try to hack our sip stack.

If you are here to participate in the community, try to help rather than force comments on people and start arguments.  Maybe try listening to the advice people are giving you......





On Fri, Nov 16, 2012 at 3:56 PM, Yiftach Golan <yiftah@choochee.com> 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@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@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@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@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@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@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@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@freeswitch.org <http://consulting@freeswitch.org>  <http://consulting@freeswitch.org>
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@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@freeswitch.org <http://consulting@freeswitch.org>  <http://consulting@freeswitch.org>
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@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@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
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@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
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




--
Anthony Minessale II

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

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

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
googletalk:conf+888@conference.freeswitch.org
pstn:+19193869900

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
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