Just as a data point... > The problem you raise is what happens later - ACH is finished, but the > results of ACH (particularly in the forwarding case) expose other > problems, namely when certain types of B2BUA are in the path. > > The way I view it is that standard proxy behaviour, without ACH, would > route an INVITE request to any registered contacts (either in parallel, > in series or a mixture, depending on priorities). This too can mean > forking and the sort of interactions you describe if there is a > dialog-hiding B2BUA in the path. It is forking that leads to these > problems - ACH is just a way in which forking can arise, beyond basic > proxy forking. > > So: > 1) I firmly believe that we are not chartered to solve this problem in > BLISS (I think you agree with this). If you want to solve it, then I > think it has to be addressed to SIPPING.
This is my understanding as well, and just because something isn't chartered in BLISS doesn't mean that it shouldn't be chartered SOMEwhere ... > 2) I also believe that it would be inappropriate to refer to this type > of problem in the ACH-analysis draft, because it is not something that > can be described in a sentence or two. If it takes about a page to > explain the issue, then in my opinion this would detract from the main > message of the ACH-analysis draft. ... and even if describing the problem in ACH isn't appropriate, describing it SOMEwhere is ... ... and further - if there WAS a draft that described this problem concisely, I'd say refering to that draft in ACH would be appropriate. So while I agree with John, please don't let what we are saying stop you from providing text. Thanks, Spencer _______________________________________________ BLISS mailing list [email protected] http://www.ietf.org/mailman/listinfo/bliss
