[ENGLISCH] Problems with incoming VoIP calls not connecting.

[pepsi_max2k]

Hey all, I have a 5050 in the UK that I've got connected as an ATA (FB LAN A > another router > modem > internet), and have problems receiving VoIP calls.

I have a sipgate.co.uk account registered that works fine for outgoing calls, and sometimes it works for incoming, but other times when you call the sipgate landline number it never rings (at most i just get a quiet "click" sound every 5 seconds), either on my phone or the caller's.

The call appears in my sipgate account as "missed" as i'd expect, but it doesn't show on the FritzBox call list at all.

Anyone know what the problem might be?

As it's behind a NAT I have a stun server listed, stun.sipgate.net, but don't have the NAT Aware box ticked. I also have the FON 1 port that my phone's connected to set with my Analog line as primary number, with the sipgate number as an additional number, and have it ticket to react to all calls.

 

[ThSteffens]

Would you please define "another router". There are 4 types of NAT. STUN works only for 3 of them. If the NAT router provides "Symmetric NAT" you need to switch off STUN and enter a few port forwardings in the router.

 

[pepsi_max2k]

It's a WRT54GL running DD-WRT v24 RC-3 nokaid version firmware. If v24 final is anything to go by, it should feature a "SIP-aware firewall" whatever that means.

I'm actually starting to think it might be one of the settings as I've changed things about a bit to simplify them and I've not been able to call my sipgate number since, though I'm sure it's been intermittent even when it was working


update: quick update; with analogue and voip connected (with fb as ata), React to all numbers unticked and analog as primary, sipgate number as a sole seconday, didn't once get through via a softphone on my pc.
as above but with analog disconnected, didn't get through with softphone or my landline.
as above but with analog disconnected and react to all number ticked and it now rings for both caller and recipient phone via softphone, havent yet tested landline or waited to see if it fails later.

fwiw, the latter was the only one that gave me any telnet output with voipd -v, starting with a UDP Request: INVITE then list of audio codecs then cancel. Seems you need React To All Numbers ticked to get anything at all then, at least when Analog is the primary number for the Fon port.

also, voipd -v showed "call from sip:{incoming callerid?}@sipgate.co.uk to 0 (sip0:{displayed callerid?})" I'm presuming the "to 0" bit is the redirect to fon 1, so without that redirect it would show nothing...
and, sipgate shows all calls that dont ring as failed, but the one that rung as recieved which ain't really true as i never answered. maybe sipgate, maybe a fon issue.


oh gawd... can't be that, it's not ringing again voipd -v no output, but no changes made to the above :| and sipgate shows another missed call.

now it gets even more weird... called and got one ring, then buzzing. voipd output was a normal incoming call output, phone rang... wtf?

looks like a bug in voipd now.... why am i always the one who tests this stuff more than the coders? come back in an hour to get the full story...

looks very much like >120 seconds of inactivity (a REGISTER or a previous successful incoming call) in voipd causes incoming calls to be disregarded. still testing to make sure...

cofirmed with react to all numbers unticked (rings within 120)....

 

[pepsi_max2k]

Right, I know what the problem is (ish) now.

After 120 seconds (2 minutes) of inactivity in voipd - that is, no output via verbose mode - all incoming voip calls fail, with no recognition by voipd that they are being made (no voipd -v output), and no ring tone for caller or called.

If a UDP REGISTER is made by voipd (every 540 seconds by default), or an incoming call is registered (UDP Request: INVITE) then within 120 seconds of this another succesful incoming call can be made, but after this time it fails as noted above.


Analog connection has no affect on this, and continues working throughout. The React To All Calls box also has no affect on the above.
I've not tested it yet but presumably an outgoing VoIP call will cause activity in voipd and therefore reset the 120 second time.


I also don't know what the actual cause of the problem is - whether it's NAT related (maybe any outgoing activity within 120 seconds allows the firewall to allow incoming data on the same port within 120 seconds?), if it's a sipgate issue (unlikely as it's recording all calls made and continues to list the thing as online, and I've not had a problem with it with other hardware), or if it's a Fritz!Box hardware or software issue.

For now the only solution I can think of, if it's not NAT related, is to force voipd to send a UDP REGISTER every 120 seconds as oposed to every 540. I think it's a simple change but I'm not sure. Failing that, a script to "voipd -s, voipd" might work but i guess that would kill any voip sessions if they were in use when voipd -s was called

update: an voip outgoing, which all feature a UDP INVITE, resets the 120 timer too.
just picking up and dropping the receiver though, which causes the following output in voipd, does not reset the thing and incoming calls still fail within 120 secs after.
voipd[1524]: incoming(5:appl=4 plci=0xb05 ncci=0x0 incoming): 11 <- 0#{sip number}
voipd[1524]: telapp_incoming - NOT running (voip=0)
voipd[1524]: 0: connected vcc 0/0/RBE/14 stay online 1
voipd[1524]: disconnected(appl=4 plci=0xb05 ncci=0x0 incoming): remote: 0x0000 (0x0000) -


I also can't find any register time setting in /var/flash/voip.cfg

May also be a STUN issue - stun.sipgate.net appears to be 10000, but fritzbox defaults to the standard 3478 port. ........ nope, not the stun port. though at least it's correct now. (stun.sipgate.net:10000 in the web config).

Not a port forwarding issue either, forwarding all sipgate ports (5004 UDP, 5060 UDP, 8000 - 8012 UDP, 10000 STUN, 3478 UDP & TCP) and 7078-7079 udp as it comes up in debug text, doesn't solve the issue.

 

[ThSteffens]

You could play around with some values in "/var/flash/voip.cfg".

I would change the "sipping_interval" to something smaller than 120s for all providers. In my Fritzbox it is set to 280s.

 

[pepsi_max2k]

is sipping interval the same as sip registration interval? in that case why would it be set as 280 as it is in voip.cfg, but change to 540s? I know sip providers can force this on a box but if that's happening, changing it to 120 isn't gonna matter is it? it also has sipping_enabled = no; so i better go figure out what it is / does.

also can't see much else that might help when changed, maybe ttl = 30m and is_nat_aware = no.
only other thing is maybe to run something that causes voipd to send a small udp packet every 2 minutes.


Also found this, which kinda confirms what i was thinking:

Once registered with the SIP Registrar, either the phone or the SIP Registrar must maintain the communication channel open by sending keep-alive packets to the SIP device before the binding expires in the NAT device. The packets could be either SIP packets send by the device or IP packets sent by the Registrar. It is possible depending on the type of NAT that sending keep-alive packets from outside is not enough, in this case the device inside NAT should take care of this by lowering the Registration interval bellow the NAT binding expiration time (usually a value of 85 seconds will suffice). Now, having a permanent communication path open between the SIP Registrar and the SIP device, it is always possible to ring the device behind the NAT and to start negotiating a SIP session.

it also mentions something about this being on top of using stun as it's not that reliable. anyway, i'm gonna test the fb connected direct to the dsl line tomorrow and if it still happens i'm gonna be pretty stumped.

 

[pepsi_max2k]

Seems like it's a NAT issue. It works fine when connected via DSL, cept I get 1/6 of my regular sync rate with it so can't be having that

Now have to figure out how I can use it with NAT, as port forwarding don't work, and I also don't seem to be able to get vi/nvi working on the fritzbox .


UPDATE: dd-wrt voip version with milkfish sip firewall integrated and enabled fixed the issue. also, not 100% sure yet, but with milkfish disabled and the following port forwards enabled it also seems to work. replace the sipgate ones with whatever your voip provider requires forwarding, and leave the rest as they're FB specific.


5004 (sipgate)
10000 (sipgate)
5060 - 5062
5070 - 5072
7077 - 7098
30000 - 30005
8000 - 8012 (sipgate)
3478 - 3479