First of all check all network nodes (switches, routers,...) and check whether the SIP signalling is OK in terms of NAT handling. Your problem is that an ACK is lost and the session is torn down, this behaviour is OK.<br><br>
If everything is OK, I would recommend that you use 1.4.18 because the NAT handling is better. I've seen that from 1.4.18 there's a problem but I don't know enough about the * internals to know where it is (i tried 1.4.20,1.4.22, 1.4.23)<br>
<br>The problem I've seen is the following:<br><br>How to detect with keep alive mechanism (easily to spot):<br><br>SIP endpoints behind a router without any ALG enabled and * in a public IP.<br><br>When SIP endpoints sends the keep alive (NOTIFY for example) the Via header is a private one (192.168.1.1) and the source IP is the public interface of the router.<br>
Even though you have nat=yes in those endpoints, * returns the reply to the private address (as stated by the RFCs) but it does not reach the endpoint because the destination address is a private onte, instead of the IP where the packet came from.<br>
<br><br>I know it's not RFC compliant but when I see this behaviour, some calls are dropped with the "critical response" message because the ACK handling is also not well done.<br><br>Hope anyone with enough knowledge can shed some light on this issue.<br>
<br>Best regards,<br>Samuel<br><br><br><div class="gmail_quote">2009/3/20 Serge Berney <span dir="ltr"><<a href="mailto:s.berney@kinonline.net">s.berney@kinonline.net</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="FR-CH">
<div>
<p><span lang="EN-US">Hello everybody !</span></p>
<p><span lang="EN-US"> </span></p>
<p><span lang="EN-US">Last day we experiment a communication drop
with this error message :</span></p>
<p><span lang="EN-US"> </span></p>
<p><span lang="EN-US">[Mar 18 12:35:27] WARNING[3854]:
chan_sip.c:1958 retrans_pkt: Maximum retries exceeded on transmission
MzhjNTAyZjNiOTM4MGNjMGZhOGJmYmQ2ZjFlMWJhNzA. for seqno 2 (Critical Response) --
See doc/sip-retransmit.txt.</span></p>
<p><span lang="EN-US"> </span></p>
<p><span lang="EN-US">[Mar 18 12:35:27] WARNING[3854]:
chan_sip.c:1980 retrans_pkt: Hanging up call
MzhjNTAyZjNiOTM4MGNjMGZhOGJmYmQ2ZjFlMWJhNzA. - no reply to our critical packet
(see doc/sip-retransmit.txt).</span></p>
<p><span lang="EN-US"> </span></p>
<p><span lang="EN-US"> </span></p>
<p><span lang="EN-US">I check on the web and see that long time
ago, some user experiment had same problem.</span></p>
<p><span lang="EN-US">But I see also that, since version 1.4,
this kind of error “no reply to our critical packet” wasn’t
considered as a Fatal error… So is it normal that cause hang up ?</span></p>
<p><span lang="EN-US"> </span></p>
<p><span lang="EN-US">I’m running Asterisk 1.4.22 and communication
was established between an Aastra 55i and X-Light</span></p>
<p><span lang="EN-US"> </span></p>
<p><span lang="EN-US">Thanks for informations.</span></p>
<p><span lang="EN-US"> </span></p>
<p><span lang="EN-US"> </span></p>
<p><span lang="EN-US">Serge BERNEY<br>
<b>Kin SA</b><br>
</span><a href="http://www.kinonline.net/" target="_blank"><span style="color: blue;" lang="EN-US">www.kinonline.net</span></a><span lang="EN-US"></span></p>
<p><span lang="EN-US"> </span></p>
</div>
</div>
<br>_______________________________________________<br>
--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--" target="_blank">http://www.api-digital.com--</a><br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br>