Difference between connect and continue?

What is the Difference between connect and continue?

Continue :

Continue is the process in which the SCP does not modify the b-party number. ( SCP does not add any prefix before b party number)

Connect :

Connect is the process in which the SCP modifies the b-party number. For example, ported numbers, short codes, etc. ( SCP will add some prefix before the B party number and route the calls)

Eg:- short code to long code conversion, International calls via LCR, IVR Calls, VMS Calls and etc…

==================

Continue : 

The CUE operation is used by the gsmSCF to instruct the gsmSSF to continue call handling. The CAMEL phase 1 BCSM has two places where CAP CUE may be used:

(1) In response to CAP IDP – the gsmSSF continues call handling with the available call-related information. That implies that an MO call is routed to the destination that is entered by the calling party.

(2) In response to DP disconnect when disconnect is reported in request mode – CAP CUE has the effect that the gsmSSF continues call clearing. That implies that the ISUP REL that caused the disconnect event is propagated towards the calling subscriber.

Connect :

The Connect (CON) operation may be used in response to CAP IDP. CAP CON enables the CAMEL service to define or modify specific parameters in the call flow. When the gsmSSF receives a call parameter in CAP CON, it replaces the available parameter in ISUP by the parameter that is received in CAP CON. The following call-related parameters may be provided with CAP CON. All parameters in CAP CON, except destination routing address are optional.

• Destination routing address – this parameter defines the destination of the call. If CAP CON is used to modify a call-related parameter such as CPC, but not to change the destination of the call, then the CAMEL service shall use a destination routing address that is equal to the called party BCD number (MO call) or called party number (MF, MT call) in CAP IDP. Whereas Called Party BCD Number is coded in accordance with GSM TS 04.08 [49], destination routing address is coded in accordance with ITU-T Q.763 [137].

• Calling Party’s Category (CPC) – the CPC serves as an indication of the type of calling party, such as normal subscriber, operator or payphone. A subscriber’s CPC is provisioned in HLR and sent to VLR during registration. It may be used to indicate the subscriber’s language preference within the HPLMN. CPC values are defined in ITU-T Q.763 [137]. Non-standard CPC values should normally be used in the HPLMN only.

• Generic number (GN) – GN is, as it name implies, a generic place holder for a number to be used in ISUP call signalling. The frame of a GN contains a number qualifier, which indicates what kind of number is contained in this parameter. ITU-T Q.763 [137] specifies generic numbers such as additional calling party number, additional called number, etc. CAMEL allows the use of GN in CAP CON only to define or modify the additional calling party number. The additional calling party number is often referred to as ‘GN6’, since it is contained in GN with number qualifier equal to 6. It would have been useful if CAMEL did not restrict the use of GN to GN6 only.

• O-CSI applicable – a CAMEL service may use this parameter when it creates an outgoing call from the GMSC, when handling an MT call. When this parameter is present in this call case, the GMSC shall use O-CSI, if available, for the outgoing call leg. For CAMEL phase 1, the SCP may create an outgoing call from the GMSC only as a direct response to CAP IDP. From CAMEL phase 2 onwards, the outgoing call may also be created in response to call establishment failure or after a disconnect event.

• Suppression of announcements (SoA) – this parameter may be used when the CAMEL service is controlling an MT call in the GMSC. Its use is to suppress announcements in GMSC or VMSC resulting from call establishment failure. This option would be used when the CAMEL service wants to use service-specific announcements (CAMEL phase 2 onwards) and hence suppress generic, network-generated announcements; see Figure 3.27. When SoA is present in CAP CON, it may suppress announcements for both call establishment failure in GMSC and call establishment failure in VMSC. GMSC stores SoA internally and includes SoA in the second MAP SRI. HLR includes SoA in MAP PRN to VLR, which also stores SoA. If GMSC receives a negative result from HLR in response to the second MAP SRI, then it uses the stored SoA to suppress the announcement that it may otherwise generate. If a call is routed to VMSC, but call establishment fails in VMSC, then the VMSC uses the stored SoA to suppress the announcement that it may otherwise generate. A CAMEL phase 2 service may use SoA for call hunting. The service uses a list of alternative destination addresses to connect an incoming call. Presuming that these alternative destination addresses are MSISDNs of the same PLMN, the serving GMSC may send the MAP SRI for the call attempts to these destinations and include SoA in the respective MAP SRIs. This requires, however, that the GMSC supports the transport of SoA over internal ISUP, which is not specified by CAMEL.

• Original called party ID – if the CAMEL service forwards the call, then it includes this parameter in CAP CON. If the call was already forwarded prior to arriving at the GMSC, then this parameter should already be present in the ISUP signalling. In that case, the CAMEL service should not overwrite this parameter.

• Redirecting party ID – the CAMEL service uses this parameter when applying call forwarding, even when the call was already forwarded prior to arriving at the GMSC. It should contain the MSISDN of the served subscriber, i.e. the subscriber on whose behalf the call is forwarded. It may, however, also contain a VPN number or other number.

• Redirection information – this parameter may be used when applying call forwarding; it contains a number of variables that define the forwarding case. The following variables are included:

• redirecting indicator, indicating the type of forwarding, such as call diversion or call rerouting; • original redirection reason, reflecting the reason for the first call forwarding for the call;

• redirection counter, indicating the number of forwardings that have taken place; when the SCP applies forwarding, it increases the value of this variable by 1;

• redirecting reason, indicating the forwarding reason, such as unconditional, busy or no reply. A gsmSSF may copy original called party ID, redirecting party ID and redirection information, when received in CAP CON, transparently to ISUP IAM for the outgoing call, without checking whether these parameters contain correct information related to the specific forwarding case. The CAMEL service therefore should take care to apply sensible information in these parameters.

Leave a Reply

Your email address will not be published. Required fields are marked *