On Mar 26, 2008, at 12:31 AM, Venkatesh wrote: [snip] > [Venkatesh]: I disagree.... You might want to talk to your "old" > PBX friends about reliability of their "old" products.... Most of > them had much better reliability numbers than current IP-PBX > vendors.... [snip]
I agree that a traditional *PBX* is generally reliable even though most are deployed without redundancy. However the feature you are trying to replicate is associated with *Key Telephone Systems* which are much less reliable. I have used both on a production basis and I do understand the difference. > > On a closing note, I would also like to state that thus far I have > > not seen any "technical" limitations to the NOTIFY proposal. > > How about the objection that the state agent has to operate > differently whether you are operating with or without seizure? > > [Venkatesh]: I am not sure I understand the objection? MLA is a new > feature that requires new behavior. UA's that need this behavior > will request this using the "sla" tag in their subscription > request. UA's that don't need this will simply subscribe to dialog- > state? The state agent has to reject a "glare" request if you include the "sla" tag, but better not reject a "glare" request if one is not included. > > I believe those concerns should have been raised when the dialog > > state draft proposed advertising such states and not when building > > an application using a behavior outlined in an RFC IMO. Others I > > have only heard revolve around subscriptions terminating upon > > receipt of a non 2xx response terminating a NOTIFY (to which I have > > provided pointers to relevant sections in 3265 that indicates > > contrary to the belief) > > I'm sorry, I must have missed that. Can you please repost this > pointer? > > [Venkatesh]: Want to draw your attention to section 3.2.2 of RFC > 3265... Specifically, the following that defines what a "failed" > request is: > > "A NOTIFY request is considered failed if the response times out, > or a non 200 class response code is received which has no Retry- > After header and no implied further action which can be taken to > retry the request". > > The MLA draft proposes rejecting the request with a non 2xx > response BUT with a "Retry-After" header. Technically, per the > above definition of RFC 3265, the request cannot be considered failed. The semantics of Retry-After are to try the IDENTICAL request again. Many SIP stacks handle this retry automatically and will not pass the error up to the application until it has retried. It is unlikely that an identical request that caused a glare will still work, since the glare condition will probably still exist. thanks, -rohan > > and a third being that of invalid behavior of a State Agent. If it > > will help, I don't have a problem with calling the State Agent as a > > MLA Event Manager or something else. May be there are others that > > was discussed in the IETF meetings and would appreciate somebody > > summarizing the same for the benefits of those that did not attend. > > There is a definition of a state agent in RFC 3265 and in the dialog > event package. Changing the name of the thing will not help. If the > goal is to reuse SIP then the bliss WG is not in a position to define > a completely new role or new behavior that is out of the scope of an > event package. BLISS simply does not have the charter to do so. You > would have to take your requirements to SIPPING and then proceed with > a new mechanism in SIP. > > [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. > 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]> > 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
