Windstream PRI

[sstelecom]

Let me start by saying I think it is a carrier issue....but still wanted to put it out there.

I have a customer complaining of periodic one way communications on their Windstream SIP trunk.

It was working fine until we started porting over remote store numbers.

This is how the trunk is configured.

type=peer
qualify=2000
dtmfmode=rfc2833
host=192.168.250.2
insecure=very
context=from-pstn
canreinvite=no
nat=yes


Just looking for ideas

Chris

 

[telcodog]

Did you get those peer details from the carrier? They should be sending you the setup required for asterisk to work on their network. I have a carrier that only requires the public ip address to work (no registration) but the problem with that setup is the system never checks to see if the trunks are actually accessible or not and always show offline in the Operator Panel, so I programmed the peer details like this:

type=peer
host=xxx.xxx.xxx.xxx (carriers public IP)
trustrpid=yes
sendrpid=yes
qualify=yes
insecure=port,invite
dtmfmode=rfc2833
disallow=all
context=from-trunk
canreinvite=nonat
allow=ulaw



Under the Tools tab, what do you get when you enter the sip show peers command?

 

[theislandtech]

one way audio is usually a firewall issue

 

[sstelecom]

Let me stress, that it is not on every call.

 

[getsomesun1]

What Kind of Firewall is in front of the UCx? Check SIP ALG and make sure it is turned off. Called SIP Transformations in Sonicwall for instance. This will give you issues.

 

[theislandtech]

Why is the host= pointing to an internal non routable IP?
Is it because of Windstream provided equipment on site?

 

[sstelecom]

Yes. Windstream had equipment on site and that is that IP address.

 

[emtsupport]

A couple of suggestions, if I may.

If the device onsite has ADTRAN on the label, a power cycle may be in order. I have seen on occasion where these devices can be unpredictable at times and a reboot seems to stabilize them.

I think nat=no would be more appropriate for this configuration as it this device appears to be local to the UCx. (i.e. not going through a router)

The randomness might suggest a bad channel on the PRI itself. They can be difficult to test, but if you can test all the channels then at least you can sleep well knowing all channels tested good.

You might ask the customer to press 9*9 from any phone to stamp the log when this occurs. This may expose a pattern where it occurs at a particular time of day or on one nxx and not another.

Finally, you can always open up a ticket with E-MetroTel. I realize this is problematic for you and your customer, but it is interesting and we all may learn something from it!

Sincerely,
pnp

 

[theislandtech]

Can you provide a sketch of your setup?