It should establish two dialogues. Tolga
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > [EMAIL PROTECTED] > Sent: Wednesday, January 28, 2004 10:21 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [Sip-implementors] About RFC 3265 SUBSCRIBE/NOTIFY! > > > What happens in the situation I describe below? > > UAC Proxy UAS1 UAS2 > ---- ----- ---- ---- > > SUBSCRIBE > ------------> SUBSCRIBE > -------------> > SUBSCRIBE > ----------------------------> > 200 To-tag:aaa > 200 To-tag:aaa <------------ > <------------- > > NOTIFY To-tag:bbb > <------------------------------------------ > > The NOTIFY arrives before the 200 from UAS2 > > Does that establish 2 dialogs? I think most implementations will > reject that NOTIFY with 481. > > /Hisham > > > -----Original Message----- > > From: ext Paul Kyzivat [mailto:[EMAIL PROTECTED] > > Sent: 28.January.2004 16:23 > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: Re: [Sip-implementors] About RFC 3265 SUBSCRIBE/NOTIFY! > > > > > > I don't think the rate limiting helps with the problem that > > the original > > poster was concerned with. He seems to be concerned that the > > SUBSCRIBE > > might fork, and that NOTIFYs will come back from many > > different forks. > > If that happens, each will be independently rate limited, but the > > aggregate rate seen by the subscriber depends on the number of forks. > > > > 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 _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
