No subject
Fri Sep 2 03:59:05 CDT 2011
for each new document sent to a subscriber. Versions are scoped within a su=
bscription."
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=
, and it can probably be done here as well, just not in the way you have do=
ne 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 th=
e code in the case that a subscription times out. If I understand things co=
rrectly, 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 afte=
r a few reboots of those phones, you'd see a LOT more subscriptions tha=
n 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 ph=
ones on every state change.
I honestly have no idea how the code change you've presented causes thi=
ngs 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 th=
e phone. One will be for the old subscription, with a version the phone lik=
es. The other NOTIFY will be for the new subscription, with a version start=
ing 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 subscri=
ption, but not the NOTIFYs for the new subscription. Why? Does the phone st=
ill have knowledge of the old subscription despite the reboot? Does the pho=
ne 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 subscrip=
tion, then why doesn't the phone unsubscribe from the old one? Why is i=
t 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 v=
ersion reported in dialog-info is obtained from the sip_pvt, meaning each s=
ubscription maintains its own independent version counter. We could create =
an option so that for phones like yours, we store the version in the sip_pe=
er instead. This way, if the peer resubscribes, then the version reported i=
n 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 a=
nd have its resources released properly. If implementing this also causes B=
LF to be reported properly to your phones, then I'd be willing to accep=
t 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 :)</pre>
<br />
<p>- Mark</p>
<br />
<p>On March 13th, 2012, 5:35 p.m., Alec Davis wrote:</p>
<table bgcolor=3D"#fefadf" width=3D"100%" cellspacing=3D"0" cellpadding=3D"=
8" style=3D"background-image: url('https://reviewboard.asterisk.org/media/r=
b/images/review_request_box_top_bg.png'); background-position: left top; ba=
ckground-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers.</div>
<div>By Alec Davis.</div>
<p style=3D"color: grey;"><i>Updated March 13, 2012, 5:35 p.m.</i></p>
<h1 style=3D"color: #575012; font-size: 10pt; margin-top: 1.5em;">Descripti=
on </h1>
<table width=3D"100%" bgcolor=3D"#ffffff" cellspacing=3D"0" cellpadding=3D"=
10" style=3D"border: 1px solid #b8b5a0">
<tr>
<td>
<pre style=3D"margin: 0; padding: 0; white-space: pre-wrap; white-space:=
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap=
: break-word;">Some phones (Grandstream GXP20XX series 1.2.5.3 firmware) if=
rebooted, loose the BLF lights due to the new subscription's "ver=
sion" being less than the previous subscription's "version&qu=
ot;.
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 subs=
cription's "version" number to increment past the previous ol=
d "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 of =
each reboot.
1st time wait for the BLF's to fail (then reboot again) - which is th=
e timeout period - a few minutes.
2nd time the lights will work, then fail, then after a few minutes start =
working again.
This fix prevents the old subscription timeout from updating the phones &qu=
ot;version" number. =
This issue doesn't affter the GXP21XX series.
Attempt to show issue byway of example below with some debug output showing=
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:I=
nUse Watchers 1
Debug output:
=3D=3D=3DSet the BLF state to InUse
- Executing [s at macro-custom-agent-inout:13] Set("SIP/GXP0001-00000005&=
quot;, "DEVICE_STATE(Custom:q8601_a8612)=3DINUSE") in new stack
...
[Mar 14 11:01:39] NOTICE[10819]: chan_sip.c:13136 state_notify_build_xml: A=
LEC <dialog id=3D"8601GXP0001" call-id=3D"3c65aed02ae1d5d=
f 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: A=
LEC <dialog id=3D"8601GXP0001" call-id=3D"79956c016812540=
0 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: A=
LEC <dialog id=3D"8601GXP0001" call-id=3D"79956c016812540=
0 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: A=
LEC <dialog id=3D"8601GXP0001" call-id=3D"3c65aed02ae1d5d=
f at 192.168.5.141" direction=3D"recipient"> version=3D6
[Mar 14 11:05:09] NOTICE[10826]: chan_sip.c:3868 __sip_autodestruct: ALEC T=
IMEOUT 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: A=
LEC <dialog id=3D"8601GXP0001" call-id=3D"79956c016812540=
0 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: A=
LEC <dialog id=3D"8601GXP0001" call-id=3D"79956c016812540=
0 at 192.168.5.141"> version=3D6
=3D=3D=3DThe BLF now has correct state of InUse.
</pre>
</td>
</tr>
</table>
<h1 style=3D"color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing <=
/h1>
<table width=3D"100%" bgcolor=3D"#ffffff" cellspacing=3D"0" cellpadding=3D"=
10" style=3D"border: 1px solid #b8b5a0">
<tr>
<td>
<pre style=3D"margin: 0; padding: 0; white-space: pre-wrap; white-space:=
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap=
: break-word;">In place on a 1.8 deployment for months, our production box =
with ~80 GXP phones, half of which are the older GXP20XX series.
</pre>
</td>
</tr>
</table>
<h1 style=3D"color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b>=
</h1>
<ul style=3D"margin-left: 3em; padding-left: 0;">
<li>trunk/channels/chan_sip.c <span style=3D"color: grey">(358608)</span><=
/li>
</ul>
<p><a href=3D"https://reviewboard.asterisk.org/r/1813/diff/" style=3D"margi=
n-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
--===============2624185258260556074==--
More information about the asterisk-dev
mailing list