RFC3265 mentions an "implied action" in section 3.2.2 with regards to a non-2xx response. Here, the "implied action" could be: client, wait then re-evaluate the status of all appearances before trying to use an appearance. A typical reason for rejection would be a glare condition, where one client hadn't yet received notification that a particular appearance was being used by another client. Waiting for the Retry-After period should allow the client to receive updates on appearance usage. 10 seconds seems a little long to be user-friendly. Perhaps 1-2 seconds makes more sense. Here's my take on the thirst/drink analogy: <precondition: client believes glass #1 is available to drink from> Client: I am drinking from glass #1 ? Server: No you're not drinking from glass #1. Try taking a drink in 2 seconds. <Client waits 2 seconds during which it learns someone else is drinking from glass #1. However, no one appears to be drinking from glass #2> Client: I am drinking from glass #2 ? Server: Ok. One significant drawback I see with the current NOTIFY/PUBLISH mechanism of the MLA draft is that it *requires* clients to report dialog status to the Appearance Agent. Making a clean separation of "floor control" from dialog status exchange would allow more flexibility for an implementation where dialog status could be composed entirely on the server side, based on floor status and call status (when the server remains in the signaling path of each call). Clients aware & capable of using floor control could do so, and clients either unaware or disinterested would not use it, though the server could actually manage floor control on behalf of these clients. -Bill ________________________________
From: [EMAIL PROTECTED] on behalf of Paul Kyzivat Sent: Wed 3/26/2008 5:52 PM To: Venkatesh Cc: Rohan Mahy; [email protected] Subject: Re: [BLISS] MLA with Floor Control Venkatesh wrote: > Paul: > > Replies Inline..... > > On Wed, Mar 26, 2008 at 6:07 AM, Paul Kyzivat <[EMAIL PROTECTED] > <mailto:[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"..... But I'm not asking anything. I am *telling* you I'm thirsty, because you asked to be told. What you are proposing seems to be another form of event notification rate limiting, without the benefit of actually reducing the rate. Paul > 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]> > > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]:[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 _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
