Dale, Thanks for the reply. See a few comments below.
- Alan - On Wed, Jul 6, 2011 at 3:02 PM, Worley, Dale R (Dale) <[email protected]> wrote: > (Despite the Subject: line, which is the Subject: of the message I am > replying to, all text references in my new text are to the -08 version.) > > Only the items which have an ongoing discussion: > >> > BTW, is the latest decision that appearance numbers start with 0, >> > rather than 1? >> >> No, the decision was that appearance numbers start at 1. I think I >> have found all the cases of appearance zero and removed them from the >> document now. > > OK. > >> > But this leads to the point that there is no clear, separate >> > description of the fundamental protocol action, viz., the UA sends a >> > PUBLISH to the Appearance Agent to request an appearance assignment >> > and the Appearance Agent sends a NOTIFY back to the UA with the final >> > assignment. >> >> This UA behavior is described in Section 5.3. I would prefer to leave >> it there rather than move it to this section. > > OK. I think I wrote my original objection when I was reading 5.2 (and > noticing that it was discussing actions) but had not yet read 5.3. > >> > BTW, is there a default value for "exclusive"? The schema doesn't >> > show one. >> >> I clarified that it is false, the same as if it is not present. I >> also described what it means if a <joined-dialog> or <replaced-dialog> >> element is not present. > > OK. I guess there's no place to specify it in the schema. > >> > section 5.3: >> > >> > Should probably add: >> > >> > User Agents which implement call pickup, joining and bridging MUST >> > support sending >>and receiving<<< an INVITE with Replaces >> > [RFC3891] or Join [RFC3911]. >> > >> > and omit the last sentence of the paragraph. Or else, the >> > requirements are more complex than I understand them to be. >> >> No, I believe the text is correct. There are three cases that need to >> be supported by the spec. >> 1. A fully functioned UA that sends and receives INVITE >> Joins/Replaces. It has buttons for "pickup" and "bridge". >> 2. A UA that only received INVITE Join and Replaces. It does not have >> "pickup" or "bridge" buttons, but these features will work if another >> UA initiates them. >> 3. A UA that only monitors the appearance group, and never receives an >> INVITEs (e.g. never registers against the AOR). This UA will never >> "ring", but does show the status of appearances, and has "pickup" and >> "bridge" buttons that will work. >> >> It is this #3 case that support for receiving INVITE Replaces and Join >> is not needed. > > Ah, yes. Every UA has to support Join/Replaces so that other UAs' > pickup and bridge operations work. This is correct. > >> > It's not clear why PUBLISH refreshes are not required after transition >> > to the confirmed state, as RFC 3903 states that published data are >> > soft-state with specified expiration time. If this I-D intends to >> > handle expiration differently from RFC 3903, this needs to be >> > specified clearly. >> >> I added some text to explain this. > > OK -- and the Appearance Agent can use SUBSCRIBE/dialog to get the > needed information. Right. > >> > section 8: >> > >> > The design of the UI is strongly affected by the expected appearance >> > numbers. My belief is that the intended design is that the appearance >> > numbers will be small non-negative integers. (See the item regarding >> > describing appearance numbers per se at the beginning of section 5.) >> > But there needs to be some stated policy regarding appearance numbers >> > that cannot be rendered by the UA. Is the UA allowed to reject them? >> > Section 8.1.1 appears to allow rejection, but this fact is a >> > significant protocol action that should not be buried in an apparently >> > non-normative section about user-interface design. >> >> No, a UA is not allowed to reject an appearance number. I removed the >> confusing text. > > OK. > >> > It would also be useful in practice if some hints were given for >> > interoperation with UAs that implement previous versions of this >> > work. This probably can be limited to methods to detect which version >> > a particular UA implements. >> >> Which version? Earlier versions of this document? Earlier versions >> of the SIPPING document? I'd really rather not do this. If a UA >> supports certain specifications (e.g. dialog event package, Join, or >> Replaces), it should be possible to figure out which pieces of the >> spec will work and which won't, but detailing them doesn't seem very >> useful. > > The techniques that are implemented in practice are generally > draft-anil-sipping-bla-03 and draft-anil-sipping-bla-04. In the real > world, we will need to handle mixed systems that include phones that > implement draft-anil-sipping-bla-03, draft-anil-sipping-bla-04, and > draft-ietf-bliss-shared-appearances. > >> > section 11.8: >> > >> > The description says that a call from one UA in a group to another UA >> > in the group would only use one appearance number. This is not >> > uniform with the rest of the SA architecture and is not the behavior >> > of traditional key phone systems. Are you sure you want to present it >> > this way? >> >> Hmm. I've seen systems that do operate this way. It might be >> possible to allow either policy in the Appearance Agent, but first >> we'd need to figure out how to make this work. For a call between two >> UAs in a group, there is just one dialog between them. It seems that >> allowing this one dialog to use two appearance numbers would break a >> bunch of things. For one thing, the XML would need to allow multiple >> <appearance> elements, or have the same dialog appear twice in the >> XML, each time with a different dialog. Neither seems very good. > > I'm not sure I see how you are looking at this. > > My mental model is what was implemented in really primitive key > systems. You could pick up the handset, push "line 1", connecting to > a circuit that went to the switch. Then dial the common directory > number; the switch would connect that incoming circuit with a > different outgoing circuit to the same phone. "line 2" would ring. > You could put line 1 on hold, then push the line 2 button to connect > the handset to the other line back to the switch, and answer the > incoming call. > > As far as I know, the dialog event package is aligned with this model > because the <dialog> elements don't actually describe *dialogs* but > rather *dialog ends*. If you call from a phone to itself, the dialog > will appear twice in the phone's <dialog-info>, and the two <dialog> > elements will have swapped local-tag and remote-tag values relative to > each other. > > This seems to be what is illustrated in the dialog event in F19 in > section 11.8, although in that case, the two dialog ends are on two > different phones and they are combined in the overall dialog event > info for sip:[email protected]. > > INVITE/Replaces and INVITE/Join use the same model, the Replaces and > Join headers don't specify a dialog, they specify a dialog end. E.g., > if you have a looped dialog from a phone to itself, the > INVITE/Replaces/Join specifies *which* end of the dialog is to be > replaced/joined. Similarly for testing whether to generate a 482 > Merged Request result; if the same dialog is already present on the > phone but with reversed tags, that is OK. > > Within this context, I would expect in the example of F19 that one > <dialog> element would have <sa:appearance>1</sa:appearance> and the > other to have <sa:appearance>2</sa:appearance>. Indeed, it would take > special code for the "incoming" side of the switch/proxy/B2BUA to > notice that although appearance 1 of HelpDesk is in use, the incoming > call we are assigning an appearance to has the same Call-ID (but > swapped tags) as the call on appearance 1, and so should be assigned > the same appearance. > > Since I look at the <dialog> elements, the appearance numbers, > etc. as corresponding to dialog ends, I would expect failures if two > different dialog ends had the same appearance number. > > But it's possible that either model can work. The consequences need > to be examined with some care, I think. In any case, the RFC should > specify one system or the other (and be clear about it), rather than > permitting either. I am now coming around to agreeing with you. You should be able to call yourself, and the only way this could work is if a different appearance number is used for each leg (end) of the dialog. I'll write some text to describe this, and update the example accordingly. > > Dale > _______________________________________________ > BLISS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
