Summary:	ASTERISK-12144: Dropped calls with: Maximum retries exceeded on transmission
Reporter:	Jimbo (digmaster)	Labels:
Date Opened:	2008-06-05 01:23:05	Date Closed:	2011-06-07 14:02:46
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	We get lots of dropped calls with the following warning in the logs: chan_sip.c: Maximum retries exceeded on transmission 2cc62c79934cc54c@192.168.1.102 for seqno 35083 (Critical Response). We use asterisk 1.4.19 with trixbox, a beronet 2-port ISDN PCI card and some Grandstream phones. This happens on 2 out of 10 calls, but when it happens it drops the call while the two people are actively talking. After further tests, we thought that the UDP port was timing out, but that wasn't the case since communication seemed ok.
Comments:	By: David Woolley (davidw) 2008-06-05 04:27:19 Which ends of the failing call are using SIP?  Have you done anything special with the call.  (See ASTERISK-11939 for an example of one "something special" that provokes this symptom.) You may well need to follow the full procedures for reporting SIP problems http://www.asterisk.org/developers/bug-guidelines , but, in this case, using sip history just before the call fails (type "sip history", on the CLI, before the call, and "sip show history <SIP channel ID>" just before the final failure) will tell you which SIP operation is failng.  Generally this error presents about 20 seconds after things started to go wrong and there are multiple attempts to send the failing request. (Removed <> from URL as Mantis doesn't understand this convention and thinks > is part of URL.  It also thinks , is - the <> were supposed to avoid that sort of problem!) By: Jimbo (digmaster) 2008-06-05 04:46:10 Grandstream -SIP> asterisk -ISDN-BRI> telco -ISDN-BRI> phone Unfortunately, this is a production environment and we couldn't reproduce the problem on our test environment, otherwise i would have reported the SIP history. In addition, the problem can't be reproduced by hand... since... it just happens. Maybe not at random but we haven't figured a way to reproduce it by hand. We did enable DEBUG mode on the Grandstream phones and got several logs with SIP messages: 481, 487, 484 and 415. Its weird because some of them aren't supposed to appear, for exaple 415 "unsupported media type" doesn't make sense because the server and the GS phone support all available codecs and they are properly enabled in their configs. I'm sorry i haven't managed to provide more details. By: Jimbo (digmaster) 2008-06-05 04:48:53 I looked at bug 0012548 but it doesn't seem related, since we are placing a normal outgoing call and not using parking. Also, that bug mentions an extra error message "no reply to our critical packet", which doesn't appear in our environment. By: Joshua C. Colp (jcolp) 2008-06-10 09:11:25 We are definitely going to need more information to look at this, such as the sip debug from the console. By: Jimbo (digmaster) 2008-06-10 09:33:13 I'm sorry, i can't provide more information, please close this bug report. By: Joshua C. Colp (jcolp) 2008-06-10 09:35:06 Suspending per reporter. If you can get the info feel free to reopen and we will look at it.