Subject: [BLISS] ACH - question concerning B2BUAs

From: "Elwell, John" <[email-masked]>
Date: Wed, 13 Feb 2008 16:59:33 +0000

During design team discussions on Automatic Call Handling (ACH), a
question arose concerning the impact of B2BUAs on ACH.

At present, the ACH draft (draft-ietf-bliss-ach-analysis-00) discusses
ACH at UAs and ACH at proxies, and interactions between these. In
principle the discussion on ACH at proxies applies equally to ACH at
B2BUAs, where B2BUAs perform the role of domain proxy.

The issue that was raised concerned other B2BUAs on the path of a call,
either between the UAS and the proxy or between the proxy and the UAC.
In the first case these might have impact on information between the UAS
and the proxy, which the proxy needs in order to perform ACH
successfully. In the second case it might have impact on information
sent to the UAC for delivery to the calling user.

One such issue is the HERFP issue, where there is a forking B2BUA on the
path and as a result only one of several final response codes can be
sent backwards. However, in my opinion this is no different from the
case of a forking proxy on the path. The next version of the ACH
analysis draft will mention the HERFP issue.

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.

The charter of BLISS/ACH (or indeed the charter of BLISS) does not
require us to address B2BUA issues. Also, certain B2BUA behaviours can
impact other aspects of SIP, not specifically ACH. Furthermore, B2BUAs
vary widely in their behaviour and we cannot hope to address all
possible architectures. However, it might be beneficial to mention any
particular behaviours that are known to cause problems for ACH, even if
we don't attempt to solve such problems.

Comments?

John

_______________________________________________
BLISS mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/bliss

---

From: Olaf Bergmann <[email-masked]>
Date: Wed, 13 Feb 2008 21:46:09 +0100

> 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

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Feb 2008 08:51:30 +0000

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-masked]] 
> Sent: 13 February 2008 20:46
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [BLISS] ACH - question concerning B2BUAs
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 14 Feb 2008 06:15:35 -0600

Just as a data point...

> 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 ...

> 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

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Feb 2008 13:57:37 +0000

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

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Spencer Dawkins
> Sent: 14 February 2008 12:16
> To: [email-masked]

---

From: Olaf Bergmann <[email-masked]>
Date: Fri, 15 Feb 2008 09:06:47 +0100

John, Spencer,

thanks for your comments. Although I agree that the solution to this
kind of protocol-related problems is not in the scope of bliss (in
fact, when looking at the reason why this broken message flow exists
at all, you will see that the cause is more on the policy side since
this is the major reason why those SBCs behave the way I described), 
I also think that when describing the interaction between distinct
devices, the caveats should at least be mentioned. 

The reason why I brought this into the ACH discussion is that in "my"
network, most problems that come with forking are (1) a result of
performing ACH and (2) occur on the message upstream as illustrated in
my example. 

Thanks,
Olaf

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 15 Feb 2008 08:16:50 +0000

Olaf,

Maybe you can suggest some words that are clear and concise and will fit
somewhere in the ACH-analysis document?

John 

> On Behalf Of Olaf Bergmann
> Sent: 15 February 2008 08:07
> To: Spencer Dawkins
> Cc: [email-masked]

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 15 Feb 2008 13:09:33 +0100

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

> Sent: 13. helmikuuta 2008 22:46
> To: Elwell, John
> Cc: [email-masked]
> > 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
>                     /
>                    /
> 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).
> 
> 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
>

---

From: Olaf Bergmann <[email-masked]>
Date: Fri, 15 Feb 2008 23:11:31 +0100

> somewhere in the ACH-analysis document?

Ok, I will have a look where it could be appropriate. 

Thanks,
Olaf