More below.
Paul
[EMAIL PROTECTED] wrote:
Every Event notification package needs to specify the rate of notification. In most packages so far, that rate is limited to 1 NOTIFY every 5 seconds.
Also, all these NOTIFY requests are within the same dialog established by the SUBSCRIBE.
Regards,
Hisham
-----Original Message----- *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of *ext Jerry Ipe Thomas *Sent:* 28.January.2003 05:23 *To:* [EMAIL PROTECTED] *Subject:* [Sip-implementors] About RFC 3265 SUBSCRIBE/NOTIFY!
Hi Guys!
In RFC 3265, it's said that if a proxy forks a SUBSCRIBE
request, then, one 2xx is returned to the subscriber for the
SUBSCRIBE request, but a helluva lot of NOTIFYs can be sent to
the subscriber!
Does this mean this?
| USER_AGENT_SUBSCRIBER | | PROXY_SERVER | SUBSCRIBE-------------------------------> ( Proxy forks this to a lot of notifiers. This sounds like nonsense to me anyway! ) <----------------------------------2xx <---------------------------------NOTIFY <---------------------------------NOTIFY <---------------------------------NOTIFY <---------------------------------NOTIFY . . .
<---------------------------------NOTIFY 200----------------------------------> 200----------------------------------> 200----------------------------------> 200----------------------------------> . . . 200---------------------------------->
Aaaaaaaaaaaaaaah!!! God have mercy on the unfortunate subscriber!
STUPID NOTE: The NOTIFYs are from notifiers.
One possible way to get over this reeeeally scary scenario is
to match the subsequent NOTIFYs using the To tag in the 2xx to
the SUBSCRIBE??? Is this the right thing to do? Man! Forking
sucks! This IS a problem with devices that do not have much in
terms of processing horsepower or memory ( Say 33 MIPS and 64KB
of SRAM. Remember that a lot of "other strange modules", which
are obviously not mine, are running within that 64KB. ) to
maintain separate dialogs with all those stupid notifiers!
I am pissed!
It's obvious by now that I'm confused about forking and RFC
3265. :-(
The forking issues are similar in some respects to what they are with invite. If the proxy forks the SUBSCRIBE and then receives a 2xx it will return that to the subscriber. It will presumably then also attempt to CANCEL all the other forked legs. But there is a race condition, so some of the other forks may have already succeeded and sent 2xx responses back to the proxy. If so, the proxy is not permitted for forward them on the subscriber, so it just discards them.
Each leg of the fork that succeeded establishes a unique dialog, based on to & from tags. (To-tags are unique.) The subscriber learns about these dialogs from the messages it receives. Normally, the 2xx would establish the first dialog. For other legs, the 2xx isn't returned, so the first NOTIFY from the notifier on the leg tells the subscriber that there is another dialog.
If the subscriber only wants to hear from one notifier, it can terminate the extra dialogs by sending a reSUBSCRIBE w/Expires:0.
Yes, its a pain. Everything about forking is a pain.
Paul
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
