SIP hangs after a while

Boardercrime

I seems the timeout settings is not the problem.
Any ideas ?

Helix26404

In Asterisk, try setting qualify=yes for the extension that is affected. This will force Asterisk to send "keep alive" packets to the device.

Boardercrime

I've got this setting already.

SpLord

any solution yet, same problem here.

After resetting the State table everything is working for round a day, then you has to reset the states

Carsten

hoba

You probably need some kind of keepalive setting for your SIP-client. I have seen devices that have a setting for this (like the AVM Fritzbox for example). Check the manuals of your device to see if it supports such a setting.

SpLord

@hoba:

You probably need some kind of keepalive setting for your SIP-client. I have seen devices that have a setting for this (like the AVM Fritzbox for example). Check the manuals of your device to see if it supports such a setting.

keepalive is active, i'm using an asterisk server which connects too some sip providers.

Slam

More settings for you guys to play with if you have a Sipura/Linksys ATA

(under NAT Support Parameters):
STUN Enable=yes, STUN Test Enable=yes, Substitute VIA Addr=yes, Send Resp To Src Port=yes, NAT Keep Alive Intvl=15, other VIA parameters=no

(under Line 1):
NAT Mapping Enable=yes, NAT Keep Alive Enable=yes

Regards

hoba

Try this solution: http://forum.pfsense.org/index.php/topic,4364.msg26872.html#msg26872

SpLord

Nope doesn't work.

Is there a possibility to trigger a state table reset when a re-dial(PPPoe) occurs?

maldex

Try to decrease the register times to 60seconds. PFsense, along with some expesive-firewalls, have UDP timeouts of 30/60 seconds… after 60 seconds the incomming INVITE will be dropped.

Using STUN doesnt solve the problem. stun is only used to let the phone know the public(masqueraded) address, and how it can open up UDP sessions.

the public IP is needed because SIP (which is osi-layer7) does also contain the IP adress, and some SIP-devices will answer only on that and not on the layer3 ip...(workaround in asterisk is NAT=Yes)

another good idea is to create a NAT rule which does static-port-mapping on the SIP & RTP sessions so that port 5060 stay's always 5060.....

things i haven't checked yet for myself:

SIP over TCP. TCP-sessions have much longer timeouts...but is rarely supported
Conservative mode.

good luck