Re: [asterisk-dev] Subscription Persistence Issues

[George Joseph]

On Wed, Feb 8, 2017 at 6:56 AM, Joshua Colp  wrote:

> On Tue, Feb 7, 2017, at 03:16 PM, George Joseph wrote:
> > Greetings All,
> >
> > I've been working on the (many) issues with recreating inbound
> > subscriptions after an asterisk restart.  I have an approach that works
> > but
> > has a drawback:  We can recreate the subscription on startup from the
> > data
> > we persist and can even send a NOTIFY to each subscriber BUT with the
> > current version of pjproject, we can't actually set the expiration timer.
> > I have a pjproject patch ready that allows us to set tie timer but the
> > drawback is that this approach will only work with bundled pjproject or a
> > patched version of your own.
> >
> > There's an alternative though...   When asterisk restarts, instead of
> > sending 'active' NOTIFYs to each subscriber, we could send
> > 'terminate,probation' instead.  The RFCs say that a "client SHOULD retry
> > at
> > some later time".  While this approach will work with any version of
> > pjproject there are issues here as well.  The first issue is the word
> > 'SHOULD'.  There's no guarantee that the client will actually
> > resubscribe.
> > The second issue is the extra SUBSCRIBE/OK/NOTIFY/OK exchange between
> > asterisk and the client at startup.  We can tell the client to retry not
> > before a random interval similar to how we stagger sending OPTIONS
> > messages
> > at startup but it's still an extra 4 packets per subscription.
>
> I don't trust clients enough to expect that this behavior will work for
> everything. If we can do the work ourselves in a way that guarantees it
> works for all clients I usually opt for doing that.
>

Yeah after further investigation, "some manufacturer"''s phones don't
resubscribe on a deactivated or probation reason.  Also discovered another
bug in pjproject that prevents the use of the 'retry-after' parameter with
probation.

I think the approach will have to be that if we detect that patched
pjproject is in use, we use the pjproject timer and if not, we start our
own timer.



>
> --
> Joshua Colp
> Digium, Inc. | Senior Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Check us out at: www.digium.com & www.asterisk.org
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
George Joseph
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Subscription Persistence Issues

[George Joseph]

On Wed, Feb 8, 2017 at 6:52 AM, Matthew Jordan  wrote:

>
>
> On Tue, Feb 7, 2017 at 1:16 PM, George Joseph  wrote:
>
>> Greetings All,
>>
>> I've been working on the (many) issues with recreating inbound
>> subscriptions after an asterisk restart.  I have an approach that works but
>> has a drawback:  We can recreate the subscription on startup from the data
>> we persist and can even send a NOTIFY to each subscriber BUT with the
>> current version of pjproject, we can't actually set the expiration timer.
>> I have a pjproject patch ready that allows us to set tie timer but the
>> drawback is that this approach will only work with bundled pjproject or a
>> patched version of your own.
>>
>> There's an alternative though...   When asterisk restarts, instead of
>> sending 'active' NOTIFYs to each subscriber, we could send
>> 'terminate,probation' instead.  The RFCs say that a "client SHOULD retry at
>> some later time".  While this approach will work with any version of
>> pjproject there are issues here as well.  The first issue is the word
>> 'SHOULD'.  There's no guarantee that the client will actually resubscribe.
>> The second issue is the extra SUBSCRIBE/OK/NOTIFY/OK exchange between
>> asterisk and the client at startup.  We can tell the client to retry not
>> before a random interval similar to how we stagger sending OPTIONS messages
>> at startup but it's still an extra 4 packets per subscription.
>>
>> Neither approach is harder or easier than the other to implement.  It's
>> just a matter of backwards compatibility vs extra traffic and the 'SHOULD'
>> uncertainty.
>>
>> Thoughts?
>>
>>
> If you go with the first approach, do the changes to pjproject to fix the
> expiration timer issues cause any API changes? Or is it merely fixing a bug
> in pjproject?
>

pjproject already has an internal API to set the timer on a subscription so
the patch is creating a public wrapper for it.


>
> --
> Matthew Jordan
> Digium, Inc. | CTO
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
George Joseph
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Subscription Persistence Issues

[Joshua Colp]

On Tue, Feb 7, 2017, at 03:16 PM, George Joseph wrote:
> Greetings All,
> 
> I've been working on the (many) issues with recreating inbound
> subscriptions after an asterisk restart.  I have an approach that works
> but
> has a drawback:  We can recreate the subscription on startup from the
> data
> we persist and can even send a NOTIFY to each subscriber BUT with the
> current version of pjproject, we can't actually set the expiration timer.
> I have a pjproject patch ready that allows us to set tie timer but the
> drawback is that this approach will only work with bundled pjproject or a
> patched version of your own.
> 
> There's an alternative though...   When asterisk restarts, instead of
> sending 'active' NOTIFYs to each subscriber, we could send
> 'terminate,probation' instead.  The RFCs say that a "client SHOULD retry
> at
> some later time".  While this approach will work with any version of
> pjproject there are issues here as well.  The first issue is the word
> 'SHOULD'.  There's no guarantee that the client will actually
> resubscribe.
> The second issue is the extra SUBSCRIBE/OK/NOTIFY/OK exchange between
> asterisk and the client at startup.  We can tell the client to retry not
> before a random interval similar to how we stagger sending OPTIONS
> messages
> at startup but it's still an extra 4 packets per subscription.

I don't trust clients enough to expect that this behavior will work for
everything. If we can do the work ourselves in a way that guarantees it
works for all clients I usually opt for doing that.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Subscription Persistence Issues

[Matthew Jordan]

On Tue, Feb 7, 2017 at 1:16 PM, George Joseph  wrote:

> Greetings All,
>
> I've been working on the (many) issues with recreating inbound
> subscriptions after an asterisk restart.  I have an approach that works but
> has a drawback:  We can recreate the subscription on startup from the data
> we persist and can even send a NOTIFY to each subscriber BUT with the
> current version of pjproject, we can't actually set the expiration timer.
> I have a pjproject patch ready that allows us to set tie timer but the
> drawback is that this approach will only work with bundled pjproject or a
> patched version of your own.
>
> There's an alternative though...   When asterisk restarts, instead of
> sending 'active' NOTIFYs to each subscriber, we could send
> 'terminate,probation' instead.  The RFCs say that a "client SHOULD retry at
> some later time".  While this approach will work with any version of
> pjproject there are issues here as well.  The first issue is the word
> 'SHOULD'.  There's no guarantee that the client will actually resubscribe.
> The second issue is the extra SUBSCRIBE/OK/NOTIFY/OK exchange between
> asterisk and the client at startup.  We can tell the client to retry not
> before a random interval similar to how we stagger sending OPTIONS messages
> at startup but it's still an extra 4 packets per subscription.
>
> Neither approach is harder or easier than the other to implement.  It's
> just a matter of backwards compatibility vs extra traffic and the 'SHOULD'
> uncertainty.
>
> Thoughts?
>
>
If you go with the first approach, do the changes to pjproject to fix the
expiration timer issues cause any API changes? Or is it merely fixing a bug
in pjproject?

-- 
Matthew Jordan
Digium, Inc. | CTO
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Subscription Persistence Issues

[George Joseph]

Greetings All,

I've been working on the (many) issues with recreating inbound
subscriptions after an asterisk restart.  I have an approach that works but
has a drawback:  We can recreate the subscription on startup from the data
we persist and can even send a NOTIFY to each subscriber BUT with the
current version of pjproject, we can't actually set the expiration timer.
I have a pjproject patch ready that allows us to set tie timer but the
drawback is that this approach will only work with bundled pjproject or a
patched version of your own.

There's an alternative though...   When asterisk restarts, instead of
sending 'active' NOTIFYs to each subscriber, we could send
'terminate,probation' instead.  The RFCs say that a "client SHOULD retry at
some later time".  While this approach will work with any version of
pjproject there are issues here as well.  The first issue is the word
'SHOULD'.  There's no guarantee that the client will actually resubscribe.
The second issue is the extra SUBSCRIBE/OK/NOTIFY/OK exchange between
asterisk and the client at startup.  We can tell the client to retry not
before a random interval similar to how we stagger sending OPTIONS messages
at startup but it's still an extra 4 packets per subscription.

Neither approach is harder or easier than the other to implement.  It's
just a matter of backwards compatibility vs extra traffic and the 'SHOULD'
uncertainty.

Thoughts?


-- 
George Joseph
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev