Hi all,<br>Im trying to understand the behaviour of asterisk when a sip call is initiated (sip invite is sent to the callee) but the callee is behind a bad-nat and becoz of that either our packets dont reach the callee or the callee does not responde to us properly, my asterisk does not get any reply of the invite packet at all even after 5 re-invites have been sent.
<br><br>The bottom line is, as the call could not be setup the caller's channel hangsup without any problem, but the callee channel does not hangup, which means its inuse limit for peer never goes back to 0, which means if the caller tries again and again the callee's inuse limit to recieve calls keeps on increasing utill it reaches the max limit (call-limit=2 for peer in
sip.conf) and never decremented, which means the callee can no longer recieve any calls irrespective of the fact that maybe its nat conditions have improved and its now able to recieve calls, or not.<br><br>I see ast_sched_add() is called in sip_call() function for auto-congestion, which mean auto-congestion is declared after timeout. I need to ask you guys that in the above described scenario, shoulden't asterisk declare auto-congestion if it does not get any reply? or does it?
<br><br>I have noticed a strange thing when i saw a debug on asterisk cli under the above scenario:<br><br><span style="color: rgb(0, 153, 0);">[Oct 24 06:50:34] DEBUG[10748]: chan_sip.c:3312 sip_hangup: Hangup call SIP/gusgus-009a7510, SIP callid
<a href="mailto:6b25d4d65b65986436195f224b67c365@69.90.174.98">6b25d4d65b65986436195f224b67c365@69.90.174.98</a>)</span><br style="color: rgb(0, 153, 0);"><span style="color: rgb(0, 153, 0);"><span style="color: rgb(204, 0, 0);">
>></span>[Oct 24 06:50:34] DEBUG[10748]: chan_sip.c:3321 sip_hangup: <span style="color: rgb(204, 0, 0);">update_call_counter(gusgus) - decrement call limit counter on hangup</span></span><br style="color: rgb(0, 153, 0);">
<span style="color: rgb(0, 153, 0);">[Oct 24 06:50:34] DEBUG[10748]: chan_sip.c:3003 update_call_counter: Updating call counter for outgoing call</span><br style="color: rgb(0, 153, 0);"><span style="color: rgb(0, 153, 0);">
<span style="color: rgb(204, 0, 0);">>></span>[Oct 24 06:50:34] DEBUG[10748]: chan_sip.c:3051 update_call_counter: <span style="color: rgb(204, 0, 0);">Call to peer 'gusgus' removed from call limit 2</span></span>
<br style="color: rgb(0, 153, 0);"><span style="color: rgb(0, 153, 0);">[Oct 24 06:50:34] DEBUG[10340]: chan_sip.c:15247 sip_devicestate: Checking device state for peer gusgus</span><br style="color: rgb(0, 153, 0);"><span style="color: rgb(0, 153, 0);">
<span style="color: rgb(204, 0, 0);">>></span>[Oct 24 06:50:34] DEBUG[10748]: chan_sip.c:2071 __sip_ack: <span style="color: rgb(204, 0, 0);">Acked pending invite 102</span></span><br style="color: rgb(0, 153, 0);">
<span style="color: rgb(0, 153, 0);">[Oct 24 06:50:34] DEBUG[10748]: chan_sip.c:2089 __sip_ack: Stopping retransmission on '<a href="mailto:6b25d4d65b65986436195f224b67c365@69.90.174.98">6b25d4d65b65986436195f224b67c365@69.90.174.98
</a>' of Request 102: Match Not Found</span><br style="color: rgb(0, 153, 0);"><span style="color: rgb(0, 153, 0);"><span style="color: rgb(204, 0, 0);">>></span>[Oct 24 06:50:34] DEBUG[10748]: chan_sip.c:3003 update_call_counter:
<span style="color: rgb(204, 0, 0);">Updating call counter for outgoing call</span></span><br style="color: rgb(0, 153, 0);"><span style="color: rgb(0, 153, 0);"><span style="color: rgb(204, 0, 0);">>></span>[Oct 24 06:50:34] DEBUG[10748]: chan_sip.c:3077 update_call_counter:
<span style="color: rgb(204, 0, 0);">Call to peer 'gusgus' is 1 out of 2</span></span><br style="color: rgb(0, 153, 0);"><span style="color: rgb(0, 153, 0);">[Oct 24 06:50:34] DEBUG[10340]: chan_sip.c:15247 sip_devicestate: Checking device state for peer gusgus
</span><br style="color: rgb(0, 153, 0);"><span style="color: rgb(0, 153, 0);">[Oct 24 06:50:34] DEBUG[10340]: chan_sip.c:15247 sip_devicestate: Checking device state for peer gusgus</span><br style="color: rgb(0, 153, 0);">
<span style="color: rgb(0, 153, 0);">[Oct 24 06:50:34] NOTICE[10748]: cdr_addon_mysql.c:1444 mysql_log: cdr_mysql: Inserting a CDR record.</span><br><br>You can see in the debug output that after decrementing the call limit it increments it again. Maybe because there is a pending invite, but y, Its retransmission should be stopped but no.
<br><br>So can anybody help me in preventing the chanel from stucking?<br><br>-- <br>Best Regards<br>Rizwan Hisham<br>Software Engineer<br>Axvoice Inc.<br><a href="http://www.axvoice.com">www.axvoice.com</a><br>