Thanks for the response. Reply inline. <snip>
> 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? I'm mainly just attempting to understand the proposal. If an appearance number has been explicitly seized using PUBLISH, it would seem desirable to include the appearance number within the INVITE to reduce confusion. Without such explicit indication, the Appearance Agents's involvement with the outbound INVITE would be required to make assumptions to correlate the successful PUBLISH to INVITE. > > 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. This is somewhat related to the open issue at the end of 5.1. A mode of operation where PUBLISH only needed for line-seize and re-synchronization would be useful. > > 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. For the reason mentioned, I currently prefer a new header. _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
