sumanth achar wrote:
> 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.
The first time it tries to send a NOTIFY after the subscriber goes down,
it should get an error on the NOTIFY. There are lots of different errors
it might get, but the end result should be that it concludes that the
dialog is gone and tears down its end.
For instance it might get a timeout. Of, if the subscriber finishes
rebooting before the next notify is sent, then presumably it won't know
about the dialog and will send a 481 response.
> 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.
The worst case should be that you see one notify on the old dialog and
send a 481. After that you should not be bothered by it.
Paul
> 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....?
There is no need for session timer on a subscription, because the expiry
timer on the subscription serves exactly the same purpose.
Paul
> Regards,
> Sumanth
>
>
>
>
>
>
> On 9/13/07, *Paul Kyzivat* <[EMAIL PROTECTED]
> <mailto:[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]>
> > [mailto:[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>] On Behalf Of
> > sumanth achar
> > Sent: Thursday, September 13, 2007 4:00 AM
> > To: [email protected]
> <mailto:[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]
> <mailto:[email protected]>
> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > [email protected]
> <mailto:[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
