asterisk users - May 2015 - "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

----- 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

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