|
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
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.
:-(
Regards,
Jerry Ipe Thomas Trainee Engineer(R&D) D-Link
India Ltd. Software and R&D Center #65, 35th Main, 100ft. Ring
Road, 2nd Stage, B.T.M Layout, Bangalore-560068 Tel:
+91-80-26788350/51 Extn: 117
|
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors