Joshua Colp
2015-May-11 17:32 UTC
[asterisk-users] "Retransmission Timeout" results in dropped calls after 32 seconds
Andrew Martin wrote:> ----- Original Message -----<snip>> > By doing a number of test calls today, I have managed to reproduce this while > sip debugging was on, so I have that information available now as well: > http://pastebin.com/ZJqzdvY3 > > This was a call from 113 to 146 via a queue. Note that the asterisk server is > at 10.10.32.251. I see the following: > INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 > SIP/2.0 180 Ringing > SIP/2.0 180 Ringing > SIP/2.0 200 OK > ACK sip:146 at 10.10.32.96:5062 SIP/2.0 > INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 > SIP/2.0 200 OK > ACK sip:146 at 10.10.32.96:5062 SIP/2.0 > INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 > INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 > INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 > INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 > INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 > > This appears to start out with a successful SIP conversation (ending with the > first ACK), so it is unclear to me why we have two new sets of INVITEs sent > afterwards.Asterisk has sent a re-INVITE to have the media flow directly. The device (seems) to respond with the 200 OK (you can tell based on the CSeq) for the initial INVITE, and not for the re-INVITE. As Asterisk gets no response to its re-INVITE it gives up and terminates the dialog. -- 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-11 18:22 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: Monday, May 11, 2015 12:32:06 PM > Subject: Re: [asterisk-users] "Retransmission Timeout" results in dropped calls after 32 seconds > > Andrew Martin wrote: > > ----- Original Message ----- > > <snip> > > > > > By doing a number of test calls today, I have managed to reproduce this > > while > > sip debugging was on, so I have that information available now as well: > > http://pastebin.com/ZJqzdvY3 > > > > This was a call from 113 to 146 via a queue. Note that the asterisk server > > is > > at 10.10.32.251. I see the following: > > INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 > > SIP/2.0 180 Ringing > > SIP/2.0 180 Ringing > > SIP/2.0 200 OK > > ACK sip:146 at 10.10.32.96:5062 SIP/2.0 > > INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 > > SIP/2.0 200 OK > > ACK sip:146 at 10.10.32.96:5062 SIP/2.0 > > INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 > > INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 > > INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 > > INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 > > INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 > > > > This appears to start out with a successful SIP conversation (ending with > > the > > first ACK), so it is unclear to me why we have two new sets of INVITEs sent > > afterwards. > > Asterisk has sent a re-INVITE to have the media flow directly. The > device (seems) to respond with the 200 OK (you can tell based on the > CSeq) for the initial INVITE, and not for the re-INVITE. As Asterisk > gets no response to its re-INVITE it gives up and terminates the dialog. >Could this perhaps be because the phone doesn't support "bypass" or re-INVITEs? Is there a way to disable this functionality and instruct asterisk to just stay in the middle of the conversation (bridging or native-bridging) for the duration of the call? I thought that setting directmedia=no and directrtpsetup=no would disable re-INVITEs and force asterisk to use bridging mode, but perhaps something else is required? Thanks, Andrew
Joshua Colp
2015-May-11 18:24 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: Monday, May 11, 2015 12:32:06 PM >> Subject: Re: [asterisk-users] "Retransmission Timeout" results in dropped calls after 32 seconds >> >> Andrew Martin wrote: >>> ----- Original Message ----- >> <snip> >> >>> By doing a number of test calls today, I have managed to reproduce this >>> while >>> sip debugging was on, so I have that information available now as well: >>> http://pastebin.com/ZJqzdvY3 >>> >>> This was a call from 113 to 146 via a queue. Note that the asterisk server >>> is >>> at 10.10.32.251. I see the following: >>> INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 >>> SIP/2.0 180 Ringing >>> SIP/2.0 180 Ringing >>> SIP/2.0 200 OK >>> ACK sip:146 at 10.10.32.96:5062 SIP/2.0 >>> INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 >>> SIP/2.0 200 OK >>> ACK sip:146 at 10.10.32.96:5062 SIP/2.0 >>> INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 >>> INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 >>> INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 >>> INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 >>> INVITE sip:146 at 10.10.32.96:5062 SIP/2.0 >>> >>> This appears to start out with a successful SIP conversation (ending with >>> the >>> first ACK), so it is unclear to me why we have two new sets of INVITEs sent >>> afterwards. >> Asterisk has sent a re-INVITE to have the media flow directly. The >> device (seems) to respond with the 200 OK (you can tell based on the >> CSeq) for the initial INVITE, and not for the re-INVITE. As Asterisk >> gets no response to its re-INVITE it gives up and terminates the dialog. >> > > Could this perhaps be because the phone doesn't support "bypass" or re-INVITEs? > Is there a way to disable this functionality and instruct asterisk to just > stay in the middle of the conversation (bridging or native-bridging) for the > duration of the call? I thought that setting directmedia=no and > directrtpsetup=no would disable re-INVITEs and force asterisk to use bridging > mode, but perhaps something else is required?That should be all that is required. If that were broken I'd expect issue reports to implode - what's the configuration? -- 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
Possibly Parallel 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