Asterisk sends “Expires: 0” when registering SIP trunk

My System:
CentOS 6.2 (2.6.32-220.13.1.el6.x86_64)
FOP2 2.26

I recently upgraded Asterisk from to on my system. Mostly things seem fine after the upgrade, although I have noticed one “niggle”; on the homepage of my SIP trunk provider ( my system now permanently shows as ‘offline’ even though it is otherwise registered fine. Calls however appear to be fine and there are no audio issues or dropouts.

I’ve been in touch with the tech’s from SIpgate and have shared SIP-debug logs with them. They think it has something to do with the fact that Asterisk is sending “Expires: 0” as part of the registration. See debug snippet at end of post.

As far as I’m aware nothing changed in FBPX between Asterisk upgrades, and the SIP registration settings are set as:

Registrations: 20 (registertimeout) 0 (registerattempts)
Registration Times: 60 (minexpiry) 3600 (maxexpiry) 120 (defaultexpiry)

I changed the defaultexpiry to 600 today (as the sipgate guys reckon that is what they need), and did an an [strong]amportal restart[/strong] but that has not helped. The SIP-debug output still shows “Expires: 0” in the registration attempts Asterisk is sending to sipgate. Weird!!!

So my question is why is Asterisk sending a “0” when it should be sending 120 (or 600 as it is now)? Has anyone seen this sort of behaviour before or know how to correct it?

I found an interesting thread on the Digium forum that suggests there is an “~expiry” option that can be appended to register statements, but if it was working before without this then can’t see why I should have to add it in now…


[2012-04-30 13:45:40] NOTICE[4395]: chan_sip.c:13337 sip_reregister:    -- Re-registration for 
[email protected]
REGISTER 11 headers, 0 lines
Reliably Transmitting (NAT) to
Via: SIP/2.0/UDP;branch=z9hG4bK68de2f0e;rport
Max-Forwards: 70
From: <sip:[email protected]>;tag=as7107c528
To: <sip:[email protected]>
Call-ID: [email protected]
User-Agent: FPBX-2.10.0(
Authorization: Digest username="4110950", realm="", algorithm=MD5,
uri="", nonce="4f9e8a91de2b3b86bdfb1db43fdc92f718f79e90",
Expires: 0
Contact: <sip:[email protected]:5060>
Content-Length: 0


<--- SIP read from UDP: --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP;received=;branch=z9hG4bK68de2f0e;rport=47377
From: <sip:[email protected]>;tag=as7107c528
To: <sip:[email protected]>;tag=12353b526ced3f57e916dd04ee4917bc.fdfc
Call-ID: [email protected]
Content-Length: 0

--- (7 headers 0 lines) ---
Scheduling destruction of SIP dialog '[email protected]' in 32000 ms
(Method: REGISTER)
[2012-04-30 13:45:40] NOTICE[4395]: chan_sip.c:21116 handle_response_register: Outbound
Registration: Expiry for is 120 sec (Scheduling reregistration in 105 s)

Turns out there was a bug with a Presence subscription patch I had applied to Asterisk. New patch has resolved the issue.