Here is the reason from the RFC3261 : <br> "...The reason for this separation is rooted in the importance of<br> delivering all 200 (OK) responses to an INVITE to the UAC. To<br> deliver them all to the UAC, the UAS alone takes responsibility<br>
for retransmitting them (see Section 13.3.1.4), and the UAC alone<br> takes responsibility for acknowledging them with ACK (see Section<br> 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is<br>
effectively considered its own transaction..."<br> <br><div class="gmail_quote">On Fri, Nov 16, 2012 at 3:50 PM, Yiftach Golan <span dir="ltr"><<a href="mailto:yiftah@choochee.com" target="_blank">yiftah@choochee.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes I you are right if the RTP is not tied with SIP this theory is not really valid <br>But this is again true about BYE that does not reach to the destination so the risk of not closing the dialog still exist<br>
In most of the voice implementation that I saw there are three options : <br>
1. Softswitch (FreeSWITCH, Asterisk, etc)<br>2. MGW (Avaya, Cisco, etc)<br>3. Media release but only between two phones <br>You can tie your RTP to the SIP with option 1 and option 2 <br>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 <br>
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 <br> <br><div class="gmail_quote">On Fri, Nov 16, 2012 at 2:31 PM, Sergey Okhapkin <span dir="ltr"><<a href="mailto:sos@sokhapkin.dyndns.org" target="_blank">sos@sokhapkin.dyndns.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Don't mix signaling (SIP) and media (RTP). Signaling and media could run<br>
different ways. Why do you think FS will always be in media path?<br>
<br>
On Friday 16 November 2012 14:56:58 Yiftach Golan wrote:<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" target="_blank">krice@freeswitch.org</a>> wrote:<br>
> > In this case masking the issue can lead to massive bills... Imaging<br>
> ><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" target="_blank">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" target="_blank">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" target="_blank">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<br>
> > 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" target="_blank">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<br>
> > 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" target="_blank">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" target="_blank">k4kaleem@gmail.com</a> <<a href="http://k4kaleem@gmail.com" target="_blank">http://k4kaleem@gmail.com</a>><br>
> ><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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">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" target="_blank">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>
</blockquote></div><br>