Thanks Spencer. In fact I agree it would be a good idea to raise the problem somewhere - but not in the context of the current BLISS/ACH draft (other than by reference to some other document).
By the way, I think this is also a relevant topic in the context of the SIP Forum interoperability initiative (the workshop they held in Vancouver) - I can't remember if any of the presentations touched on this. John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Spencer Dawkins > Sent: 14 February 2008 12:16 > To: [email protected] > Subject: Re: [BLISS] ACH - question concerning B2BUAs > > 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 > _______________________________________________ BLISS mailing list [email protected] http://www.ietf.org/mailman/listinfo/bliss
