You are here

CAP4 ContinueWithArguments and InitiateCallAttempts

5 posts / 0 new
Last post
CAP4 ContinueWithArguments and InitiateCallAttempts

CWA has a parameter called "Call Diversion Treatment Indicator" within "Forward Service Interaction Indicator". With this parameter we can disable GSM call forwarding/diversion.

My question is - i'm sending CWA along with RRB (T_BUSY, T_NOANS ...) to the SSF.

Now, if the called party is found busy and SCP get T_BUSY. I want to send CAP CUE to SSF and now want if there is some GSM forwarding enabled for B party, that was disabled earlier by CWA, to happen now.

Will this happen if CUE is sent?


Praveen, What do I understand

What do I understand with your question:
You are sending CWA along with "Call Diversion Treatment Indicator, Forward Service Interaction Indicator" set to "callDiversionNotAllowed". Then you expect - regardless if SS CF is provisioned for a given subscriber, regardless if potential early or late CF could happen - CF is not occurring and your application gets notified with ERB tBusy. When it happens you change your mind and want to challenge the called party again allowing potential SS CF to be applied.

1. If you send CUE in response to ERB tBusy, as you suggest in your post, you will allow the ISUP REL to propagate in backward direction. The call would get released.
2. Instead, you should replace the leg with new one - now your CWA/CON shall not restrict SS CF.

Supportive info, and "numbers":
1. according to 23.078
Once the SCP force the "callDiversionNotAllowed" with CWA/CONNECT, it is propagated on following application interfaces:
MSC-VLR Send Info For Incoming Call

2. According to 29.078
CAP "ServiceInteractionIndicators, call diversion not allowed" is mapped to ISUP IAM "Call to be diverted indicator, call diversion not allowed".

Regarding suppression of SS CF, you can consider:
1. Call Diversion Treatment Indicator, Forward Service Interaction Indicator set to "callDiversionNotAllowed" directly in your service, let’s say in GMSC
2. If it cannot ensure proper behaviour in TVMSC - you could add Vt-CSI so to repeat the Call Diversion Treatment Indicator, Forward Service Interaction Indicator set to "callDiversionNotAllowed" - e.g. if ISUP version is not supporting this feature
3. you could refer to old good times when those issues were solved with simple approach - the redirection counter. You can set it to the maximum value - I am sure you saw it earlier.
4. If you still experience problems - it is definitely the case to raise the trouble report to 3GPP

Diversion first disallowed, then allowed

Thanks a lot for details.

So, as i understand, the callDiversionNotAllowed will be mapped to ISUP.

The reason of first restriction on CF was to get the busy/no_ans indication in the service in which this leg is created through ICA. Now, in ICA, i can receive these indications as O_BUSY/O_NOANS, but if late forwarding is active on the B number (on which ICA was done) then to get the trigger, we need to suppress late call forwardings. When i send callDiversionNotAllowed indication through CWA, will it also restrict late forwarding?

and suppose it restricts, then can i again enable it by sending another CWA (after getting the events busy/no_ans) and again allow late CF?
At what point is this information copied to ISUP?

Much Regards

Late CF re-enabling

Went through your answer again in the recommendations and 29.078 (rel 5 - CAP4) does say that forwardCallIndicator is copied to IAM. Since my service BCSM is on GMSC, GMSC forwards the call to VMSC. I think when i'm specifying the forwardCallIndicator, it will be copied to this ISUP IAM that flows from GMSC to VMSC.

When Busy/NoAns event will happen, it will be first hit at VMSC. VMSC since have all-CF forbidden due to callForwardIndicator sent earlier in IAM, would now send REL back to GMSC with cause code corresponding to eventType.

Since call is now vanished from VMSC, we need to send the ICA, RRB, CWA again to GMSC for B party and this time CWA should have forwardingEnabled (or may not at all include this parameter).
This time, we won't get late forwarding indicator, but if there is ANY forwarding, it will happen.

However even now there is a problem (business flow wise):
1. B party will be dialled again so will get the ringing again (especialy when earlier call was released due to no_answer).
2. No Answer timer will start again and A party have to wait for 30 more seconds!! perhaps we can reduce no_answer time in RRB in this second ICA+RRB+CWA.

What do you say about these?


Praveen, I do not understand

I do not understand the business logic well, but to answer your doubts:
You may perform the IN induced CF - your service logic can learn what is FTN and redirect the call to FTN on tBusy/tNoAnswer.

How to know FTN?
2. ForwardingDestinationNumber in ERB in case of CF notification - in this case you need to monitor the call with VT-CSI as well.
3. Provisioning - provisioning can be sent both to HLR and IN platform
5. combination of MAP ATSI/ATM/NSDC, e.g. you can completely move the redirection control to IN plarform for your subscribers
6. probably more solution exists