[asterisk-users] OpenVPN Clients Intermittently Cannot Call In
Hello,
I am running Asterisk 11.12.0 on CentOS 6.4. The asterisk server and internal
phones are located on the 10.10.32.0/21 LAN subnet. I have many internal SIP
phones, which appear to be working correctly. I have a few external phones
(Yealink SIP-T32G or other Yealink model) on 192.168.32.0/24 which have an
OpenVPN client configured on them that connects back to the LAN network through
a pfSense gateway with OpenVPN configured on it.
Asterisk server LAN IP: 10.10.32.10
My internal test phone: 146 at 10.10.32.96
My external test phone: 265 at 192.168.32.10
My sip.conf for these external users is as follows:
http://pastebin.com/2b9YE7Dz
The dialplan uses this Dial() invocation when dialing either an internal or
external phone. Note that the max timeout is 12 seconds:
exten = _[12]XX,1,Dial(SIP/${EXTEN},12)
These external phones register correctly, and internal users can call these
external users, the phones ring immediately, and the call is normal. However,
if the external users try to dial an internal phone, I've observed some
different failure modes:
* operating normally: sometimes the call rings immediately, the internal user
answers, and the audio is present immediately
* ringing delay and no connection even after pickup: sometimes there's a
significant delay between when the call starts ringing on the external side
and when it actually starts ringing on the internal user's phone. Consequently,
the internal user only has 1 or 2 rings to answer. Even if they do answer
during this time, the line is dead and it goes to voicemail (the next step in
the dialplan)
* delay before audio is connected after answer: sometimes the internal user
answers, but there's a delay of 3-10 seconds before either party can hear audio
I've enabled rtp and sip debug for this particular external phone
(192.168.32.10) and attached console logs from both types of these failures:
* ringing delay and no connection even after pickup:
http://pastebin.com/fe1khEmF
* delay before audio is connected after answer: http://pastebin.com/uZSMKczk
What else can I try to debug these problems? Since it is intermittent, I am not
always able to reproduce (sometimes the calls work just fine).
Thanks,
Andrew Martin
--
_
-- 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
Re: [asterisk-users] OpenVPN Clients Intermittently Cannot Call In
- Original Message - From: Administrator TOOTAI ad...@tootai.net To: asterisk-users@lists.digium.com Sent: Thursday, April 30, 2015 4:43:33 PM Subject: Re: [asterisk-users] OpenVPN Clients Intermittently Cannot Call In I am running Asterisk 11.12.0 on CentOS 6.4. The asterisk server and internal phones are located on the 10.10.32.0/21 LAN subnet. I have many internal SIP phones, which appear to be working correctly. I have a few external phones (Yealink SIP-T32G or other Yealink model) on 192.168.32.0/24 which have an OpenVPN client configured on them that connects back to the LAN network through a pfSense gateway with OpenVPN configured on it. I faced problems with pfsense -no VPN involved- and finally installed siproxd on it. Also set the firewall mode to conservative. Daniel, Thanks for the information. Do you have an example or documentation on the siproxd configuration that you used? 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
Re: [asterisk-users] OpenVPN Clients Intermittently Cannot Call In
- Original Message - From: Administrator TOOTAI ad...@tootai.net To: asterisk-users@lists.digium.com Sent: Friday, May 1, 2015 6:42:38 AM Subject: Re: [asterisk-users] OpenVPN Clients Intermittently Cannot Call In Le 01/05/2015 00:05, Andrew Martin a écrit : - Original Message - From: Administrator TOOTAI ad...@tootai.net To: asterisk-users@lists.digium.com Sent: Thursday, April 30, 2015 4:43:33 PM Subject: Re: [asterisk-users] OpenVPN Clients Intermittently Cannot Call In I am running Asterisk 11.12.0 on CentOS 6.4. The asterisk server and internal phones are located on the 10.10.32.0/21 LAN subnet. I have many internal SIP phones, which appear to be working correctly. I have a few external phones (Yealink SIP-T32G or other Yealink model) on 192.168.32.0/24 which have an OpenVPN client configured on them that connects back to the LAN network through a pfSense gateway with OpenVPN configured on it. I faced problems with pfsense -no VPN involved- and finally installed siproxd on it. Also set the firewall mode to conservative. Daniel, Thanks for the information. Do you have an example or documentation on the siproxd configuration that you used? No, just follow the basis of the parameters given by the package. If I remember, SIP use the proxy siproxd and RTP is direct. Looking into it further, in my case it does not appear to be a NATing issue, since running OpenVPN from pfSense means there's no NATing occurring between the clients or between the clients and the asterisk server. Although I was unable to reproduce the problems, I did notice some packet loss and jitter in sip show channelstats, here is a sample: Peer Call ID Duration Recv: Pack Lost ( %) Jitter Send: Pack Lost ( %) Jitter 192.168.32.26446613544@1 00:03:03 94 004238 (97.83%) 0. 00 000244 ( 0.00%) 0. 192.168.32.385b2ebdc92fd 00:03:03 59 01 ( 1.67%) 0. 00 91 ( 0.00%) 0.0028 I was unable to find documentation each of these columns, but the high percentage of loss for received packets for 192.168.32.26 seems suspicious. Do these statistics indicate a problem? 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
Re: [asterisk-users] OpenVPN Clients Intermittently Cannot Call In
- Original Message - From: Guenther Boelter gboel...@gmail.com To: asterisk-users@lists.digium.com Sent: Tuesday, May 5, 2015 1:05:44 AM Subject: Re: [asterisk-users] OpenVPN Clients Intermittently Cannot Call In Looking into it further, in my case it does not appear to be a NATing issue, since running OpenVPN from pfSense means there's no NATing occurring between the clients or between the clients and the asterisk server. Although I was unable to reproduce the problems, I did notice some packet loss and jitter in sip show channelstats, here is a sample: Peer Call ID Duration Recv: Pack Lost ( %) Jitter Send: Pack Lost ( %) Jitter 192.168.32.26446613544@1 00:03:03 94 004238 (97.83%) 0. 00 000244 ( 0.00%) 0. 192.168.32.385b2ebdc92fd 00:03:03 59 01 ( 1.67%) 0. 00 91 ( 0.00%) 0.0028 I was unable to find documentation each of these columns, but the high percentage of loss for received packets for 192.168.32.26 seems suspicious. Do these statistics indicate a problem? Thanks, Andrew Hi Andrew, is this a linux machine? If so, check your NIC with ifconfig for hardware errors. Guenther Guenther, Yes, this machine is running CentOS 6.4 (see my original post for more details). This asterisk server has 2x gigabit NICs set up in a bond with bond mode 1. Both ifconfig and ethtool do not report any hardware errors, although they do show a few checksum errors: eth0 Link encap:Ethernet HWaddr 00:11:22:33:44:55 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:467927100 errors:0 dropped:0 overruns:1 frame:0 TX packets:304724661 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:131747094082 (122.6 GiB) TX bytes:93869585242 (87.4 GiB) Memory:fb92-fb94 eth1 Link encap:Ethernet HWaddr AA:BB:CC:DD:EE:FF UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:41250363 errors:0 dropped:0 overruns:0 frame:0 TX packets:3467 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:5190889937 (4.8 GiB) TX bytes:1594075 (1.5 MiB) Memory:fb90-fb92 From ethtool -S eth0: tx_smbus: 164709 rx_smbus: 119082408 dropped_smbus: 104036 rx_queue_0_packets: 97532982 rx_queue_0_bytes: 16800645524 rx_queue_0_drops: 1 rx_queue_0_csum_err: 0 rx_queue_0_alloc_failed: 0 rx_queue_7_packets: 53850556 rx_queue_7_bytes: 12797600155 rx_queue_7_drops: 0 rx_queue_7_csum_err: 41 rx_queue_7_alloc_failed: 0 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
Re: [asterisk-users] Phones don't stop ringing when queue is answered
James, The WaitExten()s just provide a pause between the two Queue() calls to let the first group of phones finish ringing. In this example I am ringing the same group (queue_level_1) twice, however in a real-world scenario I would ring queue_level_1 and then ring queue_level_2 which each have a different list of phones. Thanks, Andrew - Original Message - From: James Thomas jthomas...@gmail.com To: Asterisk Users Mailing List - Non-Commercial Discussion asterisk-users@lists.digium.com Sent: Thursday, May 7, 2015 10:20:10 AM Subject: Re: [asterisk-users] Phones don't stop ringing when queue is answered What purpose do the WaitExten()s serve here? Are you really allowing the caller to connect to different extensions in the test-queue context? Have you tried without the WaitExten()s? -- _ -- 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 -- _ -- 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
Re: [asterisk-users] Retransmission Timeout results in dropped calls after 32 seconds
- Original Message - From: Joshua Colp jc...@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 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
Re: [asterisk-users] Retransmission Timeout results in dropped calls after 32 seconds
- Original Message - From: Joshua Colp jc...@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: - 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@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
Re: [asterisk-users] Retransmission Timeout results in dropped calls after 32 seconds
- Original Message - From: Andrew Martin amar...@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 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
[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=11 host=dynamic type=friend Thanks! Andrew Martin -- _ -- 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
Re: [asterisk-users] Retransmission Timeout results in dropped calls after 32 seconds
- Original Message - From: Andrew Martin amar...@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=11 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
Re: [asterisk-users] Retransmission Timeout results in dropped calls after 32 seconds
- Original Message - From: Joshua Colp jc...@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 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
Re: [asterisk-users] Retransmission Timeout results in dropped calls after 32 seconds
- Original Message - From: Andrew Martin amar...@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 - From: Andrew Martin amar...@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 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
Re: [asterisk-users] Retransmission Timeout results in dropped calls after 32 seconds
- Original Message - From: Joshua Colp jc...@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: 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
Re: [asterisk-users] Retransmission Timeout results in dropped calls after 32 seconds
- Original Message - From: Joshua Colp jc...@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: - 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? -- _ -- 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
Re: [asterisk-users] Retransmission Timeout results in dropped calls after 32 seconds
- Original Message - From: Steve Davies davies...@gmail.com To: Asterisk Users Mailing List - Non-Commercial Discussion asterisk-users@lists.digium.com Sent: Wednesday, May 13, 2015 11:39:29 AM Subject: Re: [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 Steve, That is an interesting point - the server and the phone are both connected to Netgear switches where I have enabled their Auto-VoIP feature, which remarks packets based on protocol (SIP, SCCP, etc) for better QoS: http://kb.netgear.com/app/answers/detail/a_id/21758 I wonder if this remarking process is modifying another part of the packet too? Both devices are on the same subnet, so although these switches do route traffic as well, that shouldn't be coming into play here. 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
Re: [asterisk-users] Queues don't follow dialplan if no members are registered
- Original Message - From: John Kiniston johnkinis...@gmail.com To: Asterisk Users Mailing List - Non-Commercial Discussion asterisk-users@lists.digium.com Sent: Wednesday, July 29, 2015 11:53:13 AM Subject: Re: [asterisk-users] Queues don't follow dialplan if no members are registered Wow, Looks like they have really increased the options since I last looked. I just pulled down the Asterisk 13 queues.conf.sample and it's got this in it: ; paused: a member is not considered available if he is paused ; penalty: a member is not considered available if his penalty is less than QUEUE_MAX_PENALTY ; inuse: a member is not considered available if he is currently on a call ; ringing: a member is not considered available if his phone is currently ringing ; unavailable: This applies mainly to Agent channels. If the agent is a member of the queue ; but has not logged in, then do not consider the member to be available ; invalid: Do not consider a member to be available if he has an invalid device state. ; This generally is caused by an error condition in the member's channel driver. ; unknown: Do not consider a member to be available if we are unable to determine the member's ; current device state. ; wrapup: A member is not considered available if he is currently in his wrapuptime after ; taking a call. An unknown state would be a device that has a valid configuration but isn't registered. John, Thanks for the clarification and your help resolving this issue! 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
Re: [asterisk-users] Queues don't follow dialplan if no members are registered
- Original Message - From: John Kiniston johnkinis...@gmail.com To: Asterisk Users Mailing List - Non-Commercial Discussion asterisk-users@lists.digium.com Sent: Tuesday, July 28, 2015 12:12:05 PM Subject: Re: [asterisk-users] Queues don't follow dialplan if no members are registered In your queues.conf do you have a leavewhenempty and joinempty set? in queues.conf [myqueue] leavewhenempty = strict joinempty = strict strategy = ringall ringinuse = no John, Thanks for the fast reply! I had joinempty=yes in queues.conf, which explains why I was seeing this behavior. It looks like the strict setting is partially-deprecated, so instead I'm using the following combination: [myqueue] musiconhold=default music=default strategy=ringall joinempty=unavailable,invalid,unknown leavewhenempty=unavailable,invalid,unknown timeout=18 member = SIP/100 member = SIP/101 Is there any reason that using any of these options would be a problem, in particular unknown? It is not very well defined what an unknown state is exactly. 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
[asterisk-users] Queues don't follow dialplan if no members are registered
Hello, I am running Asterisk 11 on CentOS 6.x. I have configured several queues as follows in extensions.conf: exten = s,1,Queue(myqueue,rtnC,18) same = n,Background(user_unavail) same = n,WaitExten(10) exten = 1,1,Voicemail(@my-vm,s) This rings the phones in the queue for 18 seconds. If no queue members answer, the caller is then prompted to press 1 and leave a voicemail. This works well when at least 1 member is registered in the queue, however if no members are registered in the queue, the Queue() call never seems to return, and thus the remaining steps in the dialplan never execute. How can I correct this behavior so that even if the queue has no registered members, the dialplan is still followed? 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
[asterisk-users] SIP Phones over VPN Drop Audio One-Way
Hello, I am running Asterisk 11 on CentOS 6.x using the DAHDI module with 8x PSTN analog phone lines for outside connectivity. Internally, I am using several models of Yealink SIP phones (e.g SIP-T32G) on a dedicated VoIP network, 192.168.0.0/24. I have a few of these Yealink SIP phones configured with an OpenVPN certificate so that users working remotely can directly access the phone system (VPN subnet is 192.168.1.0/24). Note that this is not a NAT; VPN clients are able to directly address the Asterisk server and other SIP phones. Last week the phones connecting over the VPN started dropping audio during the call (e.g caller 1 can still hear caller 2, but not vise versa). These calls are between two SIP phones (one over the VPN, one internal). The dropouts last for 20 seconds or more, and sometimes the audio does recover and come back. I made some changes to the infrastructure last week, but I am not sure that they are the cause. First, I added echotraining=yes to /etc/asterisk/chan_dahdi.conf to try and fix echo problem (seems unrelated since the call is all SIP). I also cleaned up some extraneous firewall rules on the OpenVPN gateway, but I still allow the VPN phones to connect to the Asterisk server on ports 5000 - 2 for SIP and RSTP so this also seems unrelated. I've looked at the syslog on the SIP phones as well as the asterisk output with sip set debug and rtp set debug on but I don't see anything obviously wrong. The only sign of a problem I can see is this message when the call is hung up: pbx.c: == Spawn extension (dial-extension, 124, 1) exited non-zero on 'SIP/123-01d9' Here is an example user in my sip.conf: http://pastebin.com/6U2AhyWT Do you have any ideas about what is causing these dropouts, or what I should look at next for additional debug information? Thanks, Andrew Martin -- _ -- 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
[asterisk-users] Dropped calls when all DAHDI lines in use
Hello, I am running Asterisk 11.17 with DAHDI 2.9.0 and an OpenVox A800P with 8x analog POTS lines coming into my Asterisk server from the phone company. Internally, I have about 180 SIP clients defined in sip.conf. What appears to be happening is that if existing calls are consuming all 8 external lines and a new SIP client attempts to make a call, an existing call gets dropped. The asterisk log simply shows this as a normal hangup, so I am not able to easily distinguish between a normal hangup and this type of dropped call. In testing, I am able to get a new SIP client to report "service unavailable" when all 8 lines are consumed, yet still drops are reported. I have been unable to find any configuration settings pertaining to prioritizing existing calls over new calls. What else can I look for to attempt to debug and fix this so that existing calls are not dropped? Thanks, Andrew -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Astricon is coming up October 9-11! Signup is available at: https://www.asterisk.org/community/astricon-user-conference Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dropped calls when all DAHDI lines in use
- Original Message - > From: "John Novack SCII_U" > To: "Asterisk Users Mailing List, Non-Commercial Discussion" > , "Andrew Martin" > > Sent: Monday, October 8, 2018 4:29:41 PM > Subject: Re: [asterisk-users] Dropped calls when all DAHDI lines in use > Have you given any thought to moving to at least a current supported version > 13? > Asterisk 11 has been EOL for some time now > I doubt you will get a resolution to a version no longer supported. > Moving to the latest version 13 should be relatively quick and painless, and > if > the issue persists you might find more assistance. > > John Novack > > > Andrew Martin wrote: >> Hello, >> >> I am running Asterisk 11.17 with DAHDI 2.9.0 and an OpenVox A800P with 8x >> analog >> POTS lines coming into my Asterisk server from the phone company. >> Internally, I >> have about 180 SIP clients defined in sip.conf. What appears to be happening >> is >> that if existing calls are consuming all 8 external lines and a new SIP >> client >> attempts to make a call, an existing call gets dropped. The asterisk log >> simply >> shows this as a normal hangup, so I am not able to easily distinguish >> between a >> normal hangup and this type of dropped call. In testing, I am able to get a >> new >> SIP client to report "service unavailable" when all 8 lines are consumed, yet >> still drops are reported. >> >> I have been unable to find any configuration settings pertaining to >> prioritizing >> existing calls over new calls. What else can I look for to attempt to debug >> and >> fix this so that existing calls are not dropped? >> >> Thanks, >> >> Andrew >> > > -- > Dog is my Co-Pilot John, Thanks for the reply. Yes, I am planning on moving to version 13 but need to find a solution in the interim. If there are any configuration options that pertain to which actions to take with existing calls when new calls come in, I think it is likely that they would be shared between both versions (and I want to make sure I have the correct settings when I switch to version 13 too). Can you advise on any tunables related to handling existing vs new calls? Thanks, Andrew -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Astricon is coming up October 9-11! Signup is available at: https://www.asterisk.org/community/astricon-user-conference Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
