In SS-7, there is a 'retain' option for CCNR and CCBS. The default mode of operation is "retain = false", in which if the CC call fails, the CC request is removed from the queue anyway. (If the caller wants further CC services, he has to re-invoke CC.) In the "retain = true" mode, if the CC call fails, the CC request remains in the queue.
The originating an destination ends of the call negotiate whether retain will be in effect or not by sending indicators: The CC request (the TC-BEGIN CCBS REQUEST) carries a binary indicator stating whether the originating side supports retain, and the response to the CC request carries a binary indicator which is the AND of the request indicator and whether the destination side supports retain. The response indicator is true only if both sides support retain, and it determines whether this CC request will operate in retain mode or not. There is an open question of how SIP CC will support the retain option. The difficulty seems to be that people generally want to use retain, but its deployment is not universal, so its use must be negotiated. The rest of this message assumes that SIP CC is operating in the "SS-7 to SIP to SS-7" double gateway scenario, which places the strictest requirements on interoperability. However, looking at the diagram of a failed CCBS call in the ITU specification (Q.733.3, figure 3-7 in http://www.itu.int/ITU-T/recommendations/fl.aspx?id=4063 then click on the "Editions" tag then download the PDF), it seems to me that we can have SIP CC assume that retain is always in effect. The reasons are: - If the destination side does not support retain, then immediately after the CCBS call fails, it will send TC-END to end the transaction that was started by the TC-BEGIN CCBS REQUEST. This transaction is gatewayed to/from the SIP CC subscription, so the destination gateway will terminate the SIP CC subscription, which will be gatewayed back to the originating SS-7 as a TC-END. - A similar process happens if the originating side does not support retain and the CCBS call fails -- the originating side must send a TC-END. See note 3 at the bottom of the figure, "The TC-END is sent from either DLE or OLE." and prose at 3.5.3.1.2(c). That is, if one side supports retain and erroneously thinks the other side does also, the non-supporting side will terminate the CC subscription immediately after a failed CCBS call, giving the correct operation across the networks. I am assuming here that the sending of TC-END happens promptly after the failed CCBS call, so the CC queue entry is removed from the queue before the callee becomes available again. Dale _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
