call disconnects after 32 seconds
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
Get a SIP capture of this call as well. It might yield a clue. -MC On Thu, Nov 15, 2012 at 3:22 PM, kaleem rehman <k4kaleem@gmail.com> wrote:
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://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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
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>
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://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
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> 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>
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://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
-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch
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> 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> 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>
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://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
-- 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
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> 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> 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> > 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> >
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://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://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://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://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
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> 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> 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> > 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> >
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://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://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://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://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
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
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
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 13: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@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>
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
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@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@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>
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
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@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@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@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>
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
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@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@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@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@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>
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
_________________________________________________________________________ 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
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@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@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@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@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@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>
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
_________________________________________________________________________ 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
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@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@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@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@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@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@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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
What if RTP does not flow via FreeSWITCH but directly between the endpoints. Then ACK is the only way to send a signal that endpoint started to send RTP. Not sure if it sends ACK before starting sending RTP or after... or it is really not related to RTP, if so - why indeed ACK is needed? 2012/11/16 Yiftach Golan <yiftah@choochee.com>
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
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@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
Lawrence it still does not give an answer what do you do when the BYE does not arrive In this case only one end knows when the call ended The 30 sec disconnecting is very annoying to the users and it creates many problems with your customers When you disconnect the call it is much more problematic then a call that did not established, further more most of the HA systems are working well before the call is established, once it is established the HA no longer available As I said there is a lot of philosophy behind it, but I feel that they make a mistake in this point On Fri, Nov 16, 2012 at 3:23 PM, Lawrence Conroy <lconroy@insensate.co.uk>wrote:
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@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
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
_________________________________________________________________________ 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
Check SIP session timers which are fully supported in FreeSWITCH. On Sat, Nov 17, 2012 at 1:40 AM, Yiftach Golan <yiftah@choochee.com> wrote:
Lawrence it still does not give an answer what do you do when the BYE does not arrive In this case only one end knows when the call ended The 30 sec disconnecting is very annoying to the users and it creates many problems with your customers When you disconnect the call it is much more problematic then a call that did not established, further more most of the HA systems are working well before the call is established, once it is established the HA no longer available As I said there is a lot of philosophy behind it, but I feel that they make a mistake in this point
On Fri, Nov 16, 2012 at 3:23 PM, Lawrence Conroy <lconroy@insensate.co.uk>wrote:
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@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
_________________________________________________________________________ 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
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
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
dont forget that sip and rtp do not nessecarily go through the same hosts on the same call... how can you monitor rtp on a host if the rtp never goes there Ken Sent from my iPad On 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
I do not want to continue this discussion because apparently it hurts people when you have different opinion if you would like to have a fact base discussion with no personal offenses we can continue talking about it through are private mails On Fri, Nov 16, 2012 at 7:31 PM, Ken Rice <krice@freeswitch.org> wrote:
dont forget that sip and rtp do not nessecarily go through the same hosts on the same call... how can you monitor rtp on a host if the rtp never goes there
Ken Sent from my iPad
On 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
_________________________________________________________________________ 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
participants (9)
-
Anthony Minessale
-
kaleem rehman
-
Ken Rice
-
Lawrence Conroy
-
Michael Collins
-
Ognjen Seslija
-
Sergey Okhapkin
-
Vitalie Colosov
-
Yiftach Golan