Hi Brett, Thanks for your comments on the draft - see my replies below.
Thanks, Alan Brett Tate wrote:
The following are a few comments and questions concerning draft-ietf-bliss-shared-appearances-00. Concerning appearance seize, how does the seized appearance (from PUBLISH) actually get associated with outgoing INVITE appearance? More specifically, is the outbound proxy/b2bua receiving the INVITE supposed to assume this INVITE corresponds to the PUBLISHed seized appearance? And if so, what is explicitly/implicitly tying the two together?
These are very good questions that we will try to address in the next version. In some cases, if some or all of the dialog information is available from the SIP stack prior to sending the INVITE, it could be possible to include this information in the PUBLISH - this would allow very good correlation between the PUBLISH and the INVITE. However, since some SIP stacks may not be able to do this, the other alternative is for the server to match the Contact URI in the INVITE with the local target URI in the PUBLISH. This is a weaker coupling but might be good enough for most purposes.
Do you have a scenario in mind where this coupling is critical?
If PUBLISH not used to seize the appearance (prior to sending INVITE), section 5.3 indicates that the caller PUBLISHes the appearance from NOTIFY. Since the Appearance Agent is already aware of the current appearance status, at what point in the flow is such a PUBLISH needed?
This is another area we need to clarify as we update the call flows and text. There are two possible options - the UA could publish upon receipt of a 100 Trying or from a 180 Ringing. The 180 Ringing is of more interest to other UAs in the group, but the 100 Trying might be sooner, which could result in fewer appearance contention issues.
Concerning incoming calls, why using Alert-Info to indicate the appearance instead of defining or using another header? I ask mainly because I'm not currently aware of a defined value for indicating that the Alert-Info's absoluteURI should be ignored.
The Alert-Info parameter needs to get more attention in the discussion. We need to resolve this issue. I think the reason we chose Alert-Info is because the appearance number tells a UA where to render alerting information (i.e. which lamp should be lit). It would also be possible to define a new header field for this.
The following are a few nits: Section 1: "aappearance". Section 10.2: Paragraph starting "F1 to F4" is not correctly formatted within the txt version. Within the same paragraph, "sate" should be "state".
Thanks - we'll correct these.
Thanks, Brett
_______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
