ATIS 1000647A-1998 Integrated Services Digital Network (ISDN) C Conference Calling Supplementary Service C Operations Across Multiple Interfaces (Supplement to ATIS-1000647 1995 (R.pdf

1、 AMERICAN NATIONAL STANDARD FOR TELECOMMUNICATIONS ATIS-1000647.a.1998(R2015) Integrated Services Digital Network (ISDN) Conference Calling Supplementary Service Operations Across Multiple Interfaces As a leading technology and solutions development organization, ATIS brings together the top global

2、ICT companies to advance the industrys most-pressing business priorities. Through ATIS committees and forums, nearly 200 companies address cloud services, device solutions, emergency services, M2M communications, cyber security, ehealth, network evolution, quality of service, billing support, operat

3、ions, and more. These priorities follow a fast-track development lifecycle from design and innovation through solutions that include standards, specifications, requirements, business use cases, software toolkits, and interoperability testing. ATIS is accredited by the American National Standards Ins

4、titute (ANSI). ATIS is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a founding Partner of oneM2M, a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications sectors, and a member of the Inter-Ame

5、rican Telecommunication Commission (CITEL). For more information, visit . AMERICAN NATIONAL STANDARD Approval of an American National Standard requires review by ANSI that the requirements for due process, consensus, and other criteria for approval have been met by the standards developer. Consensus

6、 is established when, in the judgment of the ANSI Board of Standards Review, substantial agreement has been reached by directly and materially affected interests. Substantial agreement means much more than a simple majority, but not necessarily unanimity. Consensus requires that all views and object

7、ions be considered, and that a concerted effort be made towards their resolution. The use of American National Standards is completely voluntary; their existence does not in any respect preclude anyone, whether he has approved the standards or not, from manufacturing, marketing, purchasing, or using

8、 products, processes, or procedures not conforming to the standards. The American National Standards Institute does not develop standards and will in no circumstances give an interpretation of any American National Standard. Moreover, no person shall have the right or authority to issue an interpret

9、ation of an American National Standard in the name of the American National Standards Institute. Requests for interpretations should be addressed to the secretariat or sponsor whose name appears on the title page of this standard. CAUTION NOTICE: This American National Standard may be revised or wit

10、hdrawn at any time. The procedures of the American National Standards Institute require that action be taken periodically to reaffirm, revise, or withdraw this standard. Purchasers of American National Standards may receive current information on all standards by calling or writing the American Nati

11、onal Standards Institute. Notice of Disclaimer 9. In 6.1.4, add the following Operations and Errors:At the end of “endCONF”, at the top of page 22 add the following:EnhancedAddCONF:= OPERATIONARGUMENT SEQUENCE Conferenceld,dChannelldentifier OPTIONAL)-dChannelIdentifier parameter is included when re

12、questing the addition of a call from -one ISDN interface to a conference call on another ISDN interface.RESULT PartyldERRORS illConferenceld, numberOfPartiesExceeded,notAllowed,supplementaryServicelnteractionNotAllowed,invalidCallState, dClNotAssignedByNetworkDCIRequest: OPERATIONRESULT dChannelIden

13、tifier ERRORS notAvailable After “NotAllowed:= Error“, add:DCINotAssignedByNetwork:= ERRORAfter “ConfSize:= INTEGER(0127) add:dchannelidentifier := OCTET STRING (SIZE(1 4)At the end of “Conference operation values” add:dClRequest DCIRequest := 1 2 840 10005 0 9enhancedAddCONF EnhancedAddCONF := 1 2

14、840 10005 0 11At the end of “Conference error values” add:dClNotAssignedByNetwork DCINotAssignedByNetwork := 1 2 840 10005 1 1 10. Modify 6.3.2.1.3, “Adding a conferee” as follows (new text is indicated in bold face):6.3.2.1.3 Adding a confereeTo add a new party, the connection to the conference may

15、 be either in the (Active, Idle) state or in the (Active, Held) state. For incoming calls, the connection to the party to be added shall be either in the Call Received (N7), Incoming Call Proceeding (N9), or Active (N1O) call state, and in the Idle or Held auxiliary state. For outgoing calls, the co

16、nnection to the party to be added shall either be in the Outgoing Call Proceeding (N3) (where PROGRESS message indicating interworking has been sent to the served user), Call Delivered (N4), or Active (N1O) call state, and in the Idle or Held auxiliary call state.The served user shall send a FACILIT

17、Y message to the network indicating the call reference of the call to be added and including either an addCONF-Invoke component or an enhancedAddCONF-Invoke component. The enhancedAddCONF-invoke component shall be used when the add on request is to add a call associated with one ISDN interface to a

18、conference call associated with a different ISDN interface. When the call to be added is on the same interface as the conference call, either the addCONF or enhancedAddCONF Invoke components may be used where the choice is made based on a bilateral agreement. Both Invoke components contain the Confe

19、renceld parameter indicating the conference. The enhancedAddCONF-Invoke component contains an additional optional parame-ter called the D-Channel Identifier. The DCI is required when the call to be added and the conference call reside on different ISDN interfaces. The DCI shall be coded as a four oc

20、tet parameter identifying the ISDN interface associated with the call to be added. See 6.3.2.1.11 for procedures for obtaining a DCI.T1.647a-1998 (R2005)Page 3 of 4 pagesIf the network accepts the request, the network shall send a DISCONNECT message, or if the call is on hold, a RELEASE message to t

21、he served user containing a Facility information element with an addCONF-Return-Result component or enhancedAddCONF-Return-Result component based on the received Invoke component and continue call clearing according to ANSI T1.607. The Return Result component contains a PartyID. This PartyID shall b

22、e used in subsequent operations to identify the added conferee. The first clear-ing message shall contain a Cause information element indicating cause #16 “Normal call clearing” and a location or “public network serving the local user.“If a call is still in the establishment phase, i.e., the Call Re

23、ceived (N7) or the Incoming Call Proceeding (N9) call state, when the request to add a party to the conference is received in a FACILITY message, the network shall complete the connection to the conferee according to normal procedures described in ANSI T1.607.When the user receives a correctly coded

24、 addCONF-Retum-Result component or enhancedAddCONF-Return-Result component, the user shall accept the provided information and save the included PartyID.The procedures to generate PartyID are outside the scope of this standard. The requirements with respect to PartyID are that a PartyID used to iden

25、tify a conferee shall not be used again until the conferee identified by this PartyID has been dropped from the conference, i.e., a PartyID shall be unique within the context of a sin-gle conference.The network shall send a NOTIFY message to the added conferee with a Notification indicator informati

26、on element indicating that it has been added to the conference (“Conference established“).The network shall send a NOTIFY message to all other conferees with a Notification indicator information ele-ment indicating that a new conferee has been added to the conference (“Other party added“).11. Add a

27、new subclause which defines the procedures for obtaining a DCI:6.3.2.1.11 Procedure for Obtaining a DCIBefore an add-on request can be issued which involves an add-on call and the conference call being on two different ISDN interfaces, User A must have the DCI associated with the conference call.The

28、 user shall request a DCI from the network by sending a Facility information element containing an Invoke component with the operation value 9 “dCIRequest” to the network. The coding of the operation value for “dCIRequest” uses object identifiers. The national-specific operation value for “dClReques

29、t” is defined with an ISO object identifier in numbers form as 1 2 840 10005 0 9. In name form this object identifier can also be written as iso member-body us ansi-t1-610 operations dCIRe-quest. The Facility information element shall be sent in a call associated message as described in ANSI T1.610.

30、Upon receiving the dCIRequest Invoke component, the network shall send a Return Result Compo-nent including the DCI, if one is available for the interface. If the network does not have a DCI assigned to that ISDN interface, the network shall send a Return Error component with an error value of 3 “no

31、tAvailable”.12. In 6.3.2.2.1, change the Return Result component “beginCONF-Return-Result” contained in the fifth para-graph to the Return Error component “beginCONF-Return-Error“.13. Within 6.3.2.2.3, “Adding a conferee”, the following changes shall be made (new text is indicated in bold face):If t

32、he ConferencelD used is not associated with the served user, the network shall send an addCONF-Return-Error component or EnhancedAddCONF-Return-Error component, based on the received Invoke com-ponent, to the served user in a FACILITY message. The error value shall be coded as “illConferencelD.”NOTE

33、 - This error could also occur as a result of routing constraints.If the network cannot accept this conferee because the maximum number of parties has been reached, the network shall send addCONF-Retum-Error component or EnhancedAddCONF-Return-Error component, based on the received Invoke component,

34、 to the served user in a FACILITY message. The error value shall be coded as “numberOfPartiesExceeded.”If the network receives an addCONF-Invoke component or EnhancedAddCONF-Invoke component for a call reference value that is not in a valid call state as described in 6.3.2.1.3, the network shall sen

35、d addCONF-Retum-Error component or EnhancedAddCONF-Return-Error component-based on the received Invoke component, indicating the error “invalidCallState” to the served user in a FACILITY message.If an unassigned dChannelldentifier parameter is received in the FACILITY message, i.e., it does not corr

36、espond to an assigned ISDN interface in the network, then the network shall reject the request by sending a Facility information element in a FACILITY message containing a Return Error component with a national-specific error value of 1, “dClNotAssignedByNetwork” to User A. The coding of error value

37、 for “dClNotAssignedByNetwork” uses object identifiers. The national-specific value for the T1.647a-1998 (R2005)Page 4 of 4 pageserror “dClNotAssignedByNetwork” is defined with an ISO object identifier in numbers form as 1 2 840 10005 1 1. In name form this object identifier can also be written as i

38、so member-body us ansi-t1-610 errors dClNotAssignedByNetwork.If the network cannot accept this operation for any other reason, the network shall send addCONF-Return-Error component or EnhancedAddCONF-Return-Error component, based on the received Invoke com-ponent, to the served user in a FACILITY me

39、ssage. The error value shall be coded as “notAllowed.“14. In 6.3.2.2.9, all references to endCONF shall be changed to floatCONF as shown below:If the network cannot accept the operation because the floating conditions are not met (see 4.2.2.2.3), the network shall send a endfloatCONF-Retum-Error com

40、ponent in a FACILITY message to the served user. The error value shall be coded as “notAllowed.”If the network receives a endfloatCONF-Invoke component in a message with a call reference not associated with a conference, the network shall send a endfloatCONF-Return-Error component in a FACILITY mess

41、age to the served user. The error value shall be coded as “notactive.”15. In 6.4, the text shall be modified as indicated below (new text is indicated in boldface):If during a conference a remote conferee uses a supplementary service or other function that generates a notification to the controller,

42、 this notification shall be sent to the conference controller as normal with the fol-lowing addition.The notification indicator information element sent to the controller shall be preceded by an addi-tional Notification indicator information element in the same message. This The additional Notificat

43、ion indicator infomation element shall include with the notification description “discriminator for extension to ASN.1 encoded component” shall include as well_as the PartyIDNotification extended notification, as defined in 6.1.3.2 and using the extended notification mechanism for the Notification i

44、ndicator information element as defined in ANSI T1.610, indicating the PartyIDd of the conferee pertaining to the notification.16. In 6.4.11, the contents shall be replaced with the following:If the network receives a conference calling request (beginCONF Invoke component) from the user while acting

45、 on a Call Deflection request from the same user (involving the same call), the network shall reject the beginCONF Invoke component. The network shall include an error value of “notAvail-able” in the beginCONF Return Error component.If the network receives a Call Deflection request (callRerouting In

46、voke component) from the controller using the call reference of a conference call, the network shall reject the Call Deflection request. The network shall include the error value “notAllowed” in the call Rerouting Return Error component.17. In 6.4.12, the contents shall be modified as shown below (n

47、ew text is indicated in boldface):If, as a result of a conference call being transferred or a call being transferred to a conference, another party is added to a now floating conference call, the network shall apply the “adding a party” notification procedures described in 6.3.2.1.3 for the newly ad

48、ded conferee and the other conferees. The network shall also apply the floating notification procedures to all remote conferees as described in 6.3.2.1.9. The network may place the two notifications in a single or in two NOTIFY messages.The network shall not send notifications of transfer when the t

49、ransfer involves a conference call.Since the conference call is floated, the network shall also follow the procedures of 6.3.2.1.9 of ANSI T1.647 for managing the PartyIDs associated with the conferees and the ConferenceID associated with the conference. The procedures of 6.3 of ANSI T1.643 related to the Notification of transferred call clearing to the controller are not applicable.If the network receives a request to initiate conferencing (i.e., beginCONF Invoke component) while acting on an ECT request (involving the same call), the network shall r