[asterisk-dev] [Code Review]: DIALOG_INFO_XML timeout notification stops BLF's from working.

[Alec Davis]

> On March 22, 2012, 6:14 p.m., Mark Michelson wrote:
> > No.
> > 
> > From RFC 4235 Section 4.1: "Versions start at 0, and increment by one for each new document sent to a subscriber. Versions are scoped within a subscription."
> > 
> > When the phone reSUBSCRIBEs with a new call-id, that is a new subscription, and so the version starts back at 0 again. The fact that the phone you are using is trying to compare the version of a new subscription against the version of a previous subscription is just completely wrong.
> > 
> > Now, in Asterisk, we try to work around some vendor's improper behavior, and it can probably be done here as well, just not in the way you have done it. What you have done is to make dialog-info subscriptions never expire. This means that you are purposely adding a sip_pvt reference leak into the code in the case that a subscription times out. If I understand things correctly, if you perform multiple reboots on your phones, then the number of active subscriptions in Asterisk will stack more and more. I'm willing to bet that if you run 'sip show subscriptions' in your setup after a few reboots of those phones, you'd see a LOT more subscriptions than there should be. In addition, if you look at the SIP traffic after a few reboots, there are probably way more NOTIFYs than necessary going to the phones on every state change.
> > 
> > I honestly have no idea how the code change you've presented causes things to work. When your phone reboots, I can see that a new subscription is created based on the fact that the XML has a new call-id. With your change, the old subscription that normally would have timed out does not now. What this means is that Asterisk is maintaining two subscriptions for the phone. Asterisk, on every dialog state change, will be sending two NOTIFYs to the phone. One will be for the old subscription, with a version the phone likes. The other NOTIFY will be for the new subscription, with a version starting at 0 and incrementing on each new NOTIFY. Now, here's where things get weird. The phone is presumably honoring the NOTIFYs for the old subscription, but not the NOTIFYs for the new subscription. Why? Does the phone still have knowledge of the old subscription despite the reboot? Does the phone just accept any unsolicited dialog-info NOTIFY? If the phone knows about the old subscription, and it also knows that it has created a new subscription, then why doesn't the phone unsubscribe from the old one? Why is it trying to apply a per-dialog version to multiple dialogs? Seriously, WTF?
> > 
> > I have a possible solution for this that is safer, but I don't know the specific mechanics behind the brokenness of these phones. Currently, the version reported in dialog-info is obtained from the sip_pvt, meaning each subscription maintains its own independent version counter. We could create an option so that for phones like yours, we store the version in the sip_peer instead. This way, if the peer resubscribes, then the version reported in the new subscription will continue from the same point it was in the old subscription. This would allow for the old subscription to still time out and have its resources released properly. If implementing this also causes BLF to be reported properly to your phones, then I'd be willing to accept such a change into Asterisk. Just expect some strongly worded vitriol in the sample config file about how such an option should never have to exist in the first place :)

Working with the senario that a phone has restarted due to loss of power for some reason.
Trusting a phone to unsubscribe to a previous subscription is just wrong, it won't know what it's previous call-id was.

The cleaner removed the power. Then plugged it back in... so many senarios :)
So the phone has just finished booting. 

   -- Registered SIP 'GXP0001' at 192.168.5.141:5066
[Mar 23 23:54:15] NOTICE[23637]: chan_sip.c:13138 state_notify_build_xml: ALEC <dialog id="8601GXP0001" call-id="e607e6a8e79400dd at 192.168.5.141"> version=0 terminated
astrid-test*CLI> sip show subscriptions
Peer             User             Call ID          Extension        Last state     Type            Mailbox    Expiry
192.168.5.141    GXP0001          e607e6a8e79400d  8601GXP0001 at tru  Idle           dialog-info+xml <none>     000300
192.168.5.141    GXP0001          5a1f3df6ce2e4fc  8601GXP0001 at tru  Idle           dialog-info+xml <none>     000300
192.168.5.141    GXP0001          052f0371d160f58  --               <none>         mwi             8612       000300
3 active SIP subscriptions

[Mar 23 23:56:45] NOTICE[23637]: chan_sip.c:13138 state_notify_build_xml: ALEC <dialog id="8601GXP0001" call-id="e607e6a8e79400dd at 192.168.5.141"> version=1 terminated
    -- Registered SIP 'GXP0001' at 192.168.5.141:5064
[Mar 23 23:58:25] NOTICE[23637]: chan_sip.c:13133 state_notify_build_xml: ALEC <dialog id="8601GXP0001" call-id="5a1f3df6ce2e4fcf at 192.168.5.141" direction="recipient"> version=2 terminated
[Mar 23 23:58:25] NOTICE[23637]: chan_sip.c:3868 __sip_autodestruct: ALEC TIMEOUT of SIP subscription 5a1f3df6ce2e4fcf at 192.168.5.141

astrid-test*CLI> sip show subscriptions
Peer             User             Call ID          Extension        Last state     Type            Mailbox    Expiry
192.168.5.141    GXP0001          e607e6a8e79400d  8601GXP0001 at tru  Idle           dialog-info+xml <none>     000300
192.168.5.141    GXP0001          052f0371d160f58  --               <none>         mwi             8612       000300
2 active SIP subscriptions