Hi,
I have one more problem regarding subscription..
If the sip end point which has subscribed with the server goes down
abnormally (i mean without unsubscribing), subscribe dialog at the server
remains till it comes to know that the dialog at the client side doesn't
exist and keeps sending NOTIFY's on state changes.
client comes up again subscribes with the server, now i am getting notify on
both old and new dialog's but the state informaiton is same in both the
NOTIFY's. ofcourse it is not a problem is the subscription peroid is short,
since server comes to that dialog doesn't exist at the client side in less
time(i mean few NOTIFY's will come), but if the subscription peroid is say 2
hrs(rfc default value), then considerable amount of NOTIFY's can come.
is there any way to avaoid duplicate NOTIFY...?
will session timer on subscribe dialog holds good....?
Regards,
Sumanth
On 9/13/07, Paul Kyzivat <[EMAIL PROTECTED]> wrote:
>
> 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
