[asterisk-dev] [Code Review] Adding CLI Function sip remove subscribes and sip remove subscribe <peer>

[Klaus Darilion]

> On 2010-11-29 12:46:15, Russell Bryant wrote:
> > How do you envision this being used?  Is it primarily for development and debugging?  If you think there is a need for this in a production environment, I'd like to see corresponding manager actions, as well, since we don't want to encourage the usage of CLI commands from programs when possible.
> 
> schmidts wrote:
>     as i said above this is a possible problem in an asterisk cluster with a sip proxy in front if the cluster is used in an active:active setup with distributed device states.
>     
>     i will take a look at corresponding manager actions.
> 
> Russell Bryant wrote:
>     Shouldn't you just be ensuring that SUBSCRIBE always hits the same server that it started with?

Russel, consider the following scenario:

                                  /------ Asterisk 1
UAC------- Kamailio/Load-Balancer-------- Asterisk 2
                                  \------ Asterisk 3

Kamailio handles registrations, subscriptions and calls are forwarded to one of Asterisk servers. Out-of-dialog requests will be load-balanced by Kamailio, in-dialog requests (e.g. subscription refresh) will be loose-routed to the proper Asterisk server. Now, if you want to maintain one of the Asterisk servers (e.g. upgrade Asterisk) you will remove this Asterisk server from the cluster, usually by changing the load-balancer algorithm to exclude this single server. New calls will be automatically routed to the other servers, but the subscriptions are still active one the excluded Asterisk server. Therefore it is necessary to force all UACs to create a new subscription and this new subscription will be routed to one of the other servers.

The subscription will be terminated by sending a NOTIFY with Subscription-State terminated. Using "reason=probation" with "Retry-After: 60" should force UACs to resubscribe in 60 seconds. Using "reason=deactivated" could be used to force immediate resubscriptions.

A typical scenario to remove a server form the cluster would be:
- remove the server from the load-balancer destinations
- remove the subscriptions from this server by terminating them
- wait until all active calls are over
- now it is safe to shutdown the server


- Klaus


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1038/#review2978
-----------------------------------------------------------


On 2010-11-29 07:52:57, schmidts wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1038/
> -----------------------------------------------------------
> 
> (Updated 2010-11-29 07:52:57)
> 
> 
> Review request for Asterisk Developers and Klaus Darilion.
> 
> 
> Summary
> -------
> 
> After testing a clustered Asterisk solution we have noticed that there is no other way to remove subscriptions from a server then to let them time out. If you use distributed device states its possible to get notifys from different asterisk servers, cause the subscription was sent to another asterisk in the cluster, before the old subscription timed out.
> 
> With this functions all subscribes or all subscribes from a peer could be removed using a CLI command
> 
> Both functions send a terminating notify out to the watcher.
> 
> I change the expiry value of this subscribe to -1 to mark these subscribes as removed cause they will exists up to T1 X 64 seconds if the watcher is not reachable.
> 
> 
> Diffs
> -----
> 
>   trunk/channels/chan_sip.c 295786 
> 
> Diff: https://reviewboard.asterisk.org/r/1038/diff
> 
> 
> Testing
> -------
> 
> generate several thousand subscribes with sipp and removed them.
> 
> 
> Thanks,
> 
> schmidts
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20101130/8c500271/attachment.htm