Lawrence it still does not give an answer what do you do when the BYE does not arrive <br>In this case only one end knows when the call ended <br>The 30 sec disconnecting is very annoying to the users and it creates many problems with your customers<br>
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<br>
As I said there is a lot of philosophy behind it, but I feel that they make a mistake in this point <br> <br><div class="gmail_quote">On Fri, Nov 16, 2012 at 3:23 PM, Lawrence Conroy <span dir="ltr"><<a href="mailto:lconroy@insensate.co.uk" target="_blank">lconroy@insensate.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi There,<br>
um ... the folk who thought up SIP used the Z-pattern for session initiation<br>
to ensure synchronisation between the parties. That's also the reason the path<br>
for the ACK is party-to-party direct, unlike the INVITE/200.<br>
<br>
There's a real good reason for that -- it's a call, so both *ends* need to know<br>
what state they're in -- as everyone here has been telling you.<br>
<br>
Trust me -- I was there, and the discussions were intense/painful.<br>
What you're proposing is exactly what was ditched back in 1997 -- RTP-based<br>
call completion. This is brittle -- it's being carried over UDP.<br>
<br>
No-RTP call abort is useful (check out 3GPP's discussion on this and how IMS<br>
works -- in particular, the discussion on call handling when one end goes into<br>
a tunnel), but it is only a fallback, and is nasty when call & media go<br>
different routes.<br>
<br>
Might I respectfully suggest that, if you think anyone is going to go over<br>
that again to produce a new RFC, you really should cut down on the crack.<br>
<br>
Ignoring failure to receive ACK (after a whole series of attempts) is ignoring<br>
your call control channel being, to use the technical term, b*gg*r*d. Just say no.<br>
<br>
all the best,<br>
Lawrence<br>
<br>
On 16 Nov 2012, at 21:56, Yiftach Golan wrote:<br>
<br>
> This is where I am getting a bit confused, if the 200OK arrived to the<br>
> other side and we checked that the RTP exists (with mod_sofia option) we<br>
> will not get to hours of calls (unless the other side did not hanged up)<br>
> In any case there is a good chance that the BYE is getting lost, so the<br>
> danger exist even without the ACK<br>
><br>
> I am guessing that the designers of the SIP protocol came up with the ACK<br>
> because there is a potential for open dialog that is not bound with time<br>
> and they therefore wanted to know that the other side actually ACKs the<br>
> request, but since ACK is tied to INVITE only (AFAIK) and INVITE always<br>
> tied with RTP (at least in most normal SIP implementations) I'm not sure<br>
> that this ACK is that needed<br>
> but again as I said it is more of philosophical debate, maybe a potential<br>
> request in the new RFC<br>
><br>
> On Fri, Nov 16, 2012 at 12:58 PM, Ken Rice <<a href="mailto:krice@freeswitch.org">krice@freeswitch.org</a>> wrote:<br>
><br>
>> In this case masking the issue can lead to massive bills... Imaging<br>
>> paying by the minute... All of a sudden you are now leaving 2 minute calls<br>
>> up for hours on end... And continuing to get billed for them... Or you are<br>
>> not continuing to bill a customer for them... And now you have unexpected<br>
>> HUGE bills coming in... Masking it is far worse then just fixing it...<br>
>><br>
>> If we mask this one issue, we might as well mask memory leaks, or<br>
>> passwords that don’t work, etc... Sure sometimes we might have to mask an<br>
>> issue for production to work in the short term, but that is never the<br>
>> correct answer fix a problem<br>
>><br>
>><br>
>> On 11/16/12 2:19 PM, "Yiftach Golan" <<a href="mailto:yiftah@choochee.com">yiftah@choochee.com</a>> wrote:<br>
>><br>
>> While I agree on the details I disagree on the solution<br>
>> Sometimes masking the problems can be a good solution but I guess it is a<br>
>> philosophical debate<br>
>><br>
>><br>
>> On Fri, Nov 16, 2012 at 10:27 AM, Ken Rice <<a href="mailto:krice@freeswitch.org">krice@freeswitch.org</a>> wrote:<br>
>><br>
>> That leaves to big a risk of open sessions and only masks the true issue<br>
>> which is a problem with FS getting the ACK back...<br>
>><br>
>> Theres a reason FS is not getting the ACK, and FS will make several<br>
>> attempts to get an ack by retransmitting the 200 OK several times before<br>
>> that timeout occurs.<br>
>><br>
>> The real fix here is to fix the underlying cause, not masking it....<br>
>><br>
>><br>
>> On 11/16/12 11:45 AM, "Yiftach Golan" <<a href="mailto:yiftah@choochee.com">yiftah@choochee.com</a> <<br>
>> <a href="http://yiftah@choochee.com" target="_blank">http://yiftah@choochee.com</a>> > wrote:<br>
>><br>
>> I know that it is kind out of the what RFC3261 instructs, but did anyone<br>
>> think on giving the option in configuration not to hang up calls in case of<br>
>> an ACK does not arrive?<br>
>> I know that it has the risk of open sessions but there some other ways to<br>
>> handle those cases<br>
>><br>
>> On Thu, Nov 15, 2012 at 6:35 PM, Ken Rice <<a href="mailto:krice@freeswitch.org">krice@freeswitch.org</a> <<br>
>> <a href="http://krice@freeswitch.org" target="_blank">http://krice@freeswitch.org</a>> > wrote:<br>
>><br>
>> This is probably the same scenario as this is exactly what to expect...<br>
>> Call gets answered far end doesn’t ACK FS sending them a 200OK , fs hangsup<br>
>> the call....<br>
>><br>
>> Quite common on networks with NAT issues or broken endpoints<br>
>><br>
>><br>
>> On 11/15/12 7:43 PM, "Vitalie Colosov" <<a href="mailto:vetali100@gmail.com">vetali100@gmail.com</a> <<br>
>> <a href="http://vetali100@gmail.com" target="_blank">http://vetali100@gmail.com</a>> <<a href="http://vetali100@gmail.com" target="_blank">http://vetali100@gmail.com</a>> > wrote:<br>
>><br>
>> I saw this happened earlier when the remote party does not send SIP ACK<br>
>> after receiving SIP OK, so the call is being disconnected after exactly 32<br>
>> seconds.<br>
>> Not sure if this is exact same scenario here, but just something to<br>
>> consider...<br>
>><br>
>> Regards.<br>
>> Vitalie<br>
>><br>
>><br>
>> 2012/11/15 kaleem rehman <<a href="mailto:k4kaleem@gmail.com">k4kaleem@gmail.com</a> <<a href="http://k4kaleem@gmail.com" target="_blank">http://k4kaleem@gmail.com</a>><br>
>> <<a href="http://k4kaleem@gmail.com" target="_blank">http://k4kaleem@gmail.com</a>> ><br>
>><br>
>> Hi All,<br>
>><br>
>> my inbound calls are fine with no issues, my outbound calls get<br>
>> disconnected after 32 seconds and its on all calls. i tried 2 different<br>
>> suppliers and its same result.<br>
>> please find the attached log file with sofia in debug mode. - caller was<br>
>> extension 1234 and desination was 01908321682<br>
>><br>
>> your help will be greately appreciated.<br>
>><br>
>> regards,<br>
>> Kaleem<br>
>><br>
>> _________________________________________________________________________<br>
>> Professional FreeSWITCH Consulting Services:<br>
>> <a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a> <<a href="http://consulting@freeswitch.org" target="_blank">http://consulting@freeswitch.org</a>> <<br>
>> <a href="http://consulting@freeswitch.org" target="_blank">http://consulting@freeswitch.org</a>><br>
>> <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
>><br>
>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
>> <a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
>><br>
>> Official FreeSWITCH Sites<br>
>> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
>> <a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
>> <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
>><br>
>> FreeSWITCH-users mailing list<br>
>> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a> <<br>
>> <a href="http://FreeSWITCH-users@lists.freeswitch.org" target="_blank">http://FreeSWITCH-users@lists.freeswitch.org</a>> <<br>
>> <a href="http://FreeSWITCH-users@lists.freeswitch.org" target="_blank">http://FreeSWITCH-users@lists.freeswitch.org</a>><br>
>> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
>> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
>> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
>><br>
>><br>
>><br>
>> ------------------------------<br>
>> _________________________________________________________________________<br>
>> Professional FreeSWITCH Consulting Services:<br>
>> <a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a> <<a href="http://consulting@freeswitch.org" target="_blank">http://consulting@freeswitch.org</a>> <<br>
>> <a href="http://consulting@freeswitch.org" target="_blank">http://consulting@freeswitch.org</a>><br>
>> <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
>><br>
>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
>> <a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
>><br>
>> Official FreeSWITCH Sites<br>
>> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
>> <a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
>> <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
>><br>
>> FreeSWITCH-users mailing list<br>
>> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a> <<br>
>> <a href="http://FreeSWITCH-users@lists.freeswitch.org" target="_blank">http://FreeSWITCH-users@lists.freeswitch.org</a>> <<br>
>> <a href="http://FreeSWITCH-users@lists.freeswitch.org" target="_blank">http://FreeSWITCH-users@lists.freeswitch.org</a>><br>
>> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
>> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
>> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
>><br>
>><br>
>> --<br>
>> Ken<br>
>> *<a href="http://www.FreeSWITCH.org" target="_blank">http://www.FreeSWITCH.org</a><br>
>> <a href="http://www.ClueCon.com" target="_blank">http://www.ClueCon.com</a><br>
>> <a href="http://www.OSTAG.org" target="_blank">http://www.OSTAG.org</a><br>
>> *<a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a> #freeswitch<br>
>><br>
>> _________________________________________________________________________<br>
>> Professional FreeSWITCH Consulting Services:<br>
>> <a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
>> <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
>><br>
>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
>> <a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
>><br>
>> Official FreeSWITCH Sites<br>
>> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
>> <a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
>> <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
>><br>
>> FreeSWITCH-users mailing list<br>
>> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
>> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
>> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
>> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
>><br>
>><br>
> _________________________________________________________________________<br>
> Professional FreeSWITCH Consulting Services:<br>
> <a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
> <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
><br>
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
> <a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
><br>
> Official FreeSWITCH Sites<br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
> <a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
> <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
><br>
> FreeSWITCH-users mailing list<br>
> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
<br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br>