Hi all,

Dale is right, in the case the originating or destination local exchange do not support the retain option according to the SS7 procedure they will terminate the TCAP connection ba sending TC-END. This means without the 'retain supported' indication in the SUBSCRIBE the only problem that could occur is the case where a PSTN user activates CC on the SIP side and the OLE does not support retain. If there is now a error at the OLE and the PSTN does not send the TC-END, the queue entry would be retained at the monitor and there would be some service depriciation. But this will occur only in very few error cases, which become even fewer as in practise all PSTN exchanges do support the retain option.


So as we have covered all major usecases, also the error ones where there is a misunderstanding between originating and terminating side regarding the support of the retain option, and only very few errors on PSTN side could lead to a not optimal executing of CC (it will work nevertheless), I think we can close the retain option issue.

Best regards, Martin



 

> -----Ursprüngliche Nachricht-----
> Von: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] 
> Im Auftrag von WORLEY, Dale R (Dale)
> Gesendet: Sonntag, 11. Juli 2010 21:39
> An: bliss@ietf.org
> Betreff: [BLISS] Call-completion open issue 1009: The 'retain' option
> 
> 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
> BLISS@ietf.org
> https://www.ietf.org/mailman/listinfo/bliss
>