On Mon, 2009-11-09 at 12:57 -0500, Carolyn Beeton wrote:
> The IE draft for shared appearances requires that the subscription
> time be shortened while a line is "seized", so that it can be freed
> more quickly if the set which seized it dies. After recent
> restructuring of the SipSubscribeClient, I think that the 408 Request
> timeout now just causes a refresh of the subscription, without the
> application being aware that anything has gone wrong. I think this
> subverts this part of the SAA code, and it is not able to free the
> "seized" line. This is reported in
> http://track.sipfoundry.org/browse/XX-6945.
>
> I think that before the SipRefreshManager retries a failed
> subscription, it should offer it to the application and see it should
> retry… or perhaps this auto-retry should be a parameter of the
> subscription… or can someone suggest a better mechanism?
In most cases the current behavior is a lot easier to use, so I'd favor
an optional parameter to disable it over adding a new interface every
user of the mechanism would have to implement.
Suppose that you get this scenario:
Phone A and B share line 123.
Everything is set up correctly.
Phone A seizes line 123, sets up a call.
Network is partitioned such that
Phone As call is unaffected.
Phone A is not reachable from the SAA server
if I understand the issue correctly, this is where the problem occurs;
the SAA will start getting timeouts trying to contact Phone A to find
out when the line is freed.
Supposing that SAA decides the line should be freed, what happens when
the network heals? If in the mean time the SAA has freed the line, it
disagrees with A about whether or not it A has it seized. Worse - SAA
may have since allowed B to seize the line.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
