I've exhausted my troubleshooting abilities on an issue and looking for some advice moving forward.

First, I'm thinking this is either an issue with my ISP (Comcast Business) or my new modem (ARRIS SB6190) or both.  I've happily run OpenWrt on a NetGear WNDR3700v2 for 3 or 4 years behind a Motorola SB6141 modem.  I have raspbx running on a raspberry pi for about a year and this was all fine until a few months ago.  I began getting latency spikes and packet loss confirmed by MTR.  I ended up buying a new modem (the SB6190) and that problem seemed gone.  Shortly after, I upgraded OpenWrt from 15.01? to the current version 15.05, choosing to keep the settings.  All seems swell.

A few days after the upgrades, I can't make outgoing calls.  Never had this trouble before and haven't changed any firewall settings.  I restarted asterisk, checked firewall settings, SIP settings and even went back and forth with my VOIP provider (Vitelity).  Though incoming traffic works fine and SIP registration works fine, Vitelity said they saw no traffic from me when I made outgoing calls.  I logged onto my router and performed tcpdump and could clearly see the packets (UDP) being sent, but no return packets (huh???).  I reset the WAN interface on OpenWrt and even restarted the router, but it did not help.

What did and still does work?  Restarting the modem.  When I restart the modem, I'm able to initiate SIP calls (UDP connections to Vitelity's SIP server) for a few days (2-5), after which they begin to fail.  I've found no other network issues at all.  I spend most of the day with persistent SSH and VPN (IPSEC and SSL) connections that work just fine, not to mention the gobs of web traffic and netflix streaming.

I guess I could buy a different modem and try that, but how could a modem malfunction in this very specific way?  Any advice on how to figure this out would be appreciated.  In the meantime, I'm cycling my modem every few days.

Thanks.

Sorry i am an asterisk noop but i think,
it is not possible that the modem are the reason even it is a pure DSL-ethernet-bridge.
I thing something goes wrong at the update.

How have you realyze the NAT-tunneling ?
If you tunneling the NAT via STUN i can not really help you.
But you can help me if you post the relevant code.
I try to use STUN in the next days.

If you use portforwarding be first sure that it works.
make a online portscan like here http://nmap.online-domain-tools.com/
scan your SIP port 5060
be sure that you have portforwarding rules for RTP the rtp-range can be found in /etc/asterisk/rtp.conf

Then the next problem is that are the public IP must be inside the SIP header.
In the moment my Asterisk is direct connected to the WAN.
But asterisk start first and use a wrong (private) Address, the solution is to restart asterisk after the
WAN connection is etablisht.

from this reason try:
wait if you have internet connection and restart asterisk
post the result here.

An other question is what say the asterisk console (asterisk -r)?

It works fine for me with:

res_stun_monitor.conf

[general]
stunaddr = stun.adressofyourprovider.tld:3478
stunrefresh = 30

sip.conf

[general]
context=default                     ; Default context for incoming calls. Defaults to 'default'
allowoverlap=yes                     ; Disable overlap dialing support. (Default is yes)
udpbindaddr=0.0.0.0:5060
tcpenable=no                        ; Enable server for incoming TCP connections (default is no)
transport=udp                       ; Set the default transports.  The order determines the primary default transport.
srvlookup=yes      
subscribe_network_change_event=yes
nat=force_rport,comedia


register => username:password@provideraddr.tld:5060/username


[example_provider_01]
context=default
type=peer
host=provideraddr.tld
port=5060
fromdomain=provideraddr.tld
insecure=port,invite

dtmfmode=rfc2833
disallow=all
allow=ulaw,alaw

defaultuser=username
fromuser=username
secret=password
callerid=00493012345678

localnet=192.168.0.0/255.255.0.0
nat=auto_force_rport
directmedia=no
outboundproxy=proxy.provideraddr.tld:5060

you need the res-stun-monitor it is inside here:
https://yadi.sk/d/clbIuF4Y39HGQf
see https://forum.openwrt.org/viewtopic.php … 08#p349408

Thanks for your response.

I don't see how it could be a NAT thing since it affects outgoing packets, which never make it to the recipient.  Also it's DOCSIS (Comcast Business), not DSL.  Again, it works just fine for 2-5 days, then the behaviour resumes and packets disappear - they're visible on the router using tcpdump, but the recipient sees nothing.

hmm OK i have overreading some parts, you are right.

Is the destination behind a NAT, and have you try to connect the SIP-port via portscan ?

My only last idea is that some UDP package are lost,
because DOCSIS shared medium overload etc ...
Have you try it to connect via TCP ?

Destination is Vitelity, outbound.vitelity.net

Wireshark shows packets going out from router for SIP INVITE, but nothing coming in.

A few choice selections from the first outgoing packet:

User Datagram Protocol, Src Port: 5260 (5260), Dst Port: 5060 (5060)
    Source Port: 5260
    Destination Port: 5060
    Length: 1594
    Checksum: 0xb073 [validation disabled]
    [Stream index: 8]

Request-Line: INVITE sip:811@outbound.vitelity.net SIP/2.0
    Method: INVITE
    Request-URI: sip:811@outbound.vitelity.net
        Request-URI User Part: 811
        Request-URI Host Part: outbound.vitelity.net
    [Resent Packet: False]

This repeats until packet 31046 (first was 15052), when the call ends.

Lots of information in the capture, much of it sensitive of course.  I see this repeated "Suspected resend of frame: 15052", which was the first packet sent.

Again, calls begin to fail few days, but work properly after a modem restart (router restart has no effect).

vitelity.net show only registered users their possible configurations but "outbound.vitelity.net" looks for me that you are connectect via proxy.
Is Asterisk behind a nat or not ?
what show

stun show status

?
what stands at: subscribe_network_change_event in the sip.conf

The fails does not make sense and i think it is not a NAT problem too, but be sure that all settings are correct.
I am sorry the combination of fails that you have are too strange, i have no idea.