I am using a bit older version of FreeSWITCH but I think I saw it with Astra as well :<br>/* INVITE in progress? */<br>if (sr-&gt;sr_usage == du &amp;&amp; sr-&gt;sr_method == sip_method_invite &amp;&amp; nua_server_request_is_pending(sr))<br>
{<br>      return nua_client_return(cr, SIP_491_REQUEST_PENDING, msg);<br>}<br><br>The problem is with the (&quot;nua_server_request_is_pending&quot;) : <br>/** Return true if we have not sent final response to request */<br>
su_inline int nua_server_request_is_pending(nua_server_request_t const *sr)<br>{<br>      return sr &amp;&amp; sr-&gt;sr_response.msg;<br>}<br><br>You did not send the initial invite in the Jira so I do not know if the initial request constructed correctly<br>
but judging by the code it looks like your request is still pending when the second invite arrives <br><br>Thanks,<br>Yiftach.<br><br><div class="gmail_quote">On Tue, Oct 23, 2012 at 9:10 AM, Phil Quesinberry <span dir="ltr">&lt;<a href="mailto:philq@qsystemsengineering.com" target="_blank">philq@qsystemsengineering.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;m experiencing an odd issue here where a direct media call (bypass media<br>
mode) between two Aastra endpoints is disconnected when one of the endpoints<br>
sends a re-invite 2 minutes into the call, presumably to refresh the session<br>
- RTP ports &amp; codecs remain unchanged.<br>
<br>
FreeSWITCH passes the invite on to the other endpoint which replies with its<br>
own invite, again keeping the same call parameters, ports/codecs etc.<br>
<br>
FS then sends a 491 - Request Pending to both endpoints, acknowledges the<br>
second endpoint&#39;s invite and tears down the call.  This seems wrong. is this<br>
expected behavior?  I went ahead and filed a Jira on this just in case - it<br>
includes all trace info:<br>
<a href="http://jira.freeswitch.org/browse/FS-4754" target="_blank">http://jira.freeswitch.org/browse/FS-4754</a><br>
<br>
<br>
Phil Quesinberry<br>
Q Systems Engineering, Inc.<br>
Electronic Controls and Embedded Systems Development<br>
<a href="tel:%28410%29%20969-8002" value="+14109698002">(410) 969-8002</a><br>
<a href="http://www.qsystemsengineering.com" target="_blank">http://www.qsystemsengineering.com</a><br>
<br>
<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>