SIST EN 302 039-2 V1.1.2:2005
(Main)Intelligent Network (IN); Intelligent Network Capability Set 4 (CS4); Intelligent Network Application Protocol (INAP); Protocol specification; Part 2: Service Switching Function - Switching Control Function (SSF-SCF) Interface
Intelligent Network (IN); Intelligent Network Capability Set 4 (CS4); Intelligent Network Application Protocol (INAP); Protocol specification; Part 2: Service Switching Function - Switching Control Function (SSF-SCF) Interface
To specify the ETSI version of ITU IN CS4 Recommendation.
Inteligentno omrežje (IN) – Četrti nabor zmožnosti inteligentnega omrežja (CS4) – Aplikacijski protokol inteligentnega omrežja (INAP) – Specifikacija protokola – 2. del: Vmesnik funkcija komutacije storitev-funkcija krmiljenja storitev (SCF-SSF)
General Information
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Intelligent Network (IN); Intelligent Network Capability Set 4 (CS4); Intelligent Network Application Protocol (INAP); Protocol specification; Part 2: Service Switching Function - Switching Control Function (SSF-SCF) Interface33.040.35Telefonska omrežjaTelephone networksICS:Ta slovenski standard je istoveten z:EN 302 039-2 Version 1.1.2SIST EN 302 039-2 V1.1.2:2005en01-januar-2005SIST EN 302 039-2 V1.1.2:2005SLOVENSKI
STANDARD
SIST EN 302 039-2 V1.1.2:2005
ETSI EN 302 039-2 V1.1.2 (2002-11)European Standard (Telecommunications series) Intelligent Network (IN);Intelligent Network Capability Set 4 (CS4);Intelligent Network Application Protocol (INAP);Protocol specification;Part 2: Service Switching Function -Switching Control Function (SSF-SCF) Interface
SIST EN 302 039-2 V1.1.2:2005
ETSI ETSI EN 302 039-2 V1.1.2 (2002-11) 2
Reference DEN/SPAN-120065-2 Keywords CS4, IN, INAP, protocol ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00
Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88
Important notice Individual copies of the present document can be downloaded from: http://www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp If you find errors in the present document, send your comment to: editor@etsi.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2002. All rights reserved.
DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members. TIPHONTM and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. SIST EN 302 039-2 V1.1.2:2005
ETSI ETSI EN 302 039-2 V1.1.2 (2002-11) 3
Contents Intellectual Property Rights.4 Foreword.4 1 Scope.5 2 References.5 3 Abbreviations.6 4 Operation procedures.6 4.1 Modified operations.6 4.1.1 Connect.6 4.1.2 ContinueWithArgument.6 4.1.3 InitialDP.6 4.1.4 InitiateCallAttempt.6 4.1.5 MergeCallSegments.7 4.1.6 MoveLeg.7 4.1.7 SelectFacility.7 4.1.8 SplitLeg.7 4.2 New operations.7 4.2.1 CallFiltering procedure.7 4.2.1.1 General description.7 4.2.1.2 Argument Parameters.7 4.2.1.3 Invoking entity (SCF).8 4.2.1.3.1 Normal procedure.8 4.2.1.3.2 Error handling.8 4.2.1.4 Responding entity (SSF).8 4.2.1.4.1 Normal procedure.8 4.2.1.4.2 Error handling.8 5 Parameter descriptions.9 5.1 DetachSignallingPath.9 5.2 DestinationIndex.9 5.3 ExportSignallingPath.9 5.4 IncomingSignallingBufferCopy.9 5.5 IPRelatedInformation.9 5.6 MergeSignallingPaths.10 6 ASN.1 definitions.10 6.1 Data Types.10 6.2 Classes.35 6.3 Operations and Arguments.39 6.4 Operation timers.62 6.5 Packages, contracts, application contexts and abstract syntaxes.63 6.5.1 ASN.1 modules.63 6.5.2 Packages.70 6.5.3 Abstract Syntaxes.73 Annex A (informative): Bibliography.79 History.80
SIST EN 302 039-2 V1.1.2:2005
ETSI ETSI EN 302 039-2 V1.1.2 (2002-11) 4
Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http://webapp.etsi.org/IPR/home.asp). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This European Standard (Telecommunications series) has been produced by ETSI Technical Committee Services and Protocols for Advanced Networks (SPAN). The present document is part 2 of a multi-part deliverable covering Intelligent Network (IN); Intelligence Network Capability Set 4 (CS4); Intelligent Network Application Protocol (INAP); Protocol specification, as identified below: Part 1: "Common aspects"; Part 2: "Service Switching Function - Switching Control Function (SSF-SCF) Interface". The present document describes the enhancement for SSF-SCF interface. The present document and EN 302 039-1 [1] define the Intelligent Network (IN) Application Protocol (INAP) for IN Capability Set-4 based and written as delta documents upon ETSI Core INAP CS-3 (EN 301 931-1 [2] and EN 301 931-2 [3]). This set of documents define enhancements made on the SSF to SCF interface (the present document) as a subset of the ITU-T IN CS4 Recommendations Q.1248.1 [10], Q.1248.2 [11]. For the other interfaces, the ETSI Core INAP CS3 series of EN 301 931 [2] and [3] apply.
National transposition dates Date of adoption of this EN: 15 November 2002 Date of latest announcement of this EN (doa): 28 February 2003 Date of latest publication of new National Standard or endorsement of this EN (dop/e):
31 August 2003 Date of withdrawal of any conflicting National Standard (dow): 31 August 2003
SIST EN 302 039-2 V1.1.2:2005
ETSI ETSI EN 302 039-2 V1.1.2 (2002-11) 5
1 Scope The present document specifies the protocol enhancements on the SSF-SCF interface for IN CS4. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. • References are either specific (identified by date of publication and/or edition number or version number) or non-specific. • For a specific reference, subsequent revisions do not apply. • For a non-specific reference, the latest version applies. [1] ETSI EN 302 039-1: "Intelligent Network (IN); Intelligent Network Capability Set 4 (CS4); Intelligent Network Application Protocol (INAP); Protocol specification; Part 1: Common aspects". [2] ETSI EN 301 931-1: "Intelligent Network (IN); Intelligent Network Capability Set 3 (CS3); Intelligent Network Application Protocol (INAP); Protocol specification; Part 1: Common aspects". [3] ETSI EN 301 931-2: "Intelligent Network (IN); Intelligent Network Capability Set 3 (CS3); Intelligent Network Application Protocol (INAP); Protocol specification; Part 2: SCF-SSF interface". [4] ETSI EN 301 931-3: "Intelligent Network (IN); Intelligent Network Capability Set 3 (CS3); Intelligent Network Application Protocol (INAP); Protocol specification; Part 3: SCF-SRF interface ". [5] ETSI TS 122 024:"Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Description of Charge Advice Information (CAI) (3GPP TS 22.024)". [6] ETSI EN 301 070-1: "Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 3 interactions with the Intelligent Network Application Part (INAP);
Part 1: Protocol specification [ITU-T Recommendation Q.1600 (1997), modified]". [7] ESTI TS 123 040: "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Technical realization of the Short Message Service (SMS) (3GPP TS 23.040)". [8] ITU-T Recommendation E.410: "International network management - General information". [9] ITU-T Recommendation Q.1236: "Intelligent Network Capability Set 3 - Management Information Model Requirements and Methodology". [10] ITU-T Recommendation Q.1248.1: "Interface recommendation for Intelligent Network Capability Set 4: Interface Recommendation for Intelligent Network Capability Set 4 - Common aspects". [11] ITU-T Recommendation Q.1248.2: " Interface recommendation for Intelligent Network Capability Set 4: SCF-SSF Interface". [12] ITU-T Recommendation H.323: "Packet-based multimedia communications systems". [13] ITU-T Recommendation H.450.3: "Call diversion supplementary service for H.323". [14] ITU-T Recommendation Q.763: "Signalling System No. 7 - ISDN User Part formats and codes". SIST EN 302 039-2 V1.1.2:2005
ETSI ETSI EN 302 039-2 V1.1.2 (2002-11) 6
[15] ITU-T Recommendation Q.850: "Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN User Part". [16] ITU-T Recommendation Q.735.1: "Stage 3 description for community of interest supplementary services using Signalling System No. 7: Closed user group (CUG)". [17] ITU-T Recommendation Q.931: "ISDN user-network interface layer 3 specification for basic call control". [18] ITU-T Recommendation Q.713: "Signalling connection control part formats and codes". [19] ITU-T Recommendation Q.1601: "Signalling system No. 7 - Interaction between N-ISDN and INAP CS2". [20] ITU-T Recommendation Q.1238: "Interface Recommendation for intelligent network capability set 3". 3 Abbreviations For the purposes of the present document, the abbreviations given in EN 301 931-1 [2] apply. 4 Operation procedures EN 301 931-2 [3], clause 11 is applicable with the enhancements specified in the present document.
4.1 Modified operations The following operations defined in EN 301 931-2 [3] are modified by the present document. 4.1.1 Connect The following parameter defined in clause 5 is added to the operation argument: - IpRelatedInformation. Existing cug-Interlock and cug-OutgoingAcces parameters are no longer restricted for the support of CAMEL. 4.1.2 ContinueWithArgument The following parameter defined in clause 5 is added to the operation argument: - ipRelatedInformation. 4.1.3 InitialDP The following parameter defined in clause 5 is added to the operation argument: - ipRelatedInformation. 4.1.4 InitiateCallAttempt The following parameters defined in clause 5 are added to the operation argument: - incomingSignallingBufferCopy. - ipRelatedInformation. SIST EN 302 039-2 V1.1.2:2005
ETSI ETSI EN 302 039-2 V1.1.2 (2002-11) 7
4.1.5 MergeCallSegments The following parameter defined in clause 5 is added to the operation argument: - mergeSignallingPaths. 4.1.6 MoveLeg The following parameters defined in clause 5 are added to the operation argument: - detachSignallingPath. - exportSignallingPath. 4.1.7 SelectFacility The following parameter defined in clause 5 is added to the operation argument: - ipRelatedInformation. 4.1.8 SplitLeg The following parameter defined in clause 5 is added to the operation argument: - detachSignallingPath. 4.2 New operations The following new operation is defined by the present document. 4.2.1 CallFiltering procedure 4.2.1.1 General description The CallFiltering operation is used to allow the SCF to influence basic call gapping procedures based in the CCF by sending information from the SCF to the SSF. The SSF relays the received information transparently to the CCF. This way, the SCF can influence the rate at which call attempts are allowed through. The operation thus influences the filtering of calls, as opposed to service requests as is done by the Callgap operation. 4.2.1.2 Argument Parameters The operation argument consists of the following parameters. These parameters are defined in clause 13. - destination Index This index is a pointer to the Destination (see ITU-T Recommendation E.410 [8]) to which calls are filtered. - gapIndicators The parameter contains the gapDuration and the gapInterval. - registratorIdentifier This parameter identifies the SCF and is to be used by the SSF to verify that the SCF is allowed to influence CCF-based call gapping procedures. - extensions SIST EN 302 039-2 V1.1.2:2005
ETSI ETSI EN 302 039-2 V1.1.2 (2002-11) 8
4.2.1.3 Invoking entity (SCF) 4.2.1.3.1 Normal procedure SCF precondition: 1) The SCF receives an indication from the SMF an overload condition persists and callfiltering has to be initiated at the SSF. SCF postcondition: 1) The SCME is in the state "idle". If the congestion level changes new "CallFIltering" operations may be sent for active filter criteria but with a new filter interval. If the congestion situation has ended, the filtering criteria may be removed. 4.2.1.3.2 Error handling Generic error handling for the operation related error are described in clause 13 of EN 301 931-2 [3] and the TCAP services which are used for reporting operation errors as described in clause 10 of EN 301 931-1 [2]. 4.2.1.4 Responding entity (SSF) 4.2.1.4.1 Normal procedure SSF precondition: 1) None. SSF postcondition: 1) SSME-FSM is in the state "Idle". The SSF relays the received information transparently to the CCF-based call filtering process. In case callfiltering to the specific destinations is already active at the CCF, than the new gapIndicator parameter overwrites the existing parameter values.
A manual initiated call filter will prevail over an automatic initiated call filter. If a call matches several destinationIndexes, then the control corresponding with the most specific destinationIndex should be applied. The service request gap process is stopped if the indicated duration equals zero. 4.2.1.4.2 Error handling Generic error handling for the operation related error are described in clause 13 of EN 301 931-2 [3] and the TCAP services which are used for reporting operation errors as described in clause 10 of EN 301 931-1 [2]. NOTE:
In case of error (i.e. invalid registrator identifier), a TaskRefused error is returned. SIST EN 302 039-2 V1.1.2:2005
ETSI ETSI EN 302 039-2 V1.1.2 (2002-11) 9
5 Parameter descriptions EN 301 931-2 [3], clause 12 is applicable with the enhancements of the new following parameters specified in the present document. 5.1 DetachSignallingPath This indicator is used in the argument of CPH operations. It tells the CCF whether the signalling path between the Signalling Termination represented by an exported leg and the Signalling Terminations represented by the other legs should be broken or not. When this parameter is absent, the behaviour of the CCF is implementation dependent. 5.2 DestinationIndex This parameter contains a pointer to a call destination (see ITU-T Recommendation E.410 [8]). 5.3 ExportSignallingPath This indicator is used by the MoveLeg procedure. It tells the CCF whether the signalling path between the Signalling Termination represented by the exported leg and the Signalling Terminations represented by the other legs of the target CS should be impacted or not. If the parameter is absent, the behaviour of the CCF is implementation dependent. The detailed impact is outside the scope of the present document and should not be specified in the present document. 5.4 IncomingSignallingBufferCopy This indicator is used in the InitiateCallAttempt procedure. When present, the parameters of the setup.ind primitive sent by the CCF should be populated with the information received in the operation argument and in the setup.req primitive from the Signalling Termination associated with the joined controlling leg (if any) of the call segment association. If this indicator is absent, the parameters of the setup.ind primitive sent by the CCF will be populated with the information received in the operation argument and some locally defined information as defined in ITU-T Recommendation Q.1236 [9]. 5.5 IPRelatedInformation IPRelatedInformation: This parameter contains a number of sub-parameters that are specific to the interworking with IP-based networks. Currently available sub-parameters are: - alternativeCalledPartyIds: one or more identities representing a destination in the form of a valid URL. The mapping on call signalling parameters is protocol dependent.
NOTE 1:
In SIP environments, such identities are represented as SIP URLs, mapped to the "To:" field. In ITU-T Recommendation H.323 [12] environments, such identities are represented as alias addresses, mapped to the destinationAddress field. -
alternativeOriginatingPartyIds: one or more identities representing an originating party in the form of a valid. The mapping on call signalling parameters is protocol dependent.
NOTE 2:
In SIP environments, such identities are represented as SIP URLs mapped to the "From:" field. In ITU-T Recommendation H.323 [12] environments, such identities are represented as alias addresses, mapped to the sourceAddress field. - alternativeOriginalCalledPartyIds: one or more identities representing the original destination of a forwarded call, in the form of a valid URL. The mapping on call signalling parameters is protocol dependent.
SIST EN 302 039-2 V1.1.2:2005
ETSI ETSI EN 302 039-2 V1.1.2 (2002-11) 10 NOTE 3:
In SIP environments, such identities may be represented as SIP URLs, mapped to the "Record-route:" field. In ITU-T Recommendation H.323 [12] environments, such identities are represented as alias addresses, mapped to the ITU-T Recommendation H.450.3 [13] parameters. - alternativeRedirectingPartyIds: one or more identities representing a redirecting party, in the form of a valid URL. The mapping on call signalling parameters is protocol dependent.
NOTE 4:
In SIP environments, such identities may be represented as SIP URLs mapped to the "Record-route:" field. In ITU-T Recommendation H.323 [12] environments, such identities are represented as alias addresses, mapped to the ITU-T Recommendation H.450.3 [13] parameters. 5.6 MergeSignallingPaths This indicator is used by the MergeCallSegment procedure. It tells the CCF whether the signalling path between the Signalling Termination represented by the imported legs and the Signalling Terminations represented by the other legs of the target CS should be impacted or not. If the parameter is absent, the behaviour of the CCF is implementation dependent. The detailed impact is outside the scope of the present document and should be specified in the present document. 6 ASN.1 definitions 6.1 Data Types -- The Definition of SSF – SCF
Data Types Follows
IN-SSF-SCF-datatypes {itu-t(0) identified-organization(4) etsi(0) inDomain(1) in-network(1) cs4(40) modules(1) in-ssf-scf-datatypes(6) version1(0)}
DEFINITIONS IMPLICIT TAGS::=
BEGIN IMPORTS
common-classes,
common-datatypes,
ssf-scf-classes,
scf-srf-classes,
scf-srf-datatypes,
tc-Messages
FROM IN-object-identifiers {itu-t(0) identified-organization(4) etsi(0) inDomain(1) in-network(1) cs4(40) modules(1) in-object-identifiers(0) version1(0)}
COMMON-BOUNDS FROM IN-common-classes common-classes
TRIGGER,
SCF-SSF-BOUNDS FROM IN-SSF-SCF-Classes ssf-scf-classes
SCF-SRF-BOUNDS FROM IN-CS3-scf-srf-classes scf-srf-classes
Extensions{},
Integer4 FROM IN-common-datatypes common-datatypes
InformationToSend {}
FROM IN-CS3-scf-srf-datatypes scf-srf-datatypes
AddOnChargingInformation,
ChargingTariffInformation,
ChargingMessageType FROM Tariffing-DataTypes {itu-t(0) identified-organization etsi (0) 1296 version2(3)}
SIST EN 302 039-2 V1.1.2:2005
ETSI ETSI EN 302 039-2 V1.1.2 (2002-11) 11
ISDN-AddressString FROM MAP-CommonDataTypes {itu-t(0) identified-organization(4) etsi(0) mobileDomain(0) gsm-Network(1) modules(3) map-CommonDataTypes(18) version6(6)} ;-- The following three definitions are local short-hand notation for convenience. B1::= COMMON-BOUNDS
-- defined in part 1 B2::= SCF-SSF-BOUNDS
-- defined herein. B3::= SCF-SRFBOUNDS
-- defined in EN 301 931-3.
AChBillingChargingCharacteristics {B2: b2} ::= OCTET STRING (SIZE
(b2.&minAChBillingChargingLength.b2.&maxAChBillingChargingLength)) -- The AChBillingChargingCharacteristics parameter specifies charging related information. -- Its content is network operator specific. -- The internal structure of this parameter can be defined using ASN.1 and the related Basic -- Encoding Rules (BER). In such a case the value of this parameter (after the first tag and length -- information) is the BER encoding of the defined ASN.1 internal structure. -- The tag of this parameter as defined by ETSI is never replaced. -- CAMEL: -- AChBillingChargingCharacteristics {PARAMETERS-BOUND: bound}::= OCTET STRING (SIZE -- (bound.&minAChBillingChargingLength.bound.&maxAChBillingChargingLength)) -- (CONSTRAINED BY { -- shall be the result of the BER-encoded value of the type -- -- CAMEL-AchBillingChargingCharacteristics {bound}}) -- The AChBillingChargingCharacteristics parameter specifies the charging related information -- to be provided by the gsmSSF and the conditions on which this information has to be reported -- back to the gsmSCF with the ApplyChargingReport operation. The value of the
-- AchBillingChargingCharacteristics of type OCTET STRING carries a value of
-- the ASN.1 data type: CAMEL-AchBillingChargingCharacteristics.
-- The normal encoding rules are used to encode this value. -- The violation of the UserDefinedConstraint shall be handled as an ASN.1 syntax error.
AChChargingAddress {B2: b2} ::= CHOICE {
legID
[2]
LegID,
srfCallSegment [50] CallSegmentID {b2},
bNCF
[51] LegID }
ActionIndicator ::= ENUMERATED {
activate
(1),
deactivate
(2),
retrieve
(3)
} -- indicates the action to be performed by the ManageTriggerData operation.
ActionOnProfile::= ENUMERATED {
activate
(0),
deactivate
(1)
} -- indicates the action to be performed by the SetServiceProfile operation.
ActionPerformed ::= ENUMERATED {
activated
(1),
deactivated
(2),
alreadyActive (3),
alreadyInactive (4),
isActive
(5),
isInactive
(6),
tDPunknown
(7)
} -- indicates the result of the operation ManageTriggerData
AdditionalCallingPartyNumber
{B2: b2}::= Digits {b2} -- Indicates the Additional Calling Party Number.
Refer to ITU-T Recommendation Q.763
-- Generic Number for encoding.
AlertingPattern::= OCTET STRING (SIZE(3)) -- Indicates a specific pattern that is used to alert a subscriber
-- (e.g. distinctive ringing, tones, etc.).
-- Only the trailing OCTET is used, the remaining OCTETS should be sent as NULL (zero) -- The receiving side ignores the leading two OCTETS. -- Only applies if SSF is the terminating local exchange for the subscriber. -- Refer to the ITU-T Recommendation Q.931
Signal parameter
-- respective TS 129 002 for encoding.
SIST EN 302 039-2 V1.1.2:2005
ETSI ETSI EN 302 039-2 V1.1.2 (2002-11) 12 AlternativeIdentities {B2:b2} ::= SEQUENCE
(SIZE (1. b2.&maxAlternativeIdentities) )
OF AlternativeIdentity
AlternativeIdentity ::= CHOICE {
url
[0] IA5String (SIZE(1.512))
--
any RFC1738 compliant URL (e.g.; SIP URL)
} --Email addresses shall be
represented as URLs.
AOCBeforeAnswer
::= SEQUENCE {
aOCInitial
[0] CAI-GSM0224,
aOCSubsequent
[1] AOCSubsequent OPTIONAL, .
} -- support for CAMEL
AOCSubsequent
::= SEQUENCE {
cAI-GSM0224
[0] CAI-GSM0224 ,
tariffSwitchInterval
[1] INTEGER (1.86400) OPTIONAL, .
} --
tariffSwitchInterval is measured in 1 second units -- support for CAMEL
ApplicationTimer::=INTEGER (0.2047) -- Used by the SCF to set a timer in the SSF. The timer is in seconds.
AssistingSSPIPRoutingAddress
{B2: b2}::= Digits {b2} -- Indicates the destination address of the SRF for the assist procedure. -- Refer to ITU-T Recommendation Q.763 Generic Number for encoding. BackwardGVNS
{B2: b2}::= OCTET STRING (SIZE( b2.&minBackwardGVNSLength.b2.&maxBackwardGVNSLength)) -- Indicates the GVNS Backward information. Refer to ITU-T Recommendation Q.735-1 for encoding.
BackwardServiceInteractionInd::= SEQUENCE {
conferenceTreatmentIndicator
[1] OCTET STRING (SIZE(1)) OPTIONAL,
-- acceptConferenceRequest
'xxxx xx01'B
-- rejectConferenceRequest
'xxxx xx10'B
-- network default is accept confe
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.