No subject

ach new document sent to a subscriber. Versions are scoped within a subscri=
ption."

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 v=
ersion of a previous subscription is just completely wrong.

Now, in Asterisk, we try to work around some vendor's improper behavior, an=
d it can probably be done here as well, just not in the way you have done i=
t. What you have done is to make dialog-info subscriptions never expire. Th=
is means that you are purposely adding a sip_pvt reference leak into the co=
de in the case that a subscription times out. If I understand things correc=
tly, if you perform multiple reboots on your phones, then the number of act=
ive 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. I=
n addition, if you look at the SIP traffic after a few reboots, there are p=
robably 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 crea=
ted 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 thi=
s means is that Asterisk is maintaining two subscriptions for the phone. As=
terisk, on every dialog state change, will be sending two NOTIFYs to the ph=
one. 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 weir=
d. The phone is presumably honoring the NOTIFYs for the old subscription, b=
ut 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, th=
en 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 spe=
cific mechanics behind the brokenness of these phones. Currently, the versi=
on reported in dialog-info is obtained from the sip_pvt, meaning each subsc=
ription maintains its own independent version counter. We could create an o=
ption so that for phones like yours, we store the version in the sip_peer i=
nstead. This way, if the peer resubscribes, then the version reported in th=
e new subscription will continue from the same point it was in the old subs=
cription. This would allow for the old subscription to still time out and h=
ave its resources released properly. If implementing this also causes BLF t=
o 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 samp=
le config file about how such an option should never have to exist in the f=
irst place :)

- Mark


On March 13, 2012, 5:35 p.m., Alec Davis wrote:
> =

> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1813/
> -----------------------------------------------------------
> =

> (Updated March 13, 2012, 5:35 p.m.)
> =

> =

> Review request for Asterisk Developers.
> =

> =

> Summary
> -------
> =

> Some phones (Grandstream GXP20XX series 1.2.5.3 firmware) if rebooted, lo=
ose the BLF lights due to the new subscription's "version" being less than =
the previous subscription's "version".
> This happens the instant that asterisk timeouts the previous subscription=
 - which has the much larger "version" sequence number.
> =

> The only way for the lights to start working again, is for the current su=
bscription's "version" number to increment past the previous old "version" =
number.
> That period of time could be huge, if the phone isn't rebooted for days.
> =

> The workaround has been to reboot the phone twice, within a few minutes o=
f each reboot.
>   1st time wait for the BLF's to fail (then reboot again) - which is the =
timeout period - a few minutes.
>   2nd time the lights will work, then fail, then after a few minutes star=
t working again.
> =

> This fix prevents the old subscription timeout from updating the phones "=
version" number. =

> =

> This issue doesn't affter the GXP21XX series.
> =

> Attempt to show issue byway of example below with some debug output showi=
ng call-id and version number.
> =

> astrid-test*CLI> core show hints
> =

>     -=3D Registered Asterisk Dial Plan Hints =3D-
>             8601GXP0001 at trusted             : Custom:q8601_a8612    State=
:InUse           Watchers  1
> Debug output:
> =

> =3D=3D=3DSet the BLF state to InUse
> - Executing [s at macro-custom-agent-inout:13] Set("SIP/GXP0001-00000005", "=
DEVICE_STATE(Custom:q8601_a8612)=3DINUSE") in new stack
> ...
> [Mar 14 11:01:39] NOTICE[10819]: chan_sip.c:13136 state_notify_build_xml:=
 ALEC <dialog id=3D"8601GXP0001" call-id=3D"3c65aed02ae1d5df at 192.168.5.141"=
> version=3D5
> =

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Reboot the phone, it gets a new BLF subscription.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> [Mar 14 11:02:30] NOTICE[10826]: chan_sip.c:13136 state_notify_build_xml:=
 ALEC <dialog id=3D"8601GXP0001" call-id=3D"79956c0168125400 at 192.168.5.141"=
> version=3D0
> =3D=3D=3DThe BLF has correct state of InUse.
> =

> ...
> [Mar 14 11:05:00] NOTICE[10826]: chan_sip.c:13136 state_notify_build_xml:=
 ALEC <dialog id=3D"8601GXP0001" call-id=3D"79956c0168125400 at 192.168.5.141"=
> version=3D1
> =3D=3D=3DThe BLF still has correct state of InUse.
> =

> ...
> The timeout 'last notification'
> [Mar 14 11:05:09] NOTICE[10826]: chan_sip.c:13131 state_notify_build_xml:=
 ALEC <dialog id=3D"8601GXP0001" call-id=3D"3c65aed02ae1d5df at 192.168.5.141"=
 direction=3D"recipient"> version=3D6
> [Mar 14 11:05:09] NOTICE[10826]: chan_sip.c:3868 __sip_autodestruct: ALEC=
 TIMEOUT of SIP subscription 3c65aed02ae1d5df at 192.168.5.141
> =3D=3D=3DThe BLF has incorrectly gone Idle.
> =

> ...
> [Mar 14 11:15:01] NOTICE[10826]: chan_sip.c:13136 state_notify_build_xml:=
 ALEC <dialog id=3D"8601GXP0001" call-id=3D"79956c0168125400 at 192.168.5.141"=
> version=3D5
> =3D=3D=3DThe BLF is still incorrect at Idle.
> =

>     -- Registered SIP 'GXP0001' at 192.168.5.141:5066
> [Mar 14 11:17:31] NOTICE[10826]: chan_sip.c:13136 state_notify_build_xml:=
 ALEC <dialog id=3D"8601GXP0001" call-id=3D"79956c0168125400 at 192.168.5.141"=
> version=3D6
> =3D=3D=3DThe BLF now has correct state of InUse.
> =

> =

> Diffs
> -----
> =

>   trunk/channels/chan_sip.c 358608 =

> =

> Diff: https://reviewboard.asterisk.org/r/1813/diff
> =

> =

> Testing
> -------
> =

> In place on a 1.8 deployment for months, our production box with ~80 GXP =
phones, half of which are the older GXP20XX series.
> =

> =

> Thanks,
> =

> Alec
> =

>


--===============2624185258260556074==
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable




<html>
 <body>
  <div style=3D"font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor=3D"#f9f3c9" width=3D"100%" cellpadding=3D"8" style=3D"bor=
der: 1px #c9c399 solid;">
    <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href=3D"https://reviewboard.asterisk.org/r/1813/">https://reviewbo=
ard.asterisk.org/r/1813/</a>
     </td>
    </tr>
   </table>
   <br />





 <pre style=3D"white-space: pre-wrap; white-space: -moz-pre-wrap; white-spa=
ce: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">No.