Alan, Thanks for the reply.
I still worry about small incompatiblities between DSE ESC specs and shared appearance specs. And we still would like to see suggested techniques UAs can used to differentiate INVITE to shared appearances from other INVITEs. Maybe these techniques are out of scope. Also example 10.8 still has some details that aren't quite right. I added these comments inline below. Thanks, Tim > -----Original Message----- > > Message: 1 > Date: Thu, 16 Jul 2009 14:09:48 -0500 > From: Alan Johnston <[email protected]> > Subject: [BLISS] Fwd: Review of draft-bliss-shared-appearances > To: BLISS <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=WINDOWS-1252; format=flowed > > Tim, Raji, & Harsh, > > Thanks for doing this review. See my comments below. > > Thanks, > Alan > > > > *From: *"Ross, Timothy I (Tim)" <[email protected] > > <mailto:[email protected]>> > > *Date: *July 3, 2009 12:47:20 AM JST > > *To: *<[email protected] <mailto:[email protected]>>, > > <[email protected] <mailto:[email protected]>> > > *Cc: *"Chinnappa, Raji (Raji)" <[email protected] > > <mailto:[email protected]>>, "Mendiratta, Harsh V (Harsh)" > > <[email protected] <mailto:[email protected]>> > > *Subject: **Review of draft-bliss-shared-appearances* > > > > Hi Jason and Shida, > > > > Alan asked if I would like to review the shared appearance draft. > > Three of us got together and came up with these comments. > Hope they help. > > > > > > Generally the shared appearance looks good. We spent a couple of > > weeks seeing how we would adopt it into our system, and it > is a pretty > > natural fit. There were a few places where we struggled a > bit, and in > > all but one (comment 3) we found solutions. The comments > under ?Main > > Comments? address these struggles. > > > > > > Main Comments: > > > > 1) The draft does not discuss Alice and Bob being on > separate Proxies > > (SIP trapezoid). This has a few subtleties: > > a) If Bob is using TLS and his UA only accepts > connections > > from his own Proxy, then his UA will need to use a gruu > (obtained from > > Bob?s Proxy) when registering to Alice's Appearance Group. > This means > > that Bob's UA would need to register twice, once with his > own proxy to > > get a gruu, then again with Alice's proxy, passing the gruu as the > > contact. The gruu would also be needed if Bob?s UA is non-routable. > > b) Sip Messages to Bob's Bridged Appearance of Alice' > > Appearance Group need to go through Alice's Proxy, so that Alice's > > Proxy can see these calls and report their state to the Appearance > > Agent. Separate Proxies need to be considered. Some cases: > > i) INVITEs to Alice's AOR ? no problem here > > ii) INVITEwJoin from Alice to Bob -- This message is to > Bob?s Contact > > so would not normally go through Alice?s Proxy. This looks ok at > > first, because this scenario requires that Alice?s UA > PUBLISHes to the > > Appearance Group before sending the INVITEwJoin. But this > runs in to > > trouble in later stages of the call where the Appearance Agent will > > not receive a DSE PUBLISH ( 180 Ringing, 200 OK, BYE). In > these later > > stages, the Appearance Agent needs to get call state from > the Alice?s > > Proxy so it can send the DSE NOTIFYs to the appearance > group UAs. This > > can be solved with Bob obtaining a gruu from Alice?s Proxy, or by > > Alice?s UA inserting a route header to route the call > through Alice?s > > Proxy. > > iii) INVITEwReplaces from Alice to Carol ? this is pretty much the > > same problem as INVITEwJoin except here if Carol was on a separate > > Proxy, her UA would not obtain a gruu from Alice?s Proxy, so a gruu > > won?t make the INVITE traverse Alice?s Proxy. This has to > use a route > > header (at least that is all we can see) > > iv) INVITE sent from Carol to Bob?s contact that was discovered > > through Reg Event Package Subscription for Alice?s AOR -- > Again the > > same sort of problem, but this time, Carol?s UA would not > know to add > > a route header for Alice?s Proxy. Carol is not part of the > Appearance > > Group. Here if Bob?s Contact is a gruu from Alice?s Proxy, then > > Alice?s Proxy would see the INVITE. > > > > > > > > > > If Bob?s UA needs a gruu from Alice?s Proxy to solve 1.a.iv > above, and > > if Bob's UA is using TLS, then Bob?s UA will need to nest > the gruus so > > that an INVITE to his contact/gruu would go through both > Alice's Proxy > > and Bob's Proxy. This looks ok in the gruu draft. Bob would get a > > gruu from his own Proxy, and then register with that gruu > to Alice's > > Proxy, asking for another gruu. The gruus should then nest. > Then all > > INVITES that end up on Bob?s Shared Appearance for Alice > will traverse > > Alice?s then Bob?s Proxy. > > > > c) With separate proxies, we assume that when Bob's UA > > registers with Alice's Appearance Group, Bob's proxy will > authenticate > > Bob's credentials, not Alice's, so that the REGISTER should > traverse > > Bob's proxy first. The REGISTER message can add a route header to > > Bob's Proxy, but is this enough to ensure that Bob's Proxy does the > > authentication, and that Alice's Proxy trusts it? Does > authentication > > on a trapezoidal REGISTER work the same way as a trapezoidal INVITE? > > d) When Bob sends an INVITE on his shared > appearance for > > Alice?s Appearance Group the INVITE needs to go through > Bob?s Proxy, > > then Alice?s. Bob?s Proxy is needed to challenge Bob?s > credentials, > > and Alice?s Proxy is needed to report Call events to the Appearance > > Agent. Bob?s Proxy can be traversed with a route header. Alice?s > > Proxy is a bit trickier, and Bob?s Proxy would have to > route the call > > to Alice?s Proxy based on the ?From? header or Contact (if > a contact > > parameter is defined to identify the contact as a Shared > Appearance to > > Alice (see end of comment 2)) > > > I think that this all does work as long as Alice and Bob use > GRUUs and they use their GRUU from the initial registration > as the Contact for their 3rd party registration. > > We should probably include some text in the draft about this. > > > 2) The draft does not discuss (or we missed it) > how Bob's > > UA distinguishes its own calls from Alice's Appearance > Group's calls. > > We assume the "To" header is used, but this may lead to trouble. > > Consider a call to "[email protected] <mailto:[email protected]>" > > that is forwarded to Alice. When Bob's UA gets the call, the "To" > > header will be "[email protected] > <mailto:[email protected]>", and not > > "[email protected] <mailto:[email protected]>". Bob's UA may then > > need then to rely on history-info. > > > > If it is legitimate for Carol to INVITE Bob's contact discovered > > through a Registration Event Package Subscription to > Alice?s AOR, then > > it is difficult for Bob's UA to know that this is an INVITE to the > > Shared Appearance, and not his regular appearance. The "To" header > > would be for Bob's contact, and history-info would not > mention Alice's > > AOR. > > > > A gruu could solve this problem because it contains Alice?s > AOR, but > > only if it is a public gruu. > > > > Instead of relying on a combination of ?To? header, > history-info and > > public gruu, Bob's UA could tag his Contact with a contact > parameter > > distinguishing the Contact as an "Alice Appearance Group" > Contact (ex. > > Contact: <[email protected] > > <mailto:[email protected]>;[email protected] > > <mailto:[email protected]>). This would > put Bob's UA > > in control of distinguishing incoming INVITES and not have > it rely on > > the rest of system. Adding an Appearance Group parameter to the > > Contact does not have same problems that adding an > appearance number > > parameter has. > > I think that either the From or the use of a different Contact URI (or > GRUU) should solve this. Shouldn't these alternatives be mentioned in the spec? Maybe in an appendix? True it is up to the UA which way it wants to differentiate shared appearance INVITES for other INVITES, but there are tradeoffs between the alternatives. Some relying more heavily on the rest of the sip infrastructure than others. > > > > > > > 3) The draft leverages the Dialog State Event ESC but restricts the > > DSE PUBLISHes sent by the UAs. This terse PUBLISHing seems to > > conflict with the ESC/PUBLISH RFC (3903). The Shared > Appearance draft > > states that "In some cases, the Appearance Agent may not have full > > access to the complete dialog state of some or all of the > UAs in the > > group. If this is the case, the Appearance Agent will > subscribe to the > > dialog state of individual UAs in the group to obtain this > > information." This seems to require that the appearance agent (an > > extended DSE ESC) subscribe to the group UAs, while our reading of > > 3903 for DSEs would have the UAs publish all these events > by default. > > This is not the normal mode for this feature. The normal > mode is that UAs PUBLISH, but not for every dialog state event. > > > > > Reducing the PUBLISH traffic is a great idea, but I think > it belongs > > within the definition of DSE ESCs and not just in the shared > > appearance draft. All DSE ESC?s have this same traffic problem. > > There also may need to be some sort of query to allow UAs and > > Appearance Agents to go into this terse mode, allowing default DSE > > ESCs/UAs to work. > > Does it help to think of this feature as having an implied > filter for dialog state events? This filter is such that > most PUBLISHes don't get sent, just the ones we are interested in. > I am not sure it helps. When a shared appearance UA PUBLISHes to the appearance agent/DSE ESC (say Alice's as in version 02 of the draft), how does it know what the PUBLISH is for? If could be for the Alice's appearance agent, or it could be for Alice's DSE ESC that other UAs are subscribing to. When does it apply the filter? This is the problem we see. A system has UAs that publish dialog state events to an event state compositor, following RFC 3903 and RFC 4235. These RFC's (at least as I read them) have the UAs publish all states to the ESC. Now we add an appearance agent. The natural way to do this is, as the shared appearance draft suggests, extend the DSE ESC to be an appearance agent. This would be pretty simple, except that the appearance agent does not expect all events to be published, and the DSE ESC does. If the appearance agent does not sniff call states from the proxy (the simpliest way to extend the DSE ESC to an appearance agent), then it needs to SUBSCRIBE to the UAs for the DSEs that the UAs are already sending. When this happens, do the UAs send both PUBLISH and NOTIFY for DSEs not normally published in the shared appearance draft? Or do the UAs just send PUBLISHes, and the appearance agent/DSE ESC is smart enough to treat them as NOTIFYs? Is it possible to have the UAs respond to the SUBSCRIBE with some 4xx if it already PUBLISHes all the DSEs? Or can the UA respond with a 3xx redirect, redirecting the SUBSCRIBE to the ESC? This tells the subscriber to use the ESC for DSEs, instead of the UA, and since the ESC is the appearance agent, then the appearance agent knows that the ESC has complete state, and therefore the PUBLISHes are already complete. (this would when any UA tries to SUBSCRIBE for DSEs directly to a UA instead of an ESC) > > > > This is really the only part of the draft that is giving us > trouble. > > We have already defined a DSE Event State Compositor, and all UAs > > PUBLISH DSE events to it. Extending our DSE ECS to be an > Appearance > > Agent is a very natural fit, except that the terse PULISING in the > > Shared Appearance draft seems to conflict with our > interpretation of > > what a DSE ESC and supporting UAs should be. We don?t know how to > > resolve this while still following both RFC 3903 and the shared > > appearance draft. > > > > > > > > Less Main Comments: > > > > 4) Starting Appearance numbers with 0 confused me. When > first seeing > > this, I thought ?0? may have special meaning like "no > appearance". It > > became clear that this was not so after further reading. I think > > starting appearance numbers with ?1? would be clearer. > > I don't know - this draft has been around for many years, > starting at 0. It might cause backwards compatibility > problems if we change it now. > > > > > > > > 5) Example 10.1 > > > > In example 10.1, it would have been more interesting to > > see Bob's registration/subscriptions to the Appearance Group > > identified with Alice's AOR instead of seeing Alice?s > > registrations/subscriptions. Bob?s registration (I think) > would look > > like a third party registration. And I assume it should > challenge for > > Bob's credentials, and not Alice's. > > Yes, I have made this change, and it has created a discussion > about 3rd > party registration. > > > > > > 6) Example 10.2 > > > > What happens if some one else, maybe another > proxy adds an > > alert-info to the message. Does the "Proxy" then add the > "appearance" > > parameter to that alert-info? Does it remove the previous > alert-info > > and add its own? > > I added some text to cover this case. I think the proxy > applies normal > Alert-Info policies - that is, keeps ones it trusts, strips > ones it does > not. > > > > > > 6a) Example 10.2 > > "However, if Carol answers both Alice and Bob and keeps > > both dialogs active, then the Appearance Agent will need to resolve > > the situation by moving either Alice or Bob's dialog to a different > > appearance." --> Shouldn't this end up being a joined > call between > > Alice, Bob and Carol?. Same as if Bob answered the call, the Alice > > sent and INVITEwJoin? > > > This would be true if the media were mixed. However, if > Carol does not > mix the media but keeps the two calls separate (i.e. one on hold, one > active), then this is different from the Join case. > > > > > 7) Several of the examples are missing the dashed special > > communications line between the proxy and the appearance agent > > (<------>: like the dashed line between F1 and F2 in > example 10.2). > > Putting these in would clarify the examples. When reading it at > > first, I was not sure if this special communication was missing, or > > the PUBLISHes were missing. These are missing in Examples > 10.3, 10.4, > > 10.5?, 10.6, 10.7, 10.9, 10.10, 10.11?, 10.13. > > I tried to add them all in - let me know if I missed any. I can't see any more missing ones > > > > > > 8) Example 10.6 > > "Bob and Carol are in a dialog, created in one of the > > previous two call flows" --> Previous example (10.5, one of the > > ?previous two call flows?) does not allocate appearance number, but > > 10.6 de-allocates it. > > > Right - fixed the reference. > > > > > 9) Example 10.8. > > I think this call from Bob is from a regular > appearance, > > not his shared appearance to Alice. I think this should be made > > clear. I wasn't sure if it was from Bob?s shared > appearance, or Bob?s > > regular appearance. > > Good catch - this was a mistake which has been fixed. > > > > > 9a) Example 10.8 > > Shouldn't the DSE NOTIFY F16 be from [email protected] > > <mailto:[email protected]> and not [email protected] > > <mailto:[email protected]>? > > > > I'm not sure if this is fixed or not with the renumbering of the > examples. Can you check? The From header looks correct now. But it is now F19, and not F16 (the sequence diagram shows F19 while the detail shows F16) Also the DSE body looks incorrect. I think the local and remote elements are reversed. Local should be alice, and remote should be bob (unless I am confused) and the direction should be "recipient" not "initiator" > > > > 10) Example 10.12 discusses outgoing/outgoing race condition. > > Examples for the other two race conditions would be good. > > Outgoing/Incoming and Incoming/Incoming. Depending on the > > Proxy<--->Appearance agent link, outgoing/incoming may have problems > > Good idea - I added the Incoming/Outgoing. The > Incoming/Incoming one I > think would only happen if the Alert-Info appearance didn't match the > NOTIFY appearance, and this is mentioned in the text. > > > > > > 11) Appendix A > > "For example, the proxy could fetch this information by > > initiating a > > SUBSCRIBE request with Expires: 0 to the > Appearance Agent > > for the AOR > > to fetch the list of lines that are in use. > > Alternatively, it could > > act like a UA that is a part of the appearance > group and > > SUBSCRIBE to > > the State-Agent like any other UA. " --> This > has a small > > outgoing/incoming race condition. Just after the proxy polls for a > > free appearance number on an incoming INVITE, another UA > could request > > an appearance number with a DSE PUBLISH. That UA could > pick and get > > the same appearance number as the Proxy chooses from the DSE poll. > > > We got rid of this section. > > > > > 12) Example 10.7 > > When Carol hangs up F48, does NOTIFY 52 show > "terminated" > > but strip out the appearance number? The appearance number > is now in > > use between Alice and Carol. I worry that if NOTIFY F52 shows > > terminated with the same used appearance number, UAs may mistakenly > > think the number is free. > > I think we dealt with this race condition using the joined-dialog and > replaced-dialog elements. Let me know if you still think > this is a problem. > > > > > > > > Questions > > > > Q1) Example 10.2 > > > > Can the Notifies F2 - F4 come after the INVITE F7? I > > assume both ways work, and both are possible. > > > > > > Yes, I included text saying this. > > > > > > > > > > Trivial Comments > > > > T1) Section 13.1 refers to 5.1.1 and 5.1.2. Neither one > exists. Think > > they actually mean 13.1.1 and 13.1.2 > > > > T2) page 5 (wording) > > > > "The sharing or appearance of these lines > between a number > > of phones is what gives this feature its." -> its name. > > > > T3) page 9 (wording) > > > > "The Appearance Agent learns the > group state > > either dialog state publications from members." -> missing words > > > > Thanks for the nits. > > > Harsh, Raji, Tim > > > > > > Tim Ross > > 1-732-852-2104 > > [email protected] <mailto:[email protected]> > > > > > > > ------------------------------ > > _______________________________________________ > BLISS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bliss > > > End of BLISS Digest, Vol 31, Issue 31 > ************************************* > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
