Barfjelly / google-voice-sipsorcery-dialplans

Automatically exported from code.google.com/p/google-voice-sipsorcery-dialplans
0 stars 1 forks source link

Can't call SIPBroker addresses (and this is not related to my Linksys dialplan) #120

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Dial a sipbroker address. On my phone I dial it according to their dialplan, 
with a '*' - the number - and an ending '#'.
2. Monitor the call on the Liksys webpage.
3. Not hear anything on the phone even after waiting a few minutes.

What is the expected output? What do you see instead?
I dial the SIPBroker test number frequently to test the phone every few weeks. 
I should the confirmination that I'm connected but instead nothing. No sound at 
all.

What version of the product are you using? On what operating system?
Linksys PAP2T-NA

Please provide any additional information below.
I haven't changed either my SIPSorcery dialplan (yet) or my Linksys one which 
did work up until a few days ago. I was able to dial the SIPBroker test number 
up until this point and hear the confirmination.

The only thing changed is my router port forwarding. I was forwarding on my 
Linksys router the following:
#1 - Start [5060] / End port [5060] / my linksys pap2t-na
#2 - Start [8000] / End port [8999] / my linksys pap2t-na

and was able to successfully dial said number. Now, I discovered 'Single port 
forwarding' on the router settings. I figured 'Why am I forwarding (on the 
multiple port forwarding page) ports that have the same start and ending 
number? - See list'.

So I change it and now on 'Single port forwarding', which was originally blank, 
it now has the single entry for port [5060] TCP/UDP to my linksys pap2t-na.

I did check the addresses and they are the same on both port forwarding pages, 
and are also enabled.

For that point on, I believe (nothing else has changed at all), was when I 
could no longer dial the number previously mentioned. I didn't test it 
afterwards to see but now I have to say that that is the reason, maybe, since 
nothing else is different.

It is important to note that on my Linksys PAP2T-NA, when I dial the SIPBroker 
test number, I get zero returned packets/data (I do see it sending data, but 
nothing comes in). 

When dialing numbers that will go through Google Voice (i.e. everything not a 
SIP address :) ), I will get through and hear sound and everything in-between.
I'll even see returned packets too. I can call my banks's weather service 
number and hear the time and temperature currently available, but I can't call 
SIPBroker addresses and hear the recording messages, strange isn't it?

I don't know or think you would be the correct contact for this problem. But, I 
thought I would share the problem and my information this far before I contact 
VOIPLink support who might also come to the conclusion I have and maybe also a 
solution (and if they do that, I'll post it here). 

Original issue reported on code.google.com by XANAVi...@gmail.com on 18 Feb 2011 at 3:34

GoogleCodeExporter commented 8 years ago
Could you clarify, what is that SIPBroker test number? May I see the Console 
output when you dial this number?

I'm also wondering if the situation improves when you revert the router's port 
forwarding to their previous settings.

Original comment by mte...@gmail.com on 19 Feb 2011 at 5:32

GoogleCodeExporter commented 8 years ago
Sure.
The SIPBroker test number (*011188888@sipbroker.com or '*011188888#' on my 
phone) is for testing whether or not the SIP account is set up properly.

I'd love to provide you the console logs of before I reset the forwarding 
settings, but there is nothing logged at all. Well, nothing but keep-alive 
messages. But no logs from calling the number show up anywhere, after waiting a 
minute or two.

I haven't yet had a chance to try whether or not it improves if I change those 
settings back. I'll try that out in a second.

Original comment by XANAVi...@gmail.com on 19 Feb 2011 at 5:53

GoogleCodeExporter commented 8 years ago
Oh, by the way, just a moment before I start testing whether or not reversing 
the port forwarding settings, I checked the router logs for incoming dropped 
data.

There was nothing listed, so either the router is not dropping packets itself 
or the logging feature is broken (of course, the second one I doubt since it 
logs outgoing connections okay, but maybe always a possibility).

(A few minutes later)

Okay, after changing the port forwarding settings back to what they were 
originally..
Unfortunately, nothing has changed for me. SIPSorcery's console log still only 
shows keep-alive messages.

I am, of course, logged in correctly to SIPSorcery on my Linksys PAP2T-NA. 
Otherwise, no Google Voice calling (which by the still does work A-OK).

I don't even hear a ringing sound that I believe should come through to show 
that it is dialing the SIPBroker test number (but I am not sure if SIPSorcery 
or my ATA generates it). I hear two when doing Google Voice calls, one is the 
'better sounding' one and the other Google Voice's normal ringing sound.

Original comment by XANAVi...@gmail.com on 19 Feb 2011 at 6:06

GoogleCodeExporter commented 8 years ago
Here is the output of my Linksys PAP2T-NA's status page during a call to the 
SIPBroker number.

If you'd like a status page log from me during a Google Voice call to compare 
(you might), just ask. I cam't make calls at this time since it would rude to 
do that at 1:30AM, so I'll do it in the morning.

It's in .doc format for Word 97/2000/XP versions. If it doesn't work I can 
provide it in ODF format.
It's fsr too long to fit in this text box (Google says I'm sending an invalid 
request when I just to try post it in this text box).

Original comment by XANAVi...@gmail.com on 19 Feb 2011 at 6:28

Attachments:

GoogleCodeExporter commented 8 years ago
> Call Mapped RTP Port: 
> 8796 >> 0

Apparently you're not forwarding RTP port and it may be the cause of your 
problem.

> Last Called Number: 
> *011188888@sipbroker.com

Apparently you're communicating with sipbroker.com directly, that's why the 
call doesn't appear in SS console. I believe you're programmed this number in 
your ATA rather than used SS to connect it for you (by adding the number to 
your Speeddial table, for example).

What I'm saying, this issue has nothing to do with Sipsorcery and its dialplan.

Now let's think what might be wrong. When you're dealing with Sipsorcery, it 
acts like a STUN server, replacing local IPs with your external IP. That's why 
the thing works even if STUN is not enabled in your ATA. Sipbroker is a 
different story!

Please check STUN settings in your ATA, you may need to enable STUN mapping and 
enter STUN server name/address (e.g. stun01.sipphone.com).

Original comment by mte...@gmail.com on 19 Feb 2011 at 10:12

GoogleCodeExporter commented 8 years ago
I have STUN enabled in my ATA.
The following server is configured:
stun.call4-free.com

I do see 'Stunning' as a status message when calling numbers, too. So it is 
contacting that server.

Anyway, I just thought I'd tell you that.
I haven't contacted VOIPLink yet.

Yes, my dialplan in my ATA is:
(*xxx[x*]. 
<:@sipbroker.com>|*xx|[3469]11|0|00|[2-9]xxxxxx|1xxx[2-9]xxxxxxS0|xxxxxxxxxxxx.)

Because, otherwise (see Issue #116) I will not be able to dial those numbers, 
since I'll just get a busy tone immediately for some reason.

I can try to remove the SIPBroker portion out my ATA dialplan and see if it 
still does it, but I'm fairly certain I won't be able to dial those numbers 
again.

I do have SIPBroker configured in my SIPSorcery dialplan (not that you're 
doubting that) since I can dial their numbers directly using any SIP client on 
my cellphone (i.e. Linphone) or on my computer (ExpressTalk).

I do have RTP forwarding enabled. I'm forwarding the ports [5060] and 
[8000-8999] to 172.16.1.249 (the inside IP for my ATA).

Original comment by XANAVi...@gmail.com on 20 Feb 2011 at 4:40

GoogleCodeExporter commented 8 years ago
Yeah, I removed the 'Dial SIPBroker directly' portion and I can't dial those 
numbers anymore.
My ATA reports it as 'Invalid' if I try to dial star codes (like the SIPBroker 
test number available at *011188888). My ATA supports those special codes like 
from the phone company has, as it turns out.

Like *82 (unblock) and *67 (block). I wonder if that could be the cause of not 
being able to dial SIPBroker star codes or something.

I'm still working at it, I'm going to continue and maybe post some more if I 
figure something out.

Original comment by XANAVi...@gmail.com on 20 Feb 2011 at 4:48

GoogleCodeExporter commented 8 years ago
Sorry for updating so much. I hope you don't have this as starred...
I'd hate to fill up your inbox with just this one issue.

So, I can't find any settings in my Linksys PAP2T-NA to disable feature service 
codes.
That's bad.

So, I did a Google Voice call just to see something and it turns out that info 
status you referenced in your post is always 0 on the other end.
I am forwarding in my router settings ports [8000-8999] and the ports my ATA's 
selecting are ones that are in that range.

From yesterday's SIPBroker test call:
> Call Mapped RTP Port: 
> 8796 >> 0

From my recent Google Voice call:
> Call Mapped RTP Port:
> 8140 >> 0

Original comment by XANAVi...@gmail.com on 20 Feb 2011 at 5:05

GoogleCodeExporter commented 8 years ago
For my final update of today (since it's Saturday), I'm going to provide you 
with an status list from my Linksys's call info webpage.

I didn't get any closer to solving why I can't dial SIPBroker star codes 
directly even though I can with everything else linked to my SIPSorcery account.

But here's the info for during a Google Voice call. I removed the area code 
number from the phone number I was dialing.

Original comment by XANAVi...@gmail.com on 20 Feb 2011 at 5:19

Attachments:

GoogleCodeExporter commented 8 years ago
Look, your ATA is forwarding test calls directly to Sipbroker and therefore, 
the issue is not related to Sipsorcery and your dialplan. Probably it makes 
this trouble ticket invalid here.

As to service codes, I'm sure it has nothing to do with the issue. If your ATA 
treated dialed number as the service code, it wouldn't connect to Sipbroker at 
all.

If you want to be able to dial star-prefixed numbers, you need a corresponding 
entry in your ATA's dialplan (by default, only digits are accepted). This entry 
can forward star-prefixed numbers to Sipbroker, Sipsorcery or any other 
provider of your choice. I have to mention that your test only validates 
connection to Sipbroker and independent from SS status: test number may work 
even though SS server is down, your dialplan is incorrect etc. Reverse is also 
true: if SS works, test connection may not work (your case).

Original comment by mte...@gmail.com on 20 Feb 2011 at 6:56

GoogleCodeExporter commented 8 years ago
Okay, very well then.
You sound angry at me for being a novice and posting here for some reason.
I'm not angry back but it does make me sad to see that my asking for help here 
is not an accepted solution for being stuck.

In any case,
I modified the '@sipbroker.com' part of my before mentioned dialplan (the one 
from before I changed it back) into '@sipsorcery.com'.

It works now, so therefore thank you Mike T.

Original comment by XANAVi...@gmail.com on 20 Feb 2011 at 7:24

GoogleCodeExporter commented 8 years ago
I'm not angry, I'm just trying to stay on the topic (which is Sipsorcery, Ruby 
dialplans and Google Voice). There are many other VoIP-related forums (such as 
Voxilla).

Re: Sipbroker test number works when you connect via Sipsorcery. This is yet 
another argument that the issue is STUN-related. The difference between "direct 
to Sipbroker" and "Sipbroker via Sipsorcery" is that in latter case SS server 
mangles IP addresses. Probably you need to try a different STUN server. I don't 
have experience with PAP2T but SPA3102 has separate "NAT mapping enabled" 
settings for each and every gateway (LINE1, PSTN, GWn). It might be the case 
with PAP2T, too!

Original comment by mte...@gmail.com on 20 Feb 2011 at 9:21

GoogleCodeExporter commented 8 years ago

Original comment by easter...@gmail.com on 20 Feb 2011 at 2:55