This is a battle between the needs/desires of the subscriber and the
needs/desires of the notifier.
- a large value minimizes the traffic
- a small value decreases the lag before a failure of the peer is
recognized
Each device must decide what is an appropriate tradeoff between those
conflicting goals to come up with its desired number. But then the
subscriber and the notifier must agree on a value. If their desired
values differ then one or both must compromise. The notifier has the
stronger vote here because it is the one offering the service.
The negotiation is handled by having the subscriber propose a value. The
notifier is allowed to reduce it, but not to increase it. Or the
notifier can refuse the request with a status indicating that the
proposed value is too small.
Sumanth wants the subscriber's will for a larger value to take
precedence over the notifier's desire for a smaller value. There is very
little that the subscriber can do in this case. I guess its choices are:
- go along with the notifier and refresh at the more frequent rate that
the notifier requires
- allow the subscription to expire without a refresh. Then possibly
send a new subscription later when it is ready to do so.
- when a refresh is sent, a larger value may be proposed again.
You might get lucky and have the notifier accept it. But most likely
if it was reduced the first time it will be reduced in the refresh
as well.
Paul
Curt Taylor wrote:
>
> Sumanth,
>
> RFC 3265 describes the behavior for the subscribe/notify.
>
> 1) The client can send another subscribe to refresh the subscription on
> the same dialog, but the maximum expires time is still limited by the
> server.
> 2) Technically yes, but only up to the maximum provided by the server.
>
> Curt
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> sumanth achar
> Sent: Thursday, September 13, 2007 4:00 AM
> To: [email protected]
> Subject: [Sip-implementors] SUBSCRIBE Expiry Timer
>
>
> Hi,
> I have few questions on SUBSCRIBE Expiry Timer.
>
> 1. If the server sends too less expiry timer in the 200ok of SUBSCRIBE,
> how client can re-negotiate timer value...?
> 2. can RE-SUBSCRIBE increase the expiration timer value...?
>
> -Sumanth
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
