You are here

Camel release

6 posts / 0 new
Last post
Camel release

Just simple question in CAMEL. Does CAMEL (SSP) will release the call if SCP issue TCAP-END without the component of camel release? Or how the SSP handle if TCAP-END is receive without the CAMEL released component? Any help would be appreciate. Thanks in advance.

Hi, some description could be


some description could be found in the 3GPP TS 29.078
Before you check it out please note this mapping between your naming and 3GPP TS:
SSP == gsmSSF
IN central control logic == gsmSCP

1) When shall SSP received "empty"(basic) TC-END. Check out the last chapter:

Services assumed from lower layers
Services assumed from TC
gsmSSF gsmSCF interfaces
Normal procedures
gsmSCF to gsmSSF messages

here is stated: "The dialogue shall no longer be maintained when the prearranged end condition is met in the gsmSCF. When the gsmSCF does not expect any messages other than possibly REJECT or ERROR messages for the operations sent and when the last associated operation timer expires, the dialogue is locally ended by means of a TC END request primitive with prearranged end.
Alternatively, the sending of operations, leading to the termination of the relationship, by means of a TC END request primitive (basic end) is possible."

2) How shall SSP process TC-END. Again check out the last chapter:

Services assumed from lower layers
Services assumed from TC
Common procedures
Dialogue handling
Dialogue termination

here is stated:
"Receipt of a TC END indication
On receipt of a TC END indication primitive, the TC USER shall accept any component handling indication primitives and process them as described in subclause
After processing the last component handling primitive all dialogue related resources are released."

So likely you had this situation: IN node did not expect any other activities related to the call handling and it terminated dialogue with SSP(gsmSSF). Since there is no component - we are talking about basic TC-END - SSP shall terminate the dialogue too. Further call handling is in the hands of SSP - you shall check CAMEL subscription data. Something about this is again in this TS:

Circuit switched Call Control
Description of CAMEL Subscriber Data

Check out the setting for "Default Call handling" for given type of call.

Hope this helps...

Camel release

You have helped me a lot. Thanks TomiZet!

 Hi All,I would like to ask a

 Hi All,I would like to ask a related qurery.I am getting CAP Release from gsmSCF with ReleaseCause: Normal Unspecified (31)As per the gsmSCF vendor, they have identified that the ACN is wrong:TCAP-BEGIN:- application-context-name: (CAP-v1-gsmSSF-to-gsmSCF-AC)But, isn't that if ACN would have been wrong, then we would have got TCAP ABORT and not CAP RC?I would like to hear your views. Thanks in advance!BR//sama

Hi Sama,given ACN is correct

Hi Sama,given ACN is correct CAPv1 ACN - see this discussion thread for more details [url][/url]. So your vendor is not correct - you are providing correct ACN. And yep in case their node does not support ACN of this CAP version they should ABORT transaction with abort reason "ACN not supported" which might lead to CAP version negotiation. But again if they do not support CAPv1 there is nothing to negotiate. This negotiation is meant to provide backward compatibility of newer CAP implementation with older ones - not the other way round.For CAPv3 you find description of abnormal handling of TC-BEGIN this way:download from this version of TS: 3GPP TS 29.078 V4.9.0go to this head:[list][*]12      Services assumed from lower layers[*]12.1    Services assumed from TC[*]12.1.1    Common procedures[*]    Dialogue handling[*]    Dialogue establishment -> here check out the section "Receipt of a TC BEGIN indication"[/list]There is stated: "If the application-context-name included in the primitive is not supported, issue a TC-U-ABORT request primitive"Similarly you can chek it also for other CAP versions..

Thanks TomiZet!

Thanks TomiZet! for the detailed explanation.

Just to inform you that the vendor's SCF was actually not supporting the capV1 messages and at the same time was not issuing any 'ABORT' messages because of which there were confusions. Now its cleared.