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

From: "Alexeitsev, D" <[email-masked]>
Date: Mon, 16 Jun 2008 15:46:04 +0200

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.

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.

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

Comments, questions?

Greetings,
Denis

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Jun 2008 11:57:01 -0400

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

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

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

> If both Contact-B and AOR-C are busy the proxy with the monitor 

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.

	Thanks,
	Paul

> Comments, questions?
> 
> Greetings,
> Denis
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
>

---

From: [email-masked]
Date: Wed, 18 Jun 2008 18:35:08 -0400

From: "Alexeitsev, D" <[email-masked]>

I don't know why you say this, as the initial text I provided for the
I-D was deliberately constructed so as to make this case work.

The crucial features of a solution to this problem are:

1) The caller may attempt CC without receiving a "CC possible"
   indication in the failure of the original call.  If CC is not
   possible, the caller will discover it in the failure of (all forks
   of) the CC SUBSCRIBE.

2) The caller sends the CC SUBSCRIBE to the *same request-URI* as the
   original call.  In almost all cases, this will result in the
   SUBSCRIBE reaching all monitors which might allow CC subscription
   for the original call.  (The caller should also directly subscribe
   to any monitors that it learns of in "CC possible" indications of
   provisional and final responses.)

Dale