Hi, I use the same registration server as Yann and I can attest that something funky is going on with either the registration server, the sip phone[1] or the firewall inbetween as my sip phone loses the ability to re-register or something and loses the channel (and misses calls). However I have a second sip phone[2] to a different registration server going through the same firewall and it doesn't seem to have these problems.[1] is a Grandstream GXP 2100, loses channels [2] is an Aastra 6755i, seems to be OK I force my firewall to do nightly 4AM disconnects by cycling the pppoe0 interface per crontab. This process is done because in Germany the Deutsche Telekom used to cycle DSL connections after 24 hours and I'd rather this happens late at night, I don't know if they still do that. So I'M unable to see the pf state as Yann is seeing as I sleep during that time. I have in the past done a syslog capture of my grandstream phone and it's still ongoing, however I lack the expertise to read the next to cryptic syslog in order to tell what really happens with the phone. Yann what brand and model of sip phone are you using?
Hello Peter,Thank you for your reply. The phone is indeed a Grandstream phone (DP-715), and I am also based in Germany. The problem is indeed caused by the daily DSL IP renewal.
I also noticed the problem thanks to the (verbose) syslog of that phone.Clearing the state table on the router will cause an almost immediate reconnection of the phone.
As suggested by Stuart there are other ways I could deal with this issue.The reason I posted this on bugs@ is because OpenBSD keeps UDP connections natted to an IP address that has been changed, which doesn't seem straightforward according to this documentation: http://www.openbsd.org/faq/pf/nat.html which states:
"This tells PF to update the rule if the IP address(es) on the named interface changes"
I would have expected that once the address on my interface changes, new packets coming from my phone would have been natted to the new IP address. But maybe this is expected behaviour - I am fine with the workaround.
Yann
smime.p7s
Description: S/MIME Cryptographic Signature
