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.
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.
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.
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?
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
