I&#39;ve never worked with Aastras, so don&#39;t have any additional data over what&#39;s been said by others. Also, I&#39;ve never sent the SIP &quot;check-sync&quot; notify to a phone that wasn&#39;t already registered with the asterisk server the SIP notify was sent from. My best *guess* would be that actual behavior of the phones in that case might vary (based on manufacturer and/or firmware version). Some might ignore the notify, others *may* accept it *if* the asterisk server was their provisioning server previously, some might even blindly accept it.<br>
<br>The actual payload/content of the Notify is configured in the sip_notify.conf file. My version (running 1.8.1.1) does not have anything specific to Aastra in it, so I would try all the other ones to see if one of them works. If none work, I&#39;d go search for some Aastra administrator documentation (or provisioning guide, or some such). As you can see from the file, the payload itself is not complex at all. For Polycoms as an example, the &quot;Event&quot; field in the SIP NOTIFY header is set to &quot;check-sync&quot;. That&#39;s all there is to it.<br>
<br>The SIP Notify we&#39;re talking about here is a simple SIP event being sent to the phone by asterisk. Best to use a packet sniffer, or you could turn on SIP debug in asterisk for a single peer and send it the &quot;notify&quot;. The behavior I see with my Polycoms makes it appear as if there is no &quot;handshake&quot; between asterisk and the phone at all for these. The phone reboots as soon as I send the notify. Even more, asterisk does a few retransmissions of the notify packet, so it might&#39;ve expected a SIP response from the phone (which the phone did not send).<br>
<br>Lastly, to state &quot;the obvious&quot;, the SIP Notify itself does not convey any configuration data to the phone at all. It only tells the phone to &quot;go check your config&quot;. So to help with your provisioning scenario, you&#39;d have to update/modify the original config data/files for the phone on the provisioning server, then trigger the phone to reboot (or reload). From all I&#39;ve seen with Polycoms and Ciscos, you&#39;ll set up a phone&#39;s provisioning server through your DHCP server (or manually on the phone). The SIP Notify will cause the phone to go back to that provisioning server and re-load the latest config data.<br>