"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
