>> 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.
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
