Brett: Replies inline...
On Mon, Oct 20, 2008 at 1:58 PM, Brett Tate <[EMAIL PROTECTED]> wrote: > 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. [Venkatesh] While I understand this may be a desirable, I am not sure I understand the use-case you had in mind where having this information alone in the INVITE would be useful. The application requiring information about appearances could subscribe to the AoR "like" any other User-Agent and gather all information about the call by the time it receives the 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. [Venkatesh] RFC 2206 provides a list of reserved/test URL's. My understanding is that these reserved name spaces are ignored by the client. My thinking was to have applications use these reserved domains in cases where they don't intend to provide any other useful information in the Alert-Info URL? Defining a new header for communicating this information this seems like an overkill to me. It also, probably takes the scope of this document out of BLISS and moves it to SIP/SIPPING? Thanks Venkatesh > > _______________________________________________ > BLISS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bliss >
_______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
