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>
</blockquote>
<p>On March 23rd, 2012, 6:23 a.m., <b>Alec Davis</b> wrote:</p>
<blockquote style=3D"margin-left: 1em; border-left: 2px solid #d0d0d0; pad=
ding-left: 10px;">
<pre style=3D"white-space: pre-wrap; white-space: -moz-pre-wrap; white-sp=
ace: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Working w=
ith the senario that a phone has restarted due to loss of power for some re=
ason.
Trusting a phone to unsubscribe to a previous subscription is just wrong, i=
t 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: A=
LEC <dialog id=3D"8601GXP0001" call-id=3D"e607e6a8e79400d=
d at 192.168.5.141"> version=3D0 terminated
astrid-test*CLI> sip show subscriptions
Peer User Call ID Extension Last st=
ate 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 -- <non=
e> mwi 8612 000300
3 active SIP subscriptions
[Mar 23 23:56:45] NOTICE[23637]: chan_sip.c:13138 state_notify_build_xml: A=
LEC <dialog id=3D"8601GXP0001" call-id=3D"e607e6a8e79400d=
d at 192.168.5.141"> version=3D1 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: A=
LEC <dialog id=3D"8601GXP0001" call-id=3D"5a1f3df6ce2e4fc=
f at 192.168.5.141" direction=3D"recipient"> version=3D2 ter=
minated
[Mar 23 23:58:25] NOTICE[23637]: chan_sip.c:3868 __sip_autodestruct: ALEC T=
IMEOUT of SIP subscription 5a1f3df6ce2e4fcf at 192.168.5.141
astrid-test*CLI> sip show subscriptions
Peer User Call ID Extension Last st=
ate Type Mailbox Expiry
192.168.5.141 GXP0001 e607e6a8e79400d 8601GXP0001 at tru Idle =
dialog-info+xml <none> 000300
192.168.5.141 GXP0001 052f0371d160f58 -- <non=
e> mwi 8612 000300
2 active SIP subscriptions
More information about the asterisk-dev
mailing list