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

----- 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 1:24:53 PM
> Subject: Re: [asterisk-users] "Retransmission Timeout" results in
dropped calls	after 32 seconds
> 
> > 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?
> 
Here's the sip.conf (only showing a single extension since they're all
the same):
[general]
directmedia=no
directrtpsetup=no
dtmfmode=rfc2833
context=asterisk-internal
allowsubscribe=no
qualify=no
disallow=all
allow=ulaw
allow=alaw
allow=gsm
localnet=10.10.32.0/255.255.248.0
localnet=192.168.32.0/255.255.255.0

[146]
secrethost=dynamic
type=friend
>From the aforementioned sip debug capture, 146 is on the 10.10.32.0/21
network
and 113 is on the 192.168.32.0/24 network (these are directly route-able so no
NAT is involved). However, I have now been able to reproduce the problem between
two devices directly on the 10.10.32.0/21 network as well.

Thanks,

Andrew

----- Original Message -----
> From: "Andrew Martin" <amartin at xes-inc.com>
> To: "Asterisk Users Mailing List - Non-Commercial Discussion"
<asterisk-users at lists.digium.com>
> Sent: Monday, May 11, 2015 1:35:07 PM
> Subject: Re: [asterisk-users] "Retransmission Timeout" results in
dropped calls	after 32 seconds
>
> > That should be all that is required. If that were broken I'd
expect
> > issue reports to implode - what's the configuration?
> > 
> 
> Here's the sip.conf (only showing a single extension since they're
all the
> same):
> [general]
> directmedia=no
> directrtpsetup=no
> dtmfmode=rfc2833
> context=asterisk-internal
> allowsubscribe=no
> qualify=no
> disallow=all
> allow=ulaw
> allow=alaw
> allow=gsm
> localnet=10.10.32.0/255.255.248.0
> localnet=192.168.32.0/255.255.255.0
> 
> [146]
> secret> host=dynamic
> type=friend
> 
> From the aforementioned sip debug capture, 146 is on the 10.10.32.0/21
> network
> and 113 is on the 192.168.32.0/24 network (these are directly route-able so
> no
> NAT is involved). However, I have now been able to reproduce the problem
> between
> two devices directly on the 10.10.32.0/21 network as well.
> 
I've gathered the log for this dialog from the SIP phone:
http://pastebin.com/aAWs4j6i

What I see is that there's an INVITE for CSeq 103, then an OK for CSeq 103,
then another INVITE is received for CSeq 103, at which point the phone
reports an error:
<0> | ERROR | receive a request with same cseq??
>From the asterisk side, it never seems to receive this OK for CSeq 103,
hence
the reason it sends out the INVITE again.

Thanks,

Andrew