RE: [Sipping] SIP Subscription for SCADA/Stock quotes

["Brian Stucker" <[e-mail]>]

Samir,

See below.

> -----Original Message-----
> From: Srivastava, Samir (SC100:8826) 
> Sent: Monday, November 20, 2006 3:35 AM
> To: Stucker, Brian (RICH1:AR00); 'Benjamin Carlyle'; 
> '[e-mail]'
> Subject: RE: [Sipping] SIP Subscription for SCADA/Stock quotes
> 
> Hi,
> 
>   in line.
> 
> Thx
> Samir
> 
> >
> >> -----Original Message-----
> >> From: Srivastava, Samir (SC100:8826)
> >> Sent: Thursday, November 16, 2006 4:47 PM
> >> To: Benjamin Carlyle; [e-mail]
> >> Subject: RE: [Sipping] SIP Subscription for SCADA/Stock quotes
> >> 
> >> Do we want to cater the different verticals now ? More in-line.
> >> 
> >> Thx
> >> Samir
> >
> >Huh? This is a request to evaluate part of SIP framework to 
> see if it 
> >is fit for handling a large scale, highly distributed event driven 
> >environment. It had better handle it or SIP is in major 
> trouble trying 
> >to handle presence.
> 
> 
> If you remember Hennings frustration from the meeting that 
> one bit of information is going with how many bytes.  SIP 
> presence framework itself is not that good :-) Though I am 
> not focused on optimizing it currently.
> 
> In 2000, there was an attempt on the communication of 
> Intelligent Appliances...
> "SIP Extensions for Communicating with Networked Appliances", H. 
>   Schulzrinne, Simon Tsang, Stanley Moyer, Dave Marples, Arjun 
>   Roychowdhury, 11/16/2000, 
> <draft-tsang-sip-appliances-do-00.txt>         
> 
>     A variety of technologies are available to network appliances and 
>     provide home automation and control.  However, these do 
> not support 
>     wide-area access control and interworking of these Networked 
>     Appliances (NA).  This document describes a new SIP 
> method, DO, that 
>     allows a SIP UA to communicate with NAs. "
> 
> If my recollection of arguments on the list is correct, There 
> were arguments that most of the startups die because of 
> indigestion etc. SIP is not an infant any more. In the 
> startup mode, you focus on the problem at the hand. But you 
> keep architecture open such that it can handle varying needs. 
> It should increase the degree of pervassiveness in the future 
> seamlessly. I think fathers/god father of SIP were not be 
> having such a myopic vision on the utility of SIP for just 
> mimicking PSTN and Presence as you are trying to say. 
> Presence came later and it fit in well. 
> 
> To me, your fear comes from the arguments given by others for 
> weakness of SIP as "SIP Does many things for many people" . I 
> counter it "IP does the same", It depends on how you see and 
> design the versatile / pervassive protocol fulfilling 
> different needs seamlessly with little extensions where 
> processing intelligence of those extensions is just at the 
> required end point. Rest nodes are just conduit. To me, 
> Presence in its current form is just one aspect. SIP in the 
> core is excellent protocol but with some rough edges coming 
> from mimicking PSTN, etc...
> 

I think Adam already responded to this, and I happen to agree with his
response.

> 
> >
> >The point of that statement in 3265 and elsewhere is not to 
> >limit the URL schemes that can be used, but to point out that 
> >there are many ways of pushing data around a network. The 
> >intent of the framework wasn't to solve 
> >world-event-subscription-hunger. There was a lot of discussion 
> >at the time around using (PUBLISH in particular) for all sorts 
> >of things and we wanted to constrain the problem space so we 
> >could finish off the RFC sometime in our lifetime.
> 
> I am not asking world-event-hunger to be fullfilled with this 
> like X-Motif/JDK event models etc. I am asking only the 
> presence framework to extend....
> 

Presence framework to extend what?

[SNIP]

> 
> 
> As per Section 11 of 3261 
>    "An OPTIONS request MAY be sent as part of an established dialog to
>    query the peer on capabilities that may be utilized later in the
>    dialog."
> 
> OPTIONS does allow the Allow-Event header etc. There may be 
> sometime need for a SIP entity to find the state of subscirbe 
> created dialog on another end, there it will be useful. (Like 
> missing NOTIFY with state change delta) State indication can 
> be event package specific. 200 OK with subscription event 
> state tells the querying endpoint what is happening. If event 
> state is currently not supported, then protocol might need to 
> extend. Other response codes can be viewed differently.. I 
> was coining it as he was asking for server driven. I don't 
> understand completely his problem requirements as of now.

OPTIONS is not intended to carry information that can change over time.
SUBSCRIBE/NOTIFY does this. The protocol has already been extended, and
it does not use OPTIONS. See RFC-3857.

> 
> >
> >IMHO- The best way to solve the dead server problem is to have 
> >neither end generating keep-alive traffic (which, in an ideal 
> >environment in which no node fails, is always useless). Solve 
> >the problem at the server by utilizing a high-availability 
> >scheme there so that a server failure does not interrupt service.
> >
> 
> Refer my long time back proposal on the list for the Event 
> based heart beat 
> 
> http://www1.ietf.org/mail-archive/web/sip/current/msg08844.htm
l This was to avoid the  periodic OPTIONS messages flow when > other
server was down to avoid congestion etc.. I was just 
> scratching the congestion at that time...
> 
> Somewhere at the IP layer when packet is sent, it needs to 
> know which IP server should fill. VRRP just talks about the 
> IP layer connectivity. Can you describe your scheme...
>  
> 

My point here is that within this application, heartbeating between
clients and servers to solve an issue of server availability is a bad
model. Use a high-availability scheme between the servers so that they
can take over for one another. Nothing special happens at the clients. 


[SNIP]

> 
> There were some postings on the HTTP Digest being prone to 
> brute force attacks.
> BTW, I worked earlier in different event based/driven systems 
> too. When I have more free time, I will start looking into this.
> 

Please do.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP