This is a problem that we've been discussing on the Call Completion
mailing list and we would like to put it in front of the entire Bliss
mailing list for people to suggest solutions.
The problem runs:
(To simplify,) once an initial caller has made a call to a UAS that
has failed, the caller sends a SUBSCRIBE ("the CC subscribe") to a
particular UAS to state its desire to make a CC call, and to receive
notice of when it should make its CC re-call. (Currently, the
expectation is that the CC subscribe will be made to the same URI as
the original call. It might be possible to change that, but that
turns out to involve the same technical problem described below.)
Because a CC subscribe displays busy/not-busy information about the
callee without itself making an INVITE to the callee, in order to
protect privacy, we don't want to allow UAs to arbitrarily perform CC
subscribes -- they have to present identification of a previous call
that they have made to that destination, thus ensuring that the callee
is aware of the caller's interest.
Some UAC callees are nearly memory-less. (In particular, constellations
of gateways that bridge from SS7 networks to SIP networks.) Thus, the
only information that can be carried reliably from the destination of
the (failed) original call to the CC subscription and the CC recall is
the "mode" (CCBS vs. CCNR), because that is carried back into the SS7
network and is carried forward in the SS7 CC operations.
This means that the "identification" that we require of the CC
subscribe must be some aspect of the original call; it cannot be a
datum from the response to the original call (because a memoryless UAC
cannot remember the datum).
This means that any call to which CC can be applied later must bear
some sort of identification which will later be carried in the CC
subscribe and CC recall. This would be straightforward -- just use
the Call-Id -- except that calls frequently pass through SBCs or
B2BUAs that change the Call-Id.
Let us examine what might be used for identification:
There are two sorts of data that an INVITE carries. The first sort is
data about the nature of the call (To, From, etc.). Because it is
relatively easy to guess, this data is not suitable for CC
identification. The second sort is pseudo-random data used to
identify the call (Call-Id, to-tag, from-tag). By its very nature,
SBCs feel free to change the second sort of data when passing a call
through, so the UAC and UAS do not necessarily see the same values of
these data.
One alternative is to add a new header with a pseudo-random value, and
expect that SBCs will not change it. (And hope that SBCs will pass it
through, which is plausible.) But in order to reduce the burden on
the UASs and the network, we don't want to add an additional CC
identifier to every call that is generated, but it appears that we
have to to get calls reliably identified for CC.
Dale
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
