Subject: [Sipping] notify timeout behavior

From: "Petri K. Koskelainen" <[email-masked]>
Date: Sun, 6 Oct 2002 15:16:35 -0400 (EDT)

yeah, this is a known bug in wireless case and 
should be fixed somehow..

Especially if you have a lot of on-going subscriptions
you may have to re-subscribe all of them.
does not make much sense.
Some mechanism to quickly restore all (lost) subscriptions would be nice.
You may also loose or change your terminal, and then again you have 
to restore all subscriptions.

Petri

> i have been playing with presence on a gprs terminal.  due to the nature
> of gprs network, quite a few packets get lost.  this means that also
> notifys or oks to them may easily get lost.  according to RFC 3265:
>
>   If the NOTIFY request fails (as defined above) due to a timeout
>   condition, and the subscription was installed using a soft-state
>   mechanism (such as SUBSCRIBE), the notifier SHOULD remove the
>   subscription.

> this doesn't make much sense to me, since removing the subscription and
> then trying to reestablish it will create even more network traffic than
> just re-sending of the notify request

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked]
Date: Tue, 8 Oct 2002 10:46:58 +0300

Hi Adam,

> >notifys or oks to them may easily get lost.
> >
> You're saying that you are losing 11 UDP packets in a row over a 
> 30-second interval, but still somehow consider yourself 
> connected to the 
> network?
> 
> That seems implausible. At very least, it stretches the definition of 
> the word "connected" beyond any scope that I have previously 
> been aware of.

I think that Juha was meaning something along these lines:

With wireless networks, the wireless link can be flaky.  You step in
an elevator and loose coverage until you leave the elevator.  You
go through a tunnel; you walk around a tall building and loose coverage.
The user will think that he should still be connected in such 
events.

The question is: can we define the services to be resilient in
these circumstances?  

John