Hi,

If Subscriber doesn't receive NOTIFY (Subscription-State: terminated) from
notifier for the following scenario mentioned, then Notifier has died. So
re-Sending UnSubscribe doesn't help as definately it will not be responded
by Notifier.

So Subscriber should wait for Non-invite client transaction duration i.e.
Timer E and terminate the Subscription Dialog.

Regards,
Gadi


On 7/13/06, zhang jw <[EMAIL PROTECTED]> wrote:
>
> HI Sreejesh,
> it is a very interesting  case, i think  if  there if  no NOTIFY received
> with terminated state, the notifier maybe crashed, so the
> subscriber  should
> resend the SUBSCRIBE , if the transaction time out, it should be treated
> as
> 408, this dialog usage should be terminated.
>
> On 7/12/06, Sreejesh <[EMAIL PROTECTED]> wrote:
> >
> > Hi All,
> >
> > As per Rfc 3265,
> >
> -------------------------------------------------------------------------
> > A subscription is destroyed when a notifier sends a NOTIFY request
> > with a "Subscription-State" of "terminated".
> > A subscriber may send a SUBSCRIBE request with an "Expires" header
> > of 0 in order to trigger the sending of such a NOTIFY request;
> > however, for the purposes of subscription and dialog lifetime, the
> > subscription is not considered terminated until the NOTIFY with a
> > "Subscription-State" of "terminated" is sent.
> >
> -------------------------------------------------------------------------
> >
> > Case I:
> > After an Unsubscribe (Expires=0) Request, if the Subscriber does
> > not receive a NOTIFY with a "Subscription-State" of "terminated", when
> > will
> > the subscription be removed. Is there any specific Timeout period, after
> > which
> > the Subscriber himself removes the Subscription..
> >
> > Case II:
> > The same holds good for Subscription Poll Requests, if the NOTIFY were
> > not to
> > be received, when will the Subscription be removed at Subscriber end.
> >
> > Additionally, if the NOTIFY was received with a "Subscription-State" of
> > "active" in
> > either of  the above cases, how should the Subscriber behave??
> >
> > Thankz in advance.....
> > Sreejesh
> > _______________________________________________
> > 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

Reply via email to