Dale,
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of [EMAIL PROTECTED] > Sent: 23 April 2008 03:40 > To: [email protected] > Subject: Re: [BLISS] Rejection conditions for ACH > > > From: "Elwell, John" <[EMAIL PROTECTED]> > > Global rejection. The user has responded to this call by rejecting > it with the preference that all other branches should be cancelled > and forwarding to voicemail, forwarding to an assistant, etc. > should not take place. A user would use this facility when she is > unwilling to handle a particular call and does not wish it to be > handled elsewhere. A user would typically use this facility for > unwanted traffic. The fate of the call will depend on proxy ACH > settings, but typically it will result in outright rejection. > > Do please ensure that the "global" rejection has its scope controlled > so that it only involves alternatives within some local domain. As > has been argued elsewhere, since a recipient can never tell who all > the potential recipients are, a recipient cannot validly prescribe > truly global rejection, although it is reasonable to provide rejection > within a scope (e.g., all forks from an AOR). There has been some > work done on this problem already... [JRE] The BLISS ACH design team feels that, on balance, 6xx response codes should be strictly "everywhere", to be consistent with RFC 3261. Also, the design team had seen "global rejection" as being a 6xx response code and applying "everywhere". I think there is a need for such a global response, e.g., for handling unwanted traffic. We could debate whether to have yet another response meaning rejection everywhere within this domain, although personally I am not convinced. John > > Dale > > _______________________________________________ > BLISS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
