RFC 3365, section 4.4.9 covers this case. A 481 is returned if the event package doesn't permit installation of multiple subscriptions. But if the event package does, then a new dialog is established.
Paul
[EMAIL PROTECTED] wrote:
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
