[asterisk-bugs] [Asterisk 0010567]: DTMF INFO event appears to be causing Maximum retries exceeded on transmission hangup.

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10567 
====================================================================== 
Reported By:                jacksch
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10567
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     confirmed
Asterisk Version:            1.4.9  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             08-26-2007 23:09 CDT
Last Modified:              09-14-2007 13:58 CDT
====================================================================== 
Summary:                    DTMF INFO event appears to be causing Maximum
retries exceeded on transmission hangup.
Description: 
I've spent a *lot* of time struggling with outgoing calls being
disconnected 20 seconds after they were answered.  Since my phones are on a
LAN (private addressing) and my Asterisk box is dual homed (one interface
with a public IP), there is definately no NAT problem. My Asterisk talks
SIP to all my local devices on the LAN, and sends outbound calls for
termination via IAX2.

If I dial a number and hit pound (to cause the call to be dialled
immediately) on a phone connected to my Sipura 2000, Asterisk connects the
call, and I have two way audio, but then it begins transmitting INVITES to
the ATA.  The ATA acknowledging them, but, it still results in :

[Aug 27 00:01:02] WARNING[15661]: chan_sip.c:1920 retrans_pkt: Maximum
retries exceeded on transmission 9d4091f7-a13e2f8d at 192.168.220.52 for seqno
102 (Critical Response)
[Aug 27 00:01:02] WARNING[15661]: chan_sip.c:1944 retrans_pkt: Hanging up
call 9d4091f7-a13e2f8d at 192.168.220.52 - no reply to our critical packet.

If I place the same call and just wait for the ATA to time out (as opposed
to hitting # after dialling the number), the problem does not occur.

Please contact me if you would like the full debug file -- eric( a t
)jacksch( d o t )com
====================================================================== 

---------------------------------------------------------------------- 
 neutrino88 - 09-14-07 13:58  
---------------------------------------------------------------------- 
Same note as in http://bugs.digium.com/view.php?id=10332


I had a similar situation where a SIP phone would initiate a new
transaction BEFORE the ACK was sent:


SIP Phone Asterisk

INVITE (CSEQ=1) ---------->

<------------------ 180 RINGING

<------------------ 200 OK

INFO (CSEQ=3) ---------->
 <------------------ 200 OK

ACK CSEQ = 2 ------------> dropped

<------------------- 200 OK (CSEQ=2) restransmision

I designed a patch for 1.4.x branch

Index: channels/chan_sip.c
===================================================================
--- channels/chan_sip.c (révision 82392)
+++ channels/chan_sip.c (copie de travail)
@@ -14952,7 +14952,7 @@
        if (option_debug > 3)
                ast_log(LOG_DEBUG, "**** Received %s (%d) - Command in SIP
%s\n", sip_methods[p->method].text, sip_methods[p->method].id, cmd);

- if (p->icseq && (p->icseq > seqno)) {
+ if (p->icseq && (p->icseq > seqno) && req->method != SIP_ACK) {
                if (option_debug)
                        ast_log(LOG_DEBUG, "Ignoring too old SIP packet
packet %d (expecting >= %d)\n", seqno, p->icseq);
                if (req->method != SIP_ACK) 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
09-14-07 13:58  neutrino88     Note Added: 0070570                          
======================================================================