[gazz]

Please help, someone!
I know this one way audio thing has been done to death: I have searched this site & others, reloaded & restarted my systems many times but I just can't get gossiptel to work its audio in both directions with asterisk. I have several other providers set up & working without issues, why does only gossiptel do this? To clarify - we are talking outbound & the other party not being able to hear me. I have tried inbound yet.

My set up:
asterisk@home box behind an ipcop firewall (tried with a DMZ but that didn't work either). One sipura 1000 connected.
The following UDP ports have been opened on the firewall and pointed to the *box:
5060-5062
8000-65535 (testing)
4569

relevant sip.conf

[general]

port = 5060 ; Port to bind to (SIP is 5060)
bindaddr = 0.0.0.0 ; Address to bind to (all addresses on machine)
disallow=all
allow=iLBC
allow=g726
allow=gsm
allow=ulaw
allow=alaw
externip=*mydyndns.org-provided-ipaddress*
localnet=192.168.0.0./255.255.255.0
context = from-pstn ; Send unknown SIP callers to this context
callerid = Unknown

#include sip_nat.conf
#include sip_additional.conf

[gossiptel]
username=93xxxxx
type=peer
secret=xxxxx
nat=yes
insecure=very
host=sip.gossiptel.com
fromuser=93xxxxx
fromdomain=sip.gossiptel.com
disallow=all
canreinvite=no
authuser=93xxxxx
allow=ulaw

If I take the asterisk box out of the equation & use outbound proxy on an x-ten lite softphone then it connects without an issue..... but that's not what I want to do. Any pointers anyone? Have I omitted to do something really obvious/simple?

[mberlant]

How sure are you that your externip address hasn't changed since you last updated it in sip.conf?

I had that problem with regard to passing audio with FWD and remote ATAs until I found a workaround. I set externip to my dyndns name (not address), because Asterisk does a lookup every time sip.conf is reloaded. Then, to keep it current I put /usr/sbin/asterisk -r -x 'sip reload' into my crontab.

I hope this is what is causing you pain.

[gazz]

Still in much pain mberlant!

I'm sorry for the confusion above but in fact I DO have a dyndns address rather than the IP address-my ISP allocates 'sticky' IP's so if the line is permanently connected then the IP tends to stay- I tried both and of course neither were successful. I tried the crontab thingy as well. No joy.

Anything else I can do before I skulk away and self-mutilate in a quiet corner?

[mberlant]

Well, if you allow me to stop laughing for a moment, let's think...

What device is responsible for the dyndns client? Has it been 25 days without a bump to your dyndns account? Is your dyndns still resolving to your host?

Do you have any off-premises client extensions? Are they behaving properly? Do they use your dyndns FQDN to access your box?

[gazz]

mmm. laughing at pain & self-harm huh? Perchance, are you a psychiatrist by day?

I think the dyndns thing is a red herring - I've tried putting in the actual IP address without success as well. I use IPCOP, which periodically updates the dyndns server - it certainly does this according to the logs. The IP address has changed quite frequently because of a recent upgrade in my DSL service to 1meg. but IPCOP has managed to keep up with the changes. When I ping the dyndns address I get a reply I get a response but I can't tell whether that's the router or the *box replying (how DO you tell?).

I have one off-premises extension and this took me ages for it to register successfully but it has done so.... irregularly - I still haven't made a phone call on it yet. Yes, I have put in the dyndns address in the sip host/proxy requirements for the off-site IP phone.

I'm using asterisk@home 0.9 at the moment & am sorely tempted to just wipe out everying and install 1.0 - may be I've put something out of joint in some crucial module? Will this pain never end?

[mberlant]

Sorry about the laugh at your expense. I am truly trying to help you laugh through the pain, since I have had to endure my share of it in getting my own Asterisk to the state it is in.

I currently have 6 on-prem extensions, 6 off-prem extensions, 9 two-way SIP service connections, one inbound only SIP service connection and one IAX2 two-way service connection. Each one of these connections came with its own portion of pain.

The reason my brain centers on the dyndns is this: up until about a month ago I was running my Asterisk on a Linksys WRT54GS router, which passed traffic wonderfully because the Asterisk was actually on the public side of the router and not in a DMZ or behind forwarded ports. The WRT doesn't have enough horsepower to do switching and voice processing, so I couldn't set up either an IVR function or a Voice Mail function. That led me to shift the Asterisk to a dedicated Intel box.

I installed Asterisk@Home (because I couldn't get Asterisk CVS to install well over Fedora Core 3 on a Pentium 200 MMX), put the Asterisk server in my router's DMZ (the same WRT with Linksys firmware) and migrated my .conf files to the new box. The box roared to life, but would not pass audio to or from FWD or any of my off-prem extensions, although every other connection worked.

It wasn't until I set my externip to my dyndns FQDN that I could get audio on the troubled connections, although the audio would quit every once in a while. That's when I learned to reload my sip.conf after suffering a PPPoE IP address change. Everything has been smooth ever since, which is why I have been fixated on that part of the configuration.

Your question about ping response is simple. Unless you have forwarded the ping port (whose number escapes me) to your Asterisk box, it is your router that is responding to the ping. An easy way to confirm successful forwarding through your router is to forward port 80 (http) or 22 (ssh) through your router to the Asterisk box and see if you can reach AMP from a web browser or open a remote shell or SFTP session via an SSH client, since both of these server daemons are native to Asterisk@Home.

I wouldn't be so quick to change out your Asterisk version because of this problem. First of all, there's a directory /etc/asterisk/default that has clean copies of all of the .conf files should you feel you are irretrievably corrupt somewhere. Secondly, if you have other services and clients working you probably haven't screwed anything up.

[gazz]

thanks - very useful advice. Give me an evening or two to mull over this. The reason I was planning to 'upgrade' to version 1.0 was purely because I may have broken 0.9 by trying to install CLID for zaptel in UK. Why oh why can't we have an easier upgrade path? I feel quite bad criticising a product as good as this one but you have to agree this is becoming quite important for a product like *@H - which is essentially aimed at wetbehindears types like me. ops:

[mberlant]

If you are ready to tackle modifying the CLID on zaptel, your ears are somewhere between barely damp and bone dry. I too wish there were an easier way to upgrade Asterisk@Home without clobbering the whole system. Perhaps someone else knows a way?

[mayoor]

Is asterisk @ home .9 or 1.0 safe enough to be outside the nat ---- like having a external ip address. I have a provider that can give 5 address I am not sure how to setup the dsl modem and a router to do that? I am using wrt54g and have the same problem of audio only going one way. I appreciate the help I am very new to linux and asterisk

Thanks in advance

[gazz]

hi Mberlant.

As suspected I upgraded to *@H 1.0 and my troubles with gossiptel went away - the audio has returned with the settings above unchanged. One thing pointed out before is that sometimes just reloading settings doesn't do the job - you have to reboot too. I thought I'd escaped all of that in windoze. What a disappointment! Anyway, one problem solved but another appears: sipgate.co.uk has stopped working inbound. For another thread another day I think. Thanks for the help above. As for setting up CLID for the zaptel line - It's just a case of following these instructions isn't it? http://www.lusyn.com/asterisk/patches.html
Anyone can type them out.

mayoor.
your q may have done better in its own thread m8. Remember that even if you put your *box into a DMZ or give it its own external IP, the IP phones are usually behind a NAT and will then have problems communicating (admittedly not quite a great, I suspect). As far as I'm aware there isn't an intrinsic firewall on *@H but I stand to be corrected.