dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
5333
DocLarge
Premium Member
join:2004-09-08

2 edits

DocLarge

Premium Member

[PBX] Finally!!! (Good Incoming/Outgoing Calls w/o Dropouts)

Click for full size
It's not like it took forever *heh*, but I've finally made sense of the "little things" that were plaguing my installation.

My dropout issues went away when I made sure to use "type=friend" and "insecure=very," funny enough. Jet101 (Jess) was riding me about using "insecure=invite,port," so I finally went with it per his suggesting and moved a few other things around; it all appears to be "bulletproof" at this stage.

I also locked down the portforwarding aspect as well; the above attached illustrates how I used "port range forwarding" via my Linksys WRV54g to make everything work.

Additionally, here's the peer detail template I'm using as of now (feel free to cut & paste):

NOTE: THIS CONFIG SEEMS TO WORK GOOD BEHIND CONSUMER GRADE ROUTERS (I.E. LINKSYS)

Trunk (Peer Details)

username=1777xxxxxxx
type=friend This is CRUCIAL
secret=[password]
qualify=yes
nat=yes
insecure=very Also CRUCIAL
host=callcentric.com
fromuser=1777xxxxxxx
fromdomain=callcentric.com
dtmfmode=inband
disallow=all
context=from-trunk
canreinvite=no
authuser=1777xxxxxxx
allow=ulaw,alaw,g729,gsm

I'm going to move my PBX back behind my 871w momentarily and see what the differences are...

Catch y'all in a few...

Jay
MartinM
VoIP.ms
Premium Member
join:2008-07-21

MartinM

Premium Member

I would replace insecure=very by insecure=port,invite

insecure=very is deprecated.

Also might want to add

sendrpid=yes

If you want to pass your own CallerID Number. (sendrpid stands for send remote party id).

Qualify is a good idea as it act as a "Keep Alive" for your NAT external port and also if your provider becomes unreachable, and you have more than 1, your PBX will be quick to switch to the next trunk..

dtmfmode=inband not sure about that but if it works for you. It won't work very well with some of the codecs you have allowed such as g729 and gsm.

I would also add trustrpid=yes for incoming Remote Party ID.
DocLarge
Premium Member
join:2004-09-08

DocLarge

Premium Member

Thanks for the suggestion... Being that the above is working from behind the Linksys, I'm holding fast until any "nuances" pop up... The big test will be if the above config works well behind the 871w...

Jay
mazilo
From Mazilo
Premium Member
join:2002-05-30
Lilburn, GA

mazilo

Premium Member

said by DocLarge:

The big test will be if the above config works well behind the 871w...
Jay, is 871w a symmetrical NAT/Firewall? IIRC, a Linksys WRV54G is a non-symmetrical NAT/Firewall.
DocLarge
Premium Member
join:2004-09-08

3 edits

DocLarge

Premium Member

That's a question I've never been asked before and truthfully, I have no answer for...yet

I'm scoping through the net right now; I may have to scoot over and ask the cisco guys this question...

Jay

EDIT

Well, I'm batting 50% at the moment. I've moved my PBX back behind my 871w and have the following results:

- With the previously posted above config, CallCentric trunk is receiving/making calls with "zero" dropouts

- With the previously posted above config, VoipTalk trunk receives calls with no dropouts but when I make calls, it drops connection at 10 seconds consistently.

Also, here's the portforwarding scheme I'm using:

Step 1 - Create Access-List

access-list 130 permit udp any any range 5000 5084 (Port Range Forwarding)
access-list 130 permit udp any any range 8000 8766
access-list 130 permit udp any any range 10000 20000

Step 2 - Create Route-Map

route-map freepbx permit 1
match ip address 130

Step 3 - Apply Route-Map

ip nat inside source static 172.16.3.3 74.xx.xx.xx route-map freepbx

So, it looks like the issue resides with outbound calls when behind the 871w... I've got a good starting point to work with
A_VoIPer7
join:2009-11-04

A_VoIPer7

Member

If there's not much traffic flowing through your 871w, you might turn on debugging during the failure and see if it sheds any light.

»www.cisco.com/en/US/docs ··· p1086651

Note, if you have console logging turned on, this can severely impact your router.

»www.cisco.com/en/US/tech ··· 4c.shtml
Warning: Excessive debugs to the console port of a router can cause it to hang. This is because the router automatically prioritizes console output ahead of other router functions. Hence if the router is processing a large debug output to the console port, it may hang. Hence, if the debug output is excessive use the vty (telnet) ports or the log buffers to obtain your debugs. More information is provided below.

Note: By default, logging is enabled on the console port. Hence, the console port always processes debug output even if you are actually using some other port or method (such as Aux, vty or buffer) to capture the output. Hence, we recommend that, under normal operating conditions, you have the command no logging console enabled at all times and use other methods to capture debugs. In situations where you need to use the console, temporarily turn logging console back on.
DocLarge
Premium Member
join:2004-09-08

DocLarge to mazilo

Premium Member

to mazilo
Mazilo,

per one of the forum members in the Cisco forum, yes, the 871w can be considered a symmetrical firewall...

Tried a multitude of "peer detail" changes on the Voiptalk trunk last night and still haven't nailed it down. A_Voiper, I'll probably try debugging later...

Jay
vincentdelpo
join:2010-06-24

vincentdelpo

Member

Considering that Linksys is aimed at consumers and Cisco is aimed at businesses, I wouldn't be surprized if 1) the Cisco were a symmetrical NAT, and thus 2) an Asterisk server worked fine with the Linksys but had issues with the Cisco.
mazilo
From Mazilo
Premium Member
join:2002-05-30
Lilburn, GA

mazilo

Premium Member

said by vincentdelpo:

Considering that Linksys is aimed at consumers and Cisco is aimed at businesses, I wouldn't be surprized if 1) the Cisco were a symmetrical NAT, and thus 2) an Asterisk server worked fine with the Linksys but had issues with the Cisco.
Bingo! That's what I was going to say, but you beat me to it.
Dan_voip
join:2007-01-03
Saint-Hubert, QC

Dan_voip to DocLarge

Member

to DocLarge
said by DocLarge:

I also locked down the portforwarding aspect as well; the above attached illustrates how I used "port range forwarding" via my Linksys WRV54g to make everything work.
With your working configuration behind Linksys router I would remove port forwarding (eventually one by one) and do some tests. With phones registered only from the internal network you shouldn't need any port forwarding.
DocLarge
Premium Member
join:2004-09-08

4 edits

DocLarge

Premium Member

AND THE SAGA FINALLY ENDS HERE!!!!!!

Yes,YEs, YES!!!!! I put in another round of searching on the net and finally found my magic bullet in one of the trixbox forums. The culprit had been "sip_nat.conf" the entire time but I wasn't finding the specifics required to correct it until now:

Sip_nat.conf

nat=yes
canreinvite=no
srvlookup=yes
externip=74.xxx.xxx.xxx
localnet=172.16.3.0/255.255.255.0

Up until about 30 mins ago, I had "nat," "externip," "externrefresh," and "localnet" in this directory, but once I removed "externrefresh" and added the above settings to sip_nat.config, call dropping finally stopped! Oh....as of now, my PBX is running from behind my 871w!!! (BOOM-SHA-KA-LAKA, BABY!!!!)

Here's the process I followed (CISCO 871w router was used for the below port forwarding):

Step 1 - Create Access List (Port Range Forwarding Method)

access-list 130 permit udp any any range 8000 8766
access-list 130 permit udp any any range 10000 20000

NOTE: Ports 5000 - 5084 are open/transmitting "without" any direct configuration; if needed, just add the
range as an additional access-list statement:

access-list 130 permit udp any any range 5000 5084 (optional)

Step 2 - Create Route-Map

route-map freepbx permit 1
match ip address 130 (This line refers to the access-list created in the step 1)

Step 3 - Apply "One-to-One" NAT Mapping With Route-Map:

ip nat inside source static [internal ip] [external ip] route-map freepbx

Here's a better example of the above:

ip nat inside source static 172.16.3.4 74.55.43.3 route-map freepbx

The above statement tells the router to create a "one-to-one" mapping from the "internal ip address" of your PBX server to your "external ip address" assigned to you by your ISP, along with saying that any VoIP related issue is to be handled by the route-map statement (freepbx)

Next are the trunk settings seen below (CallCentric for Stateside Calls/VoipTalk for UK Calls):

CallCentric Trunk/Peer Details
call-limit=5
username=818xxxx
type=friend
secret=[password]
qualify=yes
nat=yes
insecure=very
host=voiptalk.org
fromuser=818xxxx
fromdomain=voiptalk.org
outboundproxy=nat.voiptalk.org
dtmfmode=inband
disallow=all
context=from-trunk
canreinvite=no
authuser=818xxxx
allow=ulaw,alaw,g729,gsm
CC Dial Pattern-1NXXXXXXXX and 011.

VoipTalk Trunk/Peer Details
username=1777xxxxxxx
type=friend
secret=[password]
qualify=yes
nat=yes
insecure=very
host=callcentric.com
fromuser=1777xxxxxxx
fromdomain=callcentric.com
dtmfmode=inband
disallow=all
context=from-trunk
canreinvite=no
authuser=1777xxxxxxx
allow=ulaw,alaw,g729,gsm
VoipTalk Dial Pattern-001. , 0|Z. , and 044+XXXXXXXXXX

Most folks who might copy the above configs will probably substitute "insecure=very" with "insecure=invite,port" and "type=friend" with "type=peer" and so on... I probably will try that too after I document a few more things.

Otherwise, it's time for the next project

Jay
DocLarge

DocLarge

Premium Member

Change "type=friend" and "insecure=very" to "type=peer" and "insecure=invite,port" and everything is still rolling.

All is good. Case closed!!!

THREAD CLOSED