Hi Rohan: Technically speaking, per section 3.2.2 of RFC 3265, a non 2xx response that has a Retry-After header is not considered a "Failed" and thus should not terminate the subscription at the UA....... . This is what the MLA draft is currently using... But I would prefer to have a specific response code instead of relying on this definition. It is what I have been requesting in the mailing list as well...
I am not sure there is a simple solution that would allow a mesh configuration of phones to work when you need line seizure acknowledgment. Either proposal (BFCP or NOTIFY) relies on having a central arbitrator to simplify the solution. Thanks Venkatesh On Fri, Mar 21, 2008 at 6:47 PM, Rohan Mahy <[EMAIL PROTECTED]> wrote: > Hi Venkatesh, > > Phone1, Phone2, and Phone3 all share a line using your proposed scheme. > Phone1 and Phone2 both try to seize at about the same time, but Phone1 is > slightly faster. > > Lets see what happens in two cases. First with a state agent: > > The NOTIFY from Phone1 is "accepted". > > The NOTIFY from Phone 2 is rejected, and according to RFC 3265, the dialog > terminates. Oops. > > Now lets try this with a mesh of dialogs among the three phones. This is > even worse as you have no idea whether Phone3 will accept the dialog > update from Phone1 or from Phone2. > > State agents aren't supposed to change the semantics of the event package > and I think this demonstrates that the proposed package does. > > thanks, > -rohan > > > > Francois: > > > > I am not sure about additional complexity with using SIP as the > mechanism > > and resulting in PUBLISH/NOTIFY flying all over the place. All the draft > > was > > proposing is that the UA send a NOTIFY indicating that it is going to > > place > > a call using a specific line *before* sending out the actual INVITE. > This > > NOTIFY would have gotten sent by the UA anyway post dialing. The draft > is > > just moving the position of when the NOTIFY gets sent out. From an end > > user > > perspective, when a user dials a number, he/she would simply see that it > > is > > 'attempting' to use a specific line appearance when the call is placed. > If > > there is no contention for that specific line, call proceeds fine. If > the > > NOTIFY is rejected, the line goes busy and user is provided a fast busy. > > > > Thanks > > Venkatesh > > > > On Fri, Mar 21, 2008 at 12:15 PM, Francois Audet <[EMAIL PROTECTED]> > wrote: > > > >> It's not POST call-setup. It's AT call setup. > >> > >> It's the difference between: > >> > >> Line seisure by pressing key > >> > >> - User press Line appearance. This is reported to Presence/Dialog > >> server. PUBLISH or BFCP. > >> - Presence/dialog for that line goes "busy" right away, for anybody > >> that sees it > >> - Nobody can use that line regardless of how long it takes the user > >> to dial > >> > >> Line seisure at call setup > >> > >> - User press Line appearance. This is local: no reporting anywhere. > >> - Nothing changes anywhere > >> - Line is "seized" when the call is actually made > >> - In the interim between pressing the key, somebody else could also > >> press the key and make a call. If he's faster, he'll be able to > seize > >> the > >> line before the first guy. > >> > >> Besides the mind-numbing complexity of doing the first approach, there > >> are > >> also advantages to the second approach. It avoids the problem of having > >> somebody "hogging" the line by pressing on the key and not dialling > >> anybody. > >> > >> And frankly, the SIP mechanism to "arbitrate" the > >> line-seisure-by-pressing-an-appearance will by definition be very > >> complicated and generate lots of traffic. I don't be believe it will be > >> simpler than BFCP. > >> > >> Furthermore, there will be lots of potential for race condidtions > (while > >> the NOTIFYs and PUBLISH are flying all over the place). This will > result > >> in > >> very poor user experience. Basically, pressing on the button will often > >> "not > >> work". (I have a vision of pissed-off users repeatedly pressing the key > >> that > >> doesn't want to turn on, and banging on their sets). > >> > >> The second option, with line seisure at call setup does not suffer from > >> this problem. The expectation is that the line is "taken" when you > >> actually > >> make the call, not when you press the button. > >> > >> I will point out that PBXs (as opposed to key systems) often work the > >> second way, not the first way. > >> > >> This is all very similar to arbitrating between making an outgoing call > >> and receiving an incoming one while dialing. > >> > >> ------------------------------ > >> *From:* Bill Mitchell [mailto:[EMAIL PROTECTED] > >> *Sent:* Friday, March 21, 2008 11:58 > >> *To:* DOLLY, MARTIN C, ATTLABS > >> *Cc:* [email protected]; Audet, Francois (SC100:3055); [EMAIL PROTECTED] > >> *Subject:* RE: [BLISS] MLA with Floor Control > >> > >> My answer is YES. Line seizing before call setup is worthwhile, > >> because > >> it enables shout control with a **reasonable end-user experience**. > >> > >> > >> > >> Line seizing post-call-setup is NOT worthwhile. It only adds confusion > >> with potential mid or post-dial line key hopping. > >> > >> > >> > >> > >> > >> Pre-call-setup line seizure can be optional. > >> > >> > >> > >> > >> > >> BFCP has the right primitives, but I firmly agree with Venkatesh that > it > >> adds significant network complexity and would be a large barrier for > >> implementation. I'll add my vote for a SIP-based mechanism to > >> communicate > >> line seize requests and responses. > >> > >> > >> > >> -Bill > >> > >> > >> ------------------------------ > >> > >> *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On > >> Behalf > >> Of *DOLLY, MARTIN C, ATTLABS > >> *Sent:* Friday, March 21, 2008 9:09 AM > >> *To:* Francois Audet; Venkatesh; Paul Kyzivat > >> *Cc:* Rohan Mahy; [email protected] > >> *Subject:* Re: [BLISS] MLA with Floor Control > >> > >> > >> > >> I agree, NO > >> > >> > >> ------------------------------ > >> > >> *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On > >> Behalf > >> Of *Francois Audet > >> *Sent:* Friday, March 21, 2008 11:45 AM > >> *To:* Venkatesh; Paul Kyzivat > >> *Cc:* Rohan Mahy; [email protected] > >> *Subject:* Re: [BLISS] MLA with Floor Control > >> > >> The real question is "should we do line seizing before call setup" as a > >> worthwile feature. > >> > >> > >> > >> I think "No". > >> > >> > >> > >> If the group feels "Yes", then we could look at BFCP. I really think we > >> should not be stupid enough to make this mandatory. > >> > >> > >> ------------------------------ > >> > >> *From:* Venkatesh [mailto:[EMAIL PROTECTED] > >> *Sent:* Thursday, March 20, 2008 21:49 > >> *To:* Paul Kyzivat > >> *Cc:* Audet, Francois (SC100:3055); Rohan Mahy; [email protected] > >> *Subject:* Re: [BLISS] MLA with Floor Control > >> > >> I don't disagree with your argument. However, I also think, should a > >> particular approach unduly complicate implementation of a feature > >> (especially require support from multiple network elements for a > feature > >> to > >> work), vendors are going to resort to non standard ways to implement > the > >> feature as well...... > >> > >> Venkatesh > >> > >> On Thu, Mar 20, 2008 at 9:15 PM, Paul Kyzivat <[EMAIL PROTECTED]> > >> wrote: > >> > >> I'm not promoting one way or the other. Ultimately people building > >> products will build the functionality they think they need to sell > their > >> products. If people feel this is important then they will want a way to > >> do it. If it isn't standard then it will be nonstandard. > >> > >> Paul > >> > >> > >> Francois Audet wrote: > >> > > >> > > >> >> There is a tradeoff... > >> >> > >> >> If multiple extensions can place outgoing calls from the same > >> >> line, then the line doesn't have "binary" status, so it can't > >> >> be indicated as active or not with a light. And you can't > >> >> "conference in" by picking up on the same line. > >> >> > >> >> While I am not into it myself, I can see how someone can > >> >> build a "business process" around the specific way in which > >> >> lines are managed by the phones, and then be very upset if > >> >> they can't get that same user experience. > >> > > >> > Yeah, sure, it's doable. I do not believe that adding the concept > >> > of a Line number to do this is required to do this, or even > >> > desireable. > >> > > >> >> Now you can come up with some very nice UIs that provide > >> >> better user experience, if you have a suitable display > >> >> instead of just a bunch of lights. (E.g. an entry for the > >> >> "number" (AOR that people call), and a variable length drop > >> >> down list of active calls, showing the callerid of the > >> >> caller, how long it has been active, and which extensions are > >> >> currently connected to it.) But that is *different*, and > >> >> requires a device with richer UI. > >> > > >> > Agreed. > >> > > >> > My point is that we shouldn't bastardize the protocol with all this > >> > complex extra protocol (Line numbers, BFCP, NOTIFY/PUBLISH-storms, > >> etc.) > >> > just do do this. > >> > > >> > The basic "single-lamp" based approach is doable without any of this. > >> > > >> _______________________________________________ > >> BLISS mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/bliss > >> > >> > >> > >> > >> _______________________________________________ > >> BLISS mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/bliss > >> > >> > > > >
_______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
