I think we are digressing from the primary discussion. Again going back to basics, I have the following primitives already present and supported by SIP/SIPPING in various RFC's:
1. I have a mechanism that is outlined in 3265 to send/receive NOTIFY's. 2. I have a mechanism that is outlined in 3265 to accept NOTIFY's. 3. I have a mechanism that is outlined in 3265 that allows one to reject a NOTIFY *without* terminating a subscription. 4. I have a mechanism that is outlined in dialog state that allows UA's to advertise various call states. What exactly is the proposal violating? I don't disagree to your argument of the proposal being non-intuitive but I dis-agree to the argument of it violating the spec and requiring SIPPING enhancements. And to address your question of retrying exact same request, it could be that the line being requested is free by the time the request is retried and could be successful. Venkatesh On Wed, Mar 26, 2008 at 9:20 AM, Rohan Mahy <[EMAIL PROTECTED]> wrote: > > On Mar 26, 2008, at 9:01 AM, Venkatesh wrote: > > Paul: > > > > Replies Inline..... > > > > On Wed, Mar 26, 2008 at 6:07 AM, Paul Kyzivat <[EMAIL PROTECTED]> > > wrote: > > I have only been loosely following this, but the following caught > > my eye: > > > > Venkatesh wrote: > > > > > [Venkatesh]: I am not sure the draft is "defining" a completely new > > > role. The function being performed is that of event aggregation. > > Like I > > > pointed out, it is not doing anything that violates the RFC. I am > > not > > > sure 3265 (or dialog state draft for that matter) specifically > > calls out > > > against rejecting a request by a State Agent. The way I see it > > the State > > > Agent in the proposal is doing the following: > > > > > > 1. Accept incoming NOTIFY's per dialog state RFC. > > > 2. Respond with a non 2xx response to a NOTIFY should it be > > required to > > > do glare resolution. > > > > I don't understand how there can be anything comparable to glare in an > > event package. If you think there is, that seems like a red flag to me > > that something is amiss. > > > > A NOTIFY is sent by a server possessing state, reporting on that > > state. > > The subscriber has no business arguing about it. Its like me > > telling you > > I'm thirsty, and you responding to me that I am incorrect - that I may > > not be thirsty now. > > > > I gather you have a state agent that is subscribing to events from > > several sources (phones) and aggregating the results. But if you > > want to > > model it that way, then the states of the phones are what they are, > > and > > it is up to the aggregator to make a sensible composite state out > > of the > > result. It has no business telling its notifiers they are wrong. > > > > [Venkatesh]: Paul your argument is fine; although in your example, > > I am not saying, you are incorrect, but I am saying; "I understand > > you are thirsty, but please wait for 10 seconds and ask me again"..... > > Ask me again to tell you that I was thirsty 10 seconds ago? Why does > this help anything? > > thanks, > -rohan > > > The "Retry-After" header in the response provides this > > capability....The argument I was trying to make was that any SIP > > request can be rejected/challenged by the recipient. The same > > applies to a state agent as well. I am not sure a state-agent is > > required to respond with a 200 OK should it receive a NOTIFY that > > has a mal-formed payload or a 'state' that is not even defined in > > dialog-state for example? I understand that people have taken > > exception to this specific usage, but from a generic sense, RFC > > 3265 has such a capability and it is this capability that we were > > proposing to use. > > > > > > > 3. Expect UA's not to "terminate" subscription on receipt of the > > above > > > response as the response contains a "Retry-After" header and thus > > is not > > > a "failed" request. > > > 4. Relay NOTIFY's to other MLA appearance should a NOTIFY be > > accepted. > > > > > > What is the "new role" here? > > > > > > > > > > > > thanks, > > > -rohan > > > > > > > > > > On Thu, Mar 20, 2008 at 9:47 PM, Rohan Mahy <[EMAIL PROTECTED] > > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > Hi Venkatesh, > > > > > > > > I have described a way to implement this feature that uses > > existing > > > > mechanisms, which is what BLISS should really be about > > (how to use > > > > existing mechanism). Nobody has (yet) provided any technical > > > > argument that my proposed method will not work. The > > barrier for > > > > implementing BFCP as I described is no worse than > > implementing STUN, > > > > which many, many vendors have implemented. Several people > > on the > > > > mailing list have pointed out technical flaws with the > > intended > > > > semantics of the PUBLISH-based approach. You have an > > opportunity to > > > > just go implement something that will work. I don't get it. > > > > > > > > thanks, > > > > -rohan > > > > > > > > > > > > > > > > > >
_______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
