Mikko,
Thanks, especially for the bug reference. That is exactly what I was looking for regarding the overlapping NOTIFYs and overlapping SUBSCRIBEs.
I am more concerned about the glare issue, because there really isn't anything that can be done to prevent it from happening. I don't recall there ever having been a discussion of it. To be clear, here is a message flow for the case I am concerned about:
Watcher Notifier
| |
| SUBSCRIBE |
|------------------->|
| 200 OK |
|<-------------------|
| NOTIFY |
|<-------------------|
| 200 OK |
|------------------->|
... ...
| reSUBSCRIBE
|-----\
| \ NOTIFY |
| \ /-------|
| \ / |
| \ |
| / \ |
| / \ |
| / \ |
|<----/ \----->|The question is what should each side do in this situation? It is detectable by each side when it receives the new request from the other side while it has are request outstanding.
This needn't be an especially troubling situation to the notifier. There are no ambiguities for it. So it can just go ahead and process the resubscribe, update state as necessary, and send another NOTIFY, reflecting state following the resubscribe.
But it can be troubling to the watcher. For it, the situation is ambiguous, because from its point of view the same observed results could have occurred from other flows:
| reSUBSCRIBE
|------------------->|
| 200 OK |
| /-------|
| / |
| / |
| NOTIFY |
|<-------------------|
| / |
|<-----/ |or
| reSUBSCRIBE
|------------------->|
| NOTIFY |
|<-------------------|
| 200 OK |
...<------------|(It isn't clear to me from 3265 whether this last one is valid.)
In some cases the ambiguity isn't significant. If full state is being reported in the notifies, and if the resubscribe doesn't change anything about what is returned in notifies, then it doesn't really matter - the notifies can simply be processed by the watcher without regard to the refreshes.
But things are more complex if the resubscribe changes what is reported. A good example, (the one that prompted this query) is with the KPML event package. With that package, the resubscribe can change what key presses the notifier reports on. I think there may be cases where interpretting the result in this case would be very difficult.
It would be cleaner if this were reported as glare via a 491 response. I don't see any other way to resolve the ambiguity cleanly. While 491 could be reported from both sides, it is probably sufficient to define which side does it - watcher or notifier.
Paul
[EMAIL PROTECTED] wrote:
Hi,
This topic has being discussed in relation to partial notification draft. My understanding is that 'normal' notifications (using RFC3856) can overlap. Partial notification ID restricts sending of a new NOTIFY request containing partial presence state when there is a NOTIFY transaction pending.
For more info check: http://bugs.sipit.net/show_bug.cgi?id=686
- Mikko
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Paul Kyzivat
Sent: Tuesday, February 08, 2005 21:37
To: [email protected]
Subject: [Sip-implementors] overlapping NOTIFYs?
I received a question recently about sub/not. I thought I knew the answer, but upon looking I don't find it. Hopefully somebody here knows.
I was thinking there was a restriction to one NOTIFY at a time. But I can't find any mention of that in 3265. Did I just imagine that? (Maybe I got it mixed up with MESSAGE.)
The same question applies to multiple reSUBSCRIBE requests - is there any restriction about overlapping them? Doesn't make a lot of sense, but I can't find any restriction against it.
And was there ever any discussion of glare, when reSUBSCRIBE and NOTIFY occur simultaneously? This starts to get subtle, especially if the reSUBSCRIBE causes a change in what the NOTIFYs deliver.
I gotta believe there has been discussion of this before. But I can't find any record of it. Lack of clarity around this is causing some implementation grief.
Thanks, Paul
_______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
