----- Original Message ----- > From: "Joshua Colp" <jc...@digium.com> > To: "Asterisk Users Mailing List - Non-Commercial Discussion" > <asterisk-users@lists.digium.com> > Sent: Tuesday, May 12, 2015 5:42:57 PM > Subject: Re: [asterisk-users] "Retransmission Timeout" results in dropped > calls after 32 seconds > > Andrew Martin wrote: > > <snip> > > >> > > Joshua, > > > > As a mitigation for this problem, could I increase the "timerb" option in > > sip.conf > > to a large value, say 1 hour (instead of the default 32 seconds)? What > > other > > consequences would there be from this change? > > I don't know if chan_sip will allow this, but if it does... it'll keep > transmitting over and over... it would be better to get to the bottom of > the problem. Do a packet capture on the machine running Asterisk and see > where the packet goes. That's the only thing left really. It's also > possible something got fixed in relation to directmedia between your > version and latest 11. >
Joshua, Looking at the packet capture from the asterisk server during this time, I see the following sequence of SIP packets: INVITE (102) - initial call connecting RINGING (102) - initial call connecting RINGING (102) - initial call connecting OK (102) - initial call connecting ACK (102) - initial call connecting OK (102) - initial call connecting (seems like a duplicate OK) INVITE (103) - re-INVITE to go to bypass mode ACK (102) - initial call connecting (seems like a duplicate ACK) INVITE (103) - re-INVITE to go to bypass mode (retry #1) INVITE (103) - re-INVITE to go to bypass mode (retry #2) INVITE (103) - re-INVITE to go to bypass mode (retry #3) INVITE (103) - re-INVITE to go to bypass mode (retry #4) INVITE (103) - re-INVITE to go to bypass mode (retry #5) Looking at the logs from the yealink phone (http://pastebin.com/aAWs4j6i), I see a few differences: INVITE (102) - initial call connecting TRYING (102) - initial call connecting RINGING (102) - initial call connecting INVITE (102) - initial call connecting (seems like a duplicate INVITE) RINGING (102) - initial call connecting OK (102) - initial call connecting ACK (102) - initial call connecting INVITE (103) - re-INVITE to go to bypass mode TRYING (103) - re-INVITE to go to bypass mode OK (103) - re-INVITE to go to bypass mode ACK (102) - initial call connecting (seems like a duplicate ACK) ACK (102) -initial call connecting (seems like a duplicate ACK) INVITE (103) - re-INVITE to go to bypass mode (retry #1) ACK (102) -initial call connecting (seems like a duplicate ACK) INVITE (103) - re-INVITE to go to bypass mode (retry #2) INVITE (103) - re-INVITE to go to bypass mode (retry #3) INVITE (103) - re-INVITE to go to bypass mode (retry #4) INVITE (103) - re-INVITE to go to bypass mode (retry #5) INVITE (103) - re-INVITE to go to bypass mode INVITE (103) - re-INVITE to go to bypass mode Most noteworthy is that the phone seems to send the OK for cseq 103, but it seems that the asterisk server never received this OK, which is why it kept re-transmitting the INVITE (103). Is this OK supposed to go to the asterisk server, or to the other phone? If it is supposed to go to the asterisk server, I suppose the explanation could be network turbulence prevented this OK from getting back to the server - does this seem like what happened? If so, what should be happening differently to ensure that this call doesn't get dropped? Thanks, Andrew -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users