Joshua Colp
2015-May-13 15:50 UTC
[asterisk-users] "Retransmission Timeout" results in dropped calls after 32 seconds
Andrew Martin wrote:> ----- Original Message ----- >> From: "Joshua Colp"<jcolp at digium.com> >> To: "Asterisk Users Mailing List - Non-Commercial Discussion"<asterisk-users at lists.digium.com> >> Sent: Wednesday, May 13, 2015 10:10:25 AM >> Subject: Re: [asterisk-users] "Retransmission Timeout" results in dropped calls after 32 seconds >> >> Andrew Martin wrote: >>> ----- Original Message ----- >> <snip> >> >>> >>> 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? >> The traffic is between the phone and Asterisk. As to why, I have no >> idea. The packets aren't getting to Asterisk - that's all I can say. I >> doubt it's network turbulence. Likely getting lost/blocked somewhere. >> > Since some packet loss is a possibility, I assume the protocol has mechanisms > for dealing with it. What should be happening differently in the communication > when packet loss occurs? Should the phone just be re-sending the OK, instead of > printing "<0> | ERROR | receive a request with same cseq??" to its log? Or should > Asterisk be starting with a new cseq on each INVITE retry?The 200 OK should be retransmitted until an ACK is received. It honestly looks like the phone can't talk to Asterisk and it's just generally screwing up signaling. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org
Andrew Martin
2015-May-13 15:59 UTC
[asterisk-users] "Retransmission Timeout" results in dropped calls after 32 seconds
----- Original Message -----> From: "Joshua Colp" <jcolp at digium.com> > To: "Asterisk Users Mailing List - Non-Commercial Discussion" <asterisk-users at lists.digium.com> > Sent: Wednesday, May 13, 2015 10:50:02 AM > Subject: Re: [asterisk-users] "Retransmission Timeout" results in dropped calls after 32 seconds > > Andrew Martin wrote: > > Since some packet loss is a possibility, I assume the protocol has > > mechanisms > > for dealing with it. What should be happening differently in the > > communication > > when packet loss occurs? Should the phone just be re-sending the OK, > > instead of > > printing "<0> | ERROR | receive a request with same cseq??" to its log? Or > > should > > Asterisk be starting with a new cseq on each INVITE retry? > > The 200 OK should be retransmitted until an ACK is received. It honestly > looks like the phone can't talk to Asterisk and it's just generally > screwing up signaling. >Thanks for the clarification and help debugging this problem. I will work with the phone vendor to see if they can resolve this from their end. If you have any other ideas about how to disable re-INVITEs on the asterisk side, beyond what I have done already, please let me know. Thanks, Andrew
Steve Davies
2015-May-13 16:39 UTC
[asterisk-users] "Retransmission Timeout" results in dropped calls after 32 seconds
Hi, In my experience, all Yealink phones work just fine with Asterisk, we have hundreds (perhaps even low-thousands) out there with customers on Asterisk 1.2, 1.6.2, 1.8 and 11. If you are accurately representing the SIP trace on the phone and the SIP trace on Asterisk, then I would strongly suggest a SIP ALG exists in the network between the two devices and that SIP ALG does not understand SIP properly. The two halves simply do not match, so something must surely be interfering. In my experience it is often an innocent looking Cisco router. Cisco's SIP implementation is "SIP By Cisco" rather than "RFC compliant SIP". If that is the case Cisco call it a "SIP fixup" and you just need to disable it. Hope that helps, Steve On Wed, 13 May 2015 at 16:59 Andrew Martin <amartin at xes-inc.com> wrote:> > > ----- Original Message ----- > > From: "Joshua Colp" <jcolp at digium.com> > > To: "Asterisk Users Mailing List - Non-Commercial Discussion" < > asterisk-users at lists.digium.com> > > Sent: Wednesday, May 13, 2015 10:50:02 AM > > Subject: Re: [asterisk-users] "Retransmission Timeout" results in > dropped calls after 32 seconds > > > > Andrew Martin wrote: > > > Since some packet loss is a possibility, I assume the protocol has > > > mechanisms > > > for dealing with it. What should be happening differently in the > > > communication > > > when packet loss occurs? Should the phone just be re-sending the OK, > > > instead of > > > printing "<0> | ERROR | receive a request with same cseq??" to its > log? Or > > > should > > > Asterisk be starting with a new cseq on each INVITE retry? > > > > The 200 OK should be retransmitted until an ACK is received. It honestly > > looks like the phone can't talk to Asterisk and it's just generally > > screwing up signaling. > > > > Thanks for the clarification and help debugging this problem. I will work > with the phone vendor to see if they can resolve this from their end. If > you > have any other ideas about how to disable re-INVITEs on the asterisk side, > beyond what I have done already, please let me know. > > 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20150513/60f4c625/attachment.html>
Maybe Matching Threads
- "Retransmission Timeout" results in dropped calls after 32 seconds
- "Retransmission Timeout" results in dropped calls after 32 seconds
- "Retransmission Timeout" results in dropped calls after 32 seconds
- "Retransmission Timeout" results in dropped calls after 32 seconds
- "Retransmission Timeout" results in dropped calls after 32 seconds