VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
View previous topic :: View next topic |
Author |
Message |
amartin at xes-inc.com Guest
|
Posted: Mon May 11, 2015 12:27 pm Post subject: [asterisk-users] "Retransmission Timeout" results |
|
|
----- Original Message -----
Quote: | From: "Andrew Martin" <amartin@xes-inc.com>
To: "Asterisk Users Mailing List - Non-Commercial Discussion" <asterisk-users@lists.digium.com>
Sent: Friday, May 8, 2015 5:12:28 PM
Subject: [asterisk-users] "Retransmission Timeout" results in dropped calls after 32 seconds
Hello,
I am running Asterisk 11 on CentOS 6.4 with SIP clients (Yealink phones). All
the SIP clients are on a LAN, so no NAT is involved. I have been experiencing
an intermittent problem where a call will be successfully answered, but then
dropped by Asterisk 32 seconds after it is answered (with a "Retransmission
timeout reached on transmission" error). Here is an example of this happening
in the asterisk console:
http://pastebin.com/7LDwHAJe
This problem only happens a fraction of the time, so I have been unable to
enable SIP debugging before it happens to get a capture. However, usually the
caller will just call back immediately and then the call will work without a
problem. It sounds like SIP Timer B is what causes the call to be dropped if
an
ACK to the INVITE is not received within 32 seconds. How can I determine if
this is the case and how can I resolve this "Retransmission timeout" problem?
Here is my sip.conf:
general]
directmedia=no
directrtpsetup=no
dtmfmode=rfc2833
context=internal
allowsubscribe=no
qualify=no
disallow=all
allow=ulaw
allow=alaw
allow=gsm
localnet=10.10.32.0/255.255.248.0
[123]
secret=111111
host=dynamic
type=friend
|
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@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@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
SIP/2.0 200 OK
ACK sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@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.
Also in case it is relevant, the asterisk server has two NICs set up in a bond
with bond-mode 1 (active/backup).
Does this additional debug information provide any clues to why this
intermittent "retransmission timeout" error is occurring?
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 |
|
Back to top |
|
|
jcolp at digium.com Guest
|
Posted: Mon May 11, 2015 12:32 pm Post subject: [asterisk-users] "Retransmission Timeout" results |
|
|
Andrew Martin wrote:
Quote: | ----- Original Message -----
|
<snip>
Quote: |
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@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@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
SIP/2.0 200 OK
ACK sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@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
--
_____________________________________________________________________
-- 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 |
|
Back to top |
|
|
amartin at xes-inc.com Guest
|
Posted: Mon May 11, 2015 1:22 pm Post subject: [asterisk-users] "Retransmission Timeout" results |
|
|
----- Original Message -----
Quote: | From: "Joshua Colp" <jcolp@digium.com>
To: "Asterisk Users Mailing List - Non-Commercial Discussion" <asterisk-users@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:
Quote: | ----- Original Message -----
|
<snip>
Quote: |
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@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@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
SIP/2.0 200 OK
ACK sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@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
--
_____________________________________________________________________
-- 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 |
|
Back to top |
|
|
jcolp at digium.com Guest
|
Posted: Mon May 11, 2015 1:25 pm Post subject: [asterisk-users] "Retransmission Timeout" results |
|
|
Andrew Martin wrote:
Quote: | ----- Original Message -----
Quote: | From: "Joshua Colp"<jcolp@digium.com>
To: "Asterisk Users Mailing List - Non-Commercial Discussion"<asterisk-users@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:
Quote: | ----- Original Message -----
| <snip>
Quote: | 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@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@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
SIP/2.0 200 OK
ACK sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@10.10.32.96:5062 SIP/2.0
INVITE sip:146@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
--
_____________________________________________________________________
-- 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 |
|
Back to top |
|
|
amartin at xes-inc.com Guest
|
Posted: Mon May 11, 2015 1:35 pm Post subject: [asterisk-users] "Retransmission Timeout" results |
|
|
----- Original Message -----
Quote: | From: "Joshua Colp" <jcolp@digium.com>
To: "Asterisk Users Mailing List - Non-Commercial Discussion" <asterisk-users@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
Quote: | 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]
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.
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 |
|
Back to top |
|
|
amartin at xes-inc.com Guest
|
Posted: Mon May 11, 2015 4:19 pm Post subject: [asterisk-users] "Retransmission Timeout" results |
|
|
----- Original Message -----
Quote: | From: "Andrew Martin" <amartin@xes-inc.com>
To: "Asterisk Users Mailing List - Non-Commercial Discussion" <asterisk-users@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
Quote: | 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
--
_____________________________________________________________________
-- 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 |
|
Back to top |
|
|
amartin at xes-inc.com Guest
|
Posted: Tue May 12, 2015 5:37 pm Post subject: [asterisk-users] "Retransmission Timeout" results |
|
|
----- Original Message -----
Quote: | From: "Andrew Martin" <amartin@xes-inc.com>
To: "Asterisk Users Mailing List - Non-Commercial Discussion" <asterisk-users@lists.digium.com>
Sent: Monday, May 11, 2015 4:18:58 PM
Subject: Re: [asterisk-users] "Retransmission Timeout" results in dropped calls after 32 seconds
----- Original Message -----
Quote: | From: "Andrew Martin" <amartin@xes-inc.com>
To: "Asterisk Users Mailing List - Non-Commercial Discussion"
<asterisk-users@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
Quote: | 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.
| 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?
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 |
|
Back to top |
|
|
jcolp at digium.com Guest
|
Posted: Tue May 12, 2015 5:43 pm Post subject: [asterisk-users] "Retransmission Timeout" results |
|
|
Andrew Martin wrote:
<snip>
Quote: | 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 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
--
_____________________________________________________________________
-- 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 |
|
Back to top |
|
|
amartin at xes-inc.com Guest
|
Posted: Wed May 13, 2015 10:06 am Post subject: [asterisk-users] "Retransmission Timeout" results |
|
|
----- Original Message -----
Quote: | From: "Joshua Colp" <jcolp@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>
Quote: | 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 |
|
Back to top |
|
|
jcolp at digium.com Guest
|
Posted: Wed May 13, 2015 10:10 am Post subject: [asterisk-users] "Retransmission Timeout" results |
|
|
Andrew Martin wrote:
Quote: | ----- Original Message -----
|
<snip>
Quote: |
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.
--
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
--
_____________________________________________________________________
-- 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 |
|
Back to top |
|
|
amartin at xes-inc.com Guest
|
Posted: Wed May 13, 2015 10:36 am Post subject: [asterisk-users] "Retransmission Timeout" results |
|
|
----- Original Message -----
Quote: | From: "Joshua Colp" <jcolp@digium.com>
To: "Asterisk Users Mailing List - Non-Commercial Discussion" <asterisk-users@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:
Quote: | ----- Original Message -----
|
<snip>
Quote: |
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?
--
_____________________________________________________________________
-- 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 |
|
Back to top |
|
|
jcolp at digium.com Guest
|
Posted: Wed May 13, 2015 10:50 am Post subject: [asterisk-users] "Retransmission Timeout" results |
|
|
Andrew Martin wrote:
Quote: | ----- Original Message -----
Quote: | From: "Joshua Colp"<jcolp@digium.com>
To: "Asterisk Users Mailing List - Non-Commercial Discussion"<asterisk-users@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:
Quote: | ----- Original Message -----
| <snip>
Quote: |
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
--
_____________________________________________________________________
-- 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 |
|
Back to top |
|
|
amartin at xes-inc.com Guest
|
Posted: Wed May 13, 2015 10:59 am Post subject: [asterisk-users] "Retransmission Timeout" results |
|
|
----- Original Message -----
Quote: | From: "Joshua Colp" <jcolp@digium.com>
To: "Asterisk Users Mailing List - Non-Commercial Discussion" <asterisk-users@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:
Quote: | 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 |
|
Back to top |
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|