[BLISS] WG: Issue with CC possible indication and forking proxies

["Alexeitsev, D" <[e-mail]>]

 Hi Paul

Thanks for the comments.

Alexeitsev, D wrote:
> Hi,
> 
> There is an issue with the transport of the CC possible indication in 
> the 486 response and the forking proxies.
> 
> The issue is following - consider an INVITE from A to AOR-B that gets 
> forked by a proxy to AOR-C and AOR-D. If any of the targets AOR-C and 
> AOR-D is busy the possible CCBS possible indication in any of the 486 
> responses will not survive the response aggregation in proxy and will 
> not make it's way to the A. Let's call this scenario A) proxy with no 
> monitor forking to foreign AORs.

If I understand, you are assuming there is no monitor for B but there 
might be a monitor for C and/or D. Right?

[DA] Yes.

> In my opinion there is no issues, as there is no possible way to make 
> such a scenario function fair, so there is not problem is the CC
service 
> will not function in this case at all.

This is a HERFP problem. There is current work ongoing to define a 199 
response to indicate when a candidate dialog has been abandoned. It is 
not trying to solve the general HERFP problem, but it could certainly 
solve *this* problem if the B-proxy passed the cc indicator from 
downstream back in the 199 response. It however might mean that A would 
have to subscribe to completion at both C and D.

[DA] What I was meaning by saying "it is not a problem" was that the CC
service can still be useful even if the scenario A will not function. If
in future there will be solution for this scenario - great, but at the
moment the service is fine even with this limitation.

> In the following scenarios the assumption is that there are no proxies

> from the scenario A) preceding the acting proxy. If there are any than

> the scenario A) applies.

> Consider an INVITE from A to AOR-B that gets forked by the proxy with 
> monitor to the Contact-B and AOR-C. If the Contact-B is busy and AOR-C

> is ringing, the 486 and 180 responses get aggregated to 180 with no 
> CCNR.

I don't understand the above statement. You shouldn't aggregate a 
provisional response and a final response. Either the 486 is buffered so

that later a decision can be made of which final response to return, or 
else I guess the decision can be made that the 486 response will *never*

be returned - that the final response to be returned will be whatever 
final response is returned by the leg that has returned the 180. (But 
that would be unwise - in spite of the 180, the final response from that

leg may turn out to be worse than a 486.)

[DA] I did not mean that 180 will be the last (final) response from
AOR-C, obviously there will be some truly final response coming. I was
trying to show the aggregation result during the phase while there are
only two responses available 180 and 486. Correct me if I'm wrong, but
from my understanding forking proxy will not wait until all final
responses have come to propagate the aggregated response to the
preceding entity, but will also propagate the provisional responses.
Otherwise there will be period of silence on the A side for the duration
of the ringing phase at the at least one of the targets.

> If both Contact-B and AOR-C are busy the proxy with the monitor 
> will provide the 486 with CCBS possible indication monitoring the
status 
> of the Contact-B. If Contact-B is ringing than independent from the 
> state of the AOR-C the proxy with the monitor will provide the 180
with 
> the CCNR possible indication.
> 
> Let's call this scenario B) proxy with monitor forking to local
contacts 
> and foreign AORs
> 
> Scenario C) would be proxy with monitor forking to local contacts
only. 
> This is where the local policy for the aggregation and generation of
the 
> CC possible indication would apply.
> 
> To sum-up - the scenario B and C will function properly, the scenario
A 
> will not function, but this is acceptable from my point of view as the

> A) scenario is not the common case.
> 
> This all means that we do not have to do anything special to support
the 
> transport of 486 or 180 messages carrying the CC possible indication 
> from B to A.

IMO the potential application of 199 to this use case ought to be 
considered. It could however be postponed in order to decouple this work

from the 199 work.

[DA] It was not my intention to abandon the 199 work. My intention was
to say that the service is still very applicable even in the absence of
the 199, as the problem scenarios in my opinion are not very common to
make the service unusable.

Greetings,
Denis

	
_______________________________________________
BLISS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bliss