Replies.... On Tue, Oct 21, 2008 at 6:41 AM, Brett Tate <[EMAIL PROTECTED]> wrote:
> >> 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? > > I'll provide the response within the reply to Alan concerning the topic. > > > > > 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. > > <snip> > > > [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? > > Yes; RFC 2606 provides uri possibilities. However unless something is > documented concerning the topic, it is indeterminate as to how the > receivers will act. Even if documented, it can cause non desired > behavior until devices have been updated to expect receiving such a uri > and know how to interpret the situation; however the worst case would > likely just be a useless dns query and related log failure. > [Venkatesh] We can definitely document UA's ignore the URI if it they contain the reserved domains outlined in RFC 2206 but thought that was the intent of of RFC 2206. IMO, it is easier to document this if this is what we need, rather than defining a new header in SIPPING (assuming it will not get frowned upon and rejected in SIPPING); and updating all network elements to allow support for this new header.
_______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
