Hi, If C sends different SDP bodies with the same To tag towards A, that is a protocol error.
In general, if an SDP has been sent in a reliable 18x response it is ok to send an "empty" 200 (assuming the 200 has the same To tag as one of the previous reliable 18x responses). Regards, Christer > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Olaf Bergmann > Sent: 13. helmikuuta 2008 22: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 > _______________________________________________ BLISS mailing list [email protected] http://www.ietf.org/mailman/listinfo/bliss
