Olaf, Thanks for filling in the details of your concern.
I think our opinions differ in the following respect. I see ACH as being a capability whereby some entity (UA or proxy) detects that some condition has occurred and initiates some action (the actions typically being to reject, forward (retarget), redirect, etc. End of story - that is the scope of the ACH work in BLISS - how to ensure that ACH can be achieved in a multi-vendor environment without interoperability problems. We are addressing problems like avoiding conflicts between different entities attempting ACH, availability of information to those entities to allow them to make correct ACH decisions, etc.. 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. 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. John > -----Original Message----- > From: Olaf Bergmann [mailto:[EMAIL PROTECTED] > Sent: 13 February 2008 20:46 > To: Elwell, John > Cc: [email protected] > Subject: Re: [BLISS] ACH - question concerning B2BUAs > > "Elwell, John" <[EMAIL PROTECTED]> writes: > > > However, the point was made that there may be other types > of behaviour, > > specific to certain types of B2BUA, which might have an > impact. These > > are to do with B2BUAs that fork but hide from the upstream side the > > multiple early dialogs that are generated on the downstream > side. I will > > leave the originator of these comments to expand further on this. > > So, here is the issue that I guess is a typical problem that is faced > in an ACH scenario (although I am aware of the fact that this is a > problem of the B2BUA manufacturer, not the entity that performs ACH). > > Consider the following message flow where A sends an INVITE through > B2BUA B to proxy C. Here, at C, the INVITE is being forked to the > contatcs X, Y, Z: > > -------> X > / > / > A ----> B -----> C --------> Y > \ > \ > -------> Z > > > Now, X, Y and Z create 183 responses with distinct To-tags and an SDP > bodies for playing early media. The reponses are forwarded upstream by > proxy C and everything would be fine of A received these responses. > > But, many B2BUAs I have seen so far claiming to be what marketing > calls a session border controller (SBC) had an interesting feature: > They hide the multiple (early) dialogs on the downstream side from the > calling UA on the upstream side. Hence, B presents to A a single > To-tag throughout the entire session, i.e., when the first provisional > response---e.g. from X---is received, it is forwarded to A, with some > tag attached at the To header. Other provisional responses, including > those from Y and Z that have different To tags are mapped to early > dialog that already exists between B and A (re-using the initial To > tag generated by B for the first provisional response received from > downstream). > > At this point, A has seen three provisional responses within a single > early dialog, carrying different SDP bodies (the media addresses > usually are aligned to B's media address but codecs and ports may be > different). > > To make things more complex, Z might send a 200 OK. Given that the > provisional responses have been reliable (in terms of 100rel), there > might be no session description contained in the 200 OK (out of my > head I am not sure if this is really correct but I can observe this > every day). The body-less 200 OK is forwarded by B to A (also seen in > real life). > > Question 1: What session description is A considered to use? > > Question 2: If Y in the following sends a 200 OK without SDP body and > this 200 OK is forwarded to A, how would A tear down this > call leg? > > First of all, I agree that this seems to be a bug of the B2BUA related > to offer/answer which is generally out of scope for bliss. But as > these buggy devices exist---and I did not really find out what is the > correct way to fix this bug when presenting multiple early dialogs to > A is not an option for some reason---I have the feeling that it could > make sense to document this family of problems just to make clear that > performing (functions like) ACH in certain architectures might have > effects that the operator of the ACH performing entity did not think > of in the first step. > > Regards, > Olaf > > _______________________________________________ BLISS mailing list [email protected] http://www.ietf.org/mailman/listinfo/bliss
