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
