Excellent notes. These will greatly improve this document. A few comments inline:
On Sat, Mar 6, 2010 at 11:05 PM, Alan Johnston <[email protected]> wrote: >> Also, I think that trying to hold too firmly to the old key system >> model is a mistake. In the old system, if one set had seized the line, >> no-one else could. That is not the case in SIP, and I think that to, >> for example, prevent a call from ringing at a set with one button for >> the shared AOR because some other set is currently on a call, is a >> huge mistake. (This scenario is described in the examples at the end >> of section 7.1.4) > > I think the draft confuses two cases which we need to clearly separate. > > 1. A UA which understands shared appearances, but for some reason only > supports a single appearance number. I think supporting this requirement is causing a lot complexity in the draft. Maybe this requirement addresses some other feature and not Shared Line Appearances. If possible, we should drop it from this draft because this draft should solely focus on Shared Line Appearances. > If you >> think of a help desk application, and Alice wants Bob to pick up a call >> she has placed on hold, she needs to be able to tell him which call. >> She shouldn't have to figure out which appearance number her button >> happens to map to, and hope that he can figure it out on his set too. >> "appearance 2" does not map to a physical button labelled "line 2". >> On one set it might be physically in a different place from line 2 on >> another set (e.g. >> >> x x vs x >> x x x >> >> - is line two the second one in the first row or the first one in the >> second row?) And she shouldn't have to announce the calling user's name >> or number, if a unique one is even available. Therefore it seems to me >> to be a requirement that the UAs mark each appearance instance clearly, >> by number. > > If there is strong interest in this, we could include a non-normative > appendix or something showing example button maps and arrangements, but > I think this is overkill. This feature must adapt to users and existing > sets and usability requirements, not the other way around. Besides, > anything new will not use hard buttons but use soft keys, so none of > this applies. This is getting into UI. I agree this is an overkill. The draft is already too long. >> - What happens in this model if a phone selects a busy line? > > It fails. I think some sets give 'dialtone' if the line is seized and > some other tone if it is not available. Some phones allow you to barge on a busy line. >> - REQ-7 typo "learn the appearance status of the the group" - >> delete second 'the' >> - I think it means "the status of all appearances of the group >> (shared AOR)" >> - REQ-9. Really? the importance of the appearance number is that users >> can tell each other which call to join or pick up. Do they need to be >> able to tell each other which call they are answering? (maybe) > > The issue is that some phones need to know the appearance number in > order to alert properly. Otherwise, the call can seem to "jump" from > one place to another which can confuse users. This is why we use the > Alert-Info header field. Correct. That's why not assigning an appearance number for UAs that are not capable of assigning one themselves doesn't work. >> - REQ-13 - how is this different from any normal SIP call on hold etc? > > I don't follow. Hold does leak information - the other side knows from > signaling that you are on hold. The other side doesn't need to know > which appearance you are using, as this could imply that other > appearances are in use. Correct. This is one of the reasons that most practical implementations of this feature are B2BUAs. >> - REQ-16: I don't understand "ringdown". If appearance number >> corresponds to a physical button, then how can this work? What if >> two users press the same button at the same time? > > It will work for one and fail for the other. The second will either fail (e.g. if the line was seized as exclusive) or barge-in. >> 4.2. Implementation >> >> 4: "UAs receive the appearance number to use in rendering the >> incoming call in a NOTIFY from the Appearance Agent and in the >> INVITE itself." Why in two places? This increases the complexity. >> Or is it in the NOTIFY just because all NOTIFYs with dialog state >> changes will include it? In which case, why mention it specially? > > It must be in the NOTIFY as it is just part of the dialog state. It > must be in the INVITE to avoid cases where the NOTIFY might get lost and > the UA does not know which appearance to render for the call. Correct. There are also situations where only NOTIFYs are sent to render incoming call and then the answering UA sends the INVITE in the reverse direction. This is necessary for scaling shared groups to large sizes. >> 6: "if the user does not select an appearance or does not care" - why >> allow this? Why not require PUBLISH with appearance number >> before seize? > > > The consensus of the group was that we do not want to force a PUBLISH > before every call with this feature. Instead, only UAs that have a UI > requirement will PUBLISH first. Others can just place calls normally. I tend to agree with the original comment that we should require PUBLISH with appearance number. >> - para 3 on pg 13: "A UA that does not need to select a particular >> appearance number (or doesn't care) would just send an INVITE as >> normal" >> (i.e. without PUBLISHing first) >> - and the AA will assign one. But I don't see why we allow this. It >> muddies the appearance number waters even more. How will the user be >> able to tell someone else how to pick this call up? > > No, this relates to seizure (current draft terminology) - the > pre-selection of an appearance number *before* sending the INVITE. A UA > with hard buttons will require seizure. A UA with a more flexible > display can allow a user to place a call and then update the display > (either during trying, alerting, or connection) with the assigned > appearance number when it is known via the NOTIFY. I tend to agree with the original comment. The UAs participating in shared AoR group must be capable of selecting the appearance number when placing an outbound call. The other feature is known as hunting. That is not - Shared Line Appearance. >> - why would AA not allow calls w/o assigned appearance number? > > Some implementations do it one way, others another way. Personally, I > think it complicates the whole system to allow calls without appearance > numbers using the *same* AOR. Why not just use a different AOR, and the > whole problem is solved? Agreed 100%. >> 7.1.2 Dual Appearance UAs >> - so, and? do we expect them to reject all but "0" and "1"? or just "0"? > > Now this one is clearly confusing. I think this is actually a POSU that > can only do PSTN-style call-waiting (i.e. flash hook). In this case, > I'd say that it can only handle two calls at a time due to its user > interface. > > This section needs rewriting, but I'll wait to see if others have an > opinion on this. This is call waiting with hook flash. Can you have two active (non-held) simultaneous calls in this? I don't think this belongs in Shared Line Appearance draft. >> 8 Interop with non-Shared Appearance UAs >> >> - "It is desirable to allow a basic UA that does not directly support >> shared appearance to be part of a shared appearance group." >> - is it? they won't be able to pick up calls on hold or join calls. > > Why not? They might support dialog package and send INVITE Join or > Replaces but not implement this specification. How will they indicate which appearance number they are going to Join or Replace? >> - a UA is not required to PUBLISH when a call is released, (see 10.6) >> so why would a failed call be any different? The Proxy knows >> that the call failed, so I would expect a dotted line after F47 >> and then a NOTIFY from the AA to Bob and Alice > > That's a good question. There might be cases where the UA wants to > release and appearance number, for example if the user selected it by > mistake. Or, think about a phone with a row of appearance buttons. If > the user runs their finger over all of them, that might cause the UA to > PUBLISH for a whole bunch of appearances. Without a way for the UA to > cancel, all those appearances would be held for the expiration time of > the PUBLISH. With a mechanism, the UA could cancel each one as the next > one was pressed. > > I'll leave this in for the moment to see what others think of this. The UA does need a mechanism to release the appearance. This also happens with 1-stage dialing where the phone provide the dial-tone locally. As soon the use seizes the dial-tone line, the PUBLISH/NOTIFY sequence will happen. The user will now start dialing but may abandon dialing in the middle of it. This will require the UA to release the appearance. Raj _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
