home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD2.mdf / ccitt / 1992 / q / q931a.asc < prev    next >
Text File  |  1991-12-31  |  31KB  |  727 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.                            ANNEX A
  8.                                 
  9.                    (to Recommendation Q.931)
  10.                                 
  11.             User side and network side SDL diagrams
  12.                                 
  13.                                 
  14.                                                               
  15.  
  16.                                           
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30. ANNEXES B TO O AND APPENDICES I, II AND II OF RECOMMENDATION Q.931         
  31.  
  32.                                                                        Page
  33.  
  34.  
  35. Annex B: Compatibility checking ..........................................   7
  36.  
  37. Annex C: Transit network selection .......................................  11
  38.  
  39. Annex D: Extensions for symmetric call operation .........................  12
  40.  
  41. Annex E: Network specific facility selection .............................  15
  42.  
  43. Annex F: D Channel backup procedures .....................................  16
  44.  
  45. Annex G: Cause definitions ...............................................  19
  46.  
  47. Annex H: Examples of information elements coding .........................  26
  48.  
  49. Annex I: Use of progress indicators ......................................  34
  50.  
  51. Annex J: Examples of cause value and location for busy condition .........  35
  52.  
  53. Annex K: Message segmentation procedures .................................  38
  54.  
  55. Annex L: Low layer information coding principles .........................  48
  56.  
  57. Annex M: Low layer compatibility negotiation .............................  57
  58.  
  59. Annex N: Procedures for establishment of bearer connection prior to
  60.        call acceptance .................................................  59
  61.  
  62.                                                                            Page
  63.  
  64. Annex O: Optional procedures for bearer service change ...................  60
  65.  
  66. Appendix I - Use of cause values in call control procedures...............  61
  67.  
  68. Appendix II - Example message flow diagrams and example conditions for
  69.             cause mappings in packet communications.....................  73
  70.  
  71. Appendix III - Summary of assigned information element identifier and
  72.             message type code points for the Q.93-Series of   Recommendations............................................  87
  73.                                    Annex B
  74.                                        
  75.                           (to Recommendation Q.931)
  76.                                        
  77.                             Compatibility checking
  78.                                        
  79.  
  80. B.1    Introduction
  81.  
  82.        This annex describes the various compatibility checks  which  should  be
  83. carried out to ensure that the best matched user and network  capabilities  are
  84. achieved on a call within an ISDN.
  85.  
  86.        This annex also covers interworking with existing networks.
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.        Three different processes of compatibility checking shall be performed:
  95.  
  96.        i)   at the user-to-network interface on the calling side (see
  97.              B.2);
  98.  
  99.        ii)  at the network-user interface on the called side (see    B.3.2);
  100.             and
  101.  
  102.        iii)      user-to-user (see  B.3.3).
  103.  
  104. Note - In this context and throughout this annex the term "called user"  is  the
  105. end point entity which  is  explicitly  addressed.  This  may  be  an  addressed
  106. interworking unit (IWU), see I.500 Series Recommendations.
  107.  
  108.        For details on the coding of the information required  for  compatibility
  109. checking, see Annex L.
  110.  
  111. B.2    Calling side compatibility checking
  112.  
  113.        At the calling side, the network shall  check  that  the  bearer  service
  114. requested by the calling user in the Bearer capability information element matches 
  115. with the bearer services provided to that user by the network. If a mismatch  is
  116. detected, then the network shall reject the call using one of the causes listed in 
  117.  5.1.5.2.
  118.  
  119.        Network services are described in Recommendations I.230 [47] and
  120. I.240 [48] as bearer services and teleservices, respectively.
  121.  
  122. B.3    Called side compatibility checking
  123.  
  124.        In this section, the word  "check"  means  that  the  user  examines  the
  125. contents of the specified information element.
  126.  
  127. B.3.1  Compatibility checking with addressing information
  128.  
  129.        If an incoming SETUP  message  is  offered  with  addressing  information
  130. (i.e., either DDI or sub-addressing or the appropriate part of the called  party
  131. number, e.g., for DDI) the following actions will occur:
  132.  
  133.        a)   if a number (e.g. for DDI) or sub-address is  assigned  to  a  user,
  134.             then the information in a Called party number or Called party sub-address information element of the incoming call shall be checked by 
  135.             the user against the corresponding part of the number assigned to the 
  136.             user (e.g., for DDI) or the user's own
  137.             sub-address. In the case of a mismatch, the user shall  ignore  the
  138.             call.     In    the    case    of    match,    the    compatibility
  139.             checking described in  B.3.2 to B.3.3 will follow;
  140.  
  141.        b)   if a user has no DDI number or sub-address, then the  Called  party
  142.             number and Called party sub-address information  element  shall  be
  143.             ignored. The compatibility checking described in  B.3.2 and B.3.3 
  144.             will follow.
  145.  
  146. Note 1 - According to the user's requirements, compatibility  checking  can  be
  147. performed in various ways from the viewpoint of execution order and information to 
  148. be checked, e.g. first DDI number/sub-address and then  compatibility  or  vice
  149. versa.
  150.  
  151. Note 2 - If an incoming call, offered with addressing information, is always to 
  152. be awarded to the addressed user, all users connected to the same  passive  bus
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164. should have a DDI number or sub-address.
  165.  
  166. B.3.2  Network-to-user compatibility checking
  167.  
  168.        When the network is providing a bearer service at the called  side,  the
  169. user shall check that the bearer service offered by the network in  the  Bearer
  170. capability information element matches the bearer services that the user is able to 
  171. support.  If a mismatch is detected, then the user shall either ignore or reject 
  172. the offered call using cause No. 88 "incompatible destination".
  173.  
  174. B.3.3  User-to-user compatibility checking
  175.  
  176.        The called side terminal equipment shall check that the content  of  the
  177. Low layer compatibility information element is compatible with the functions it 
  178. supports.
  179.  
  180.        The Low layer compatibility information element (if available) shall  be
  181. used to check compatibility of low layers (e.g., from layer 1 to  layer  3,  if
  182. layered according to the OSI model).
  183.  
  184. Note - The Bearer capability information element is also checked, see   B.3.2.
  185. Therefore, if any conflict  from  duplication  of  information  in  the  Bearer
  186. capability and the Low layer compatibility information elements is detected, this 
  187. conflict shall be resolved according to Annex L, e.g. the conflicting information in 
  188. the Low layer compatibility information element shall be ignored.
  189.  
  190.        If the Low layer compatibility information element is not included in an 
  191. incoming SETUP message, the Bearer capability information element shall be used 
  192. to check the compatibility of low layers.
  193.  
  194.        The called terminal equipment may check  the  High  layer  compatibility
  195. information element (if present) as part of user-to-user compatibility checking 
  196. procedures, even if the network only supports bearer services.
  197.  
  198.        If a mismatch is detected in checking any of  the  information  elements
  199. above, then the terminal equipment shall either ignore or reject the offered call 
  200. using cause No. 88 "incompatible destination".
  201.  
  202.        With regard to the presence or absence of the High  layer  compatibility
  203. and Low layer compatibility information elements, two cases arise:
  204.  
  205.        a)   Compatibility assured with the available description of the call
  206.  
  207.        This is when all  terminal  equipment  implement  (i.e.  understand  the
  208. contents of) the High layer compatibility and Low layer compatibility information 
  209. elements.  Thus, based on the High layer compatibility and Low layer compatibility 
  210. information element encoding, they are capable of accepting a  call  for  which
  211. they have the requested functionality.
  212.  
  213.        b)   Compatibility not assured with the available description of the   call
  214.  
  215.        This is when all or some of the  terminal  equipment  do  not  recognize
  216. (i.e. ignore) either the High layer compatibility or  Low  layer  compatibility
  217. information elements. Without careful configuration or administration at the user's 
  218. installation, there is a danger that a terminal equipment which  has  incorrect
  219. functionality will accept the call.
  220.  
  221.        Therefore, in order to assure compatibility with incoming calls,  it  is
  222. recommended that the terminal equipment check the Low layer  compatibility  and
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229. High layer compatibility information elements.
  230.  
  231. Note - Some terminal equipment, upon bilateral agreement with other users or in 
  232. accordance with other standards (e.g. Recommendation X.213, [23]) may employ the 
  233. User-user information  element  for  additional  compatibility  checking.  Such
  234. terminal equipment shall check the User-user information element in a manner identical 
  235. to that described here for the High  layer  compatibility  information  element
  236. "compatibility assured" case.
  237.  
  238. B.3.4  User action tables
  239.  
  240.        The following tables show the action which shall be  carried  out  as  a
  241. result of compatibility checking with the calling user's request for  a  bearer
  242. service and/or teleservice.
  243.  
  244.                                TABLE B-1/Q.931
  245.  
  246.                     Bearer capability compatibility checking
  247.                                        ┌─────────────┬────────────────┬─────────────────────┐ 
  248.             │      BC     │ Point-to-point │     Broadcast       │
  249.             │  mandatory  │   data link    │     data link       │
  250.             │info element │                │     (Note 1)        │
  251.             ├─────────────┼────────────────┼─────────────────────┤
  252.             │             │                │                     │
  253.             │Compatible   │Proceed         │     Proceed         │
  254.             ├─────────────┼────────────────┼──────────┬──────────┤
  255.             │Incompatible │Reject (5.2.5.1)│Ignore    │Reject    │
  256.             │             │                │(5.2.5.1a)│(5.2.5.1b)│
  257.             │             │                │(Note 2)  │(Note 2)  │
  258.             └─────────────┴────────────────┴──────────┴──────────┘
  259.  
  260.                                TABLE B-2/Q.931
  261.                                        
  262.     Low layer and high layer compatibility checking: compatibility assured
  263.                   with the available description of the call
  264.  
  265.  ┌─────────────┬────────────────────────┬──────────────────────────────────┐
  266.  │LLC/HLC      │     Point-to-point     │          Broadcast               │
  267.  │compatibility│       data link        │          data link               │
  268.  │assured      │        (Note 1)        │           (Note 1)               │
  269.  ├─────────────┼────────────────────────┼──────────────────────────────────┤
  270.  │Compatible   │        Accept          │           Accept                 │
  271.  ├─────────────┼──────────┬─────────────┼──────────┬─────────┬─────────────┤
  272.  │Incompatible │ Reject   │Attempt low  │Ignore    │Reject   │Attempt      │
  273.  │             │ (5.2.5.1)│layer        │(5.2.5.1a)│5.2.5.1b)│low layer    │
  274.  │             │          │compatibility│(Note 2)  │(Note 2) │compatibility│
  275.  │             │          │negotiation  │          │         │negotiation  │
  276.  │             │          │(Annex M)    │          │         │(Annex M)    │
  277.  └─────────────┴──────────┴─────────────┴──────────┴─────────┴─────────────┘
  278.  
  279.                                TABLE B-3/Q.931
  280.                                        
  281.       Low layer and high layer compatibility checking: compatibility not
  282.               assured with the available description of the call
  283.                                                   
  284.      ┌─────────────┬─────────────────────────┬─────────────────────────┐
  285.      │LLC/HLC      │     Point-to-point      │     Broadcast data      │
  286.      │compatibility│        data link        │          link           │
  287.      │not assured  │        (Note 1)         │        (Note 1)         │
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.      ├─────────────┼──────────┬──────────────┼──────────┬──────────────┤
  300.      │HLC or LLC   │ Accept or│Attempt low   │ Accept or│Attempt low   │
  301.      │present      │ reject   │layer         │ reject   │layer         │
  302.      │             │ (Note 3) │compatibility │ (Note 3) │compatibility │
  303.      │             │          │negotiation   │          │negotiation   │
  304.      │             │          │(Annex M)     │          │(Annex M)     │
  305.      └─────────────┴──────────┴──────────────┴──────────┴──────────────┘
  306.  
  307. Note 1 - For broadcast  data  link  terminal  equipment  which  are  explicitly
  308. addressed using sub-addressing or DDI, the point-to-point column in the above table 
  309. shall be used.
  310.  
  311. Note 2 - When a terminal equipment on a broadcast data link is incompatible, an 
  312. option of "ignore or reject" is permitted, see  5.2.2.
  313.  
  314. Note 3 - Some terminal equipment on this interface may understand the  High  layer
  315. compatibility or Low layer compatibility information element and would reject  the
  316. call if incompatible.
  317.  
  318. B.4    Interworking with existing networks
  319.  
  320.        Limitations in network or distant user signalling (e.g. in the case  of  an
  321. incoming call from a PSTN or a call from an analogue terminal)  may  restrict  the
  322. information available to the called user in the incoming SETUP message. A called user 
  323. should accept limited compatibility checking (e.g., without the
  324. High layer compatibility information element) if a call is routed from an existing 
  325. network which does  not  support  High  layer  compatibility  information  element
  326. transfer.
  327.  
  328.        In cases where the network cannot provide all incoming call information, or 
  329. where the network is not aware  of  the  existence  or  absence  of  some  service
  330. information (such as compatibility information), the incoming SETUP message includes a 
  331. Progress indicator information element, containing progress indicator No. 1 "Call is 
  332. not end-to-end ISDN, further call progress information may be available in-band" or 
  333. No. 3 "Origination address is non-ISDN" (see Annex I).
  334.  
  335.        The  terminal  equipment  receiving  a  SETUP  with  a  progress  indicator
  336. information element shall modify its compatibility checking, the terminal equipment should 
  337. regard the compatibility as successful if  it  is  compatible  with  the  included
  338. information, which as a minimum, will be the bearer capability information element. A 
  339. terminal equipment expecting information in  addition  to  the  Bearer  capability
  340. information element in a full ISDN environment need not reject the call if such information 
  341. is absent but a Progress indicator information element is included.
  342.  
  343.  
  344.  
  345.  
  346.  
  347.                                      Annex C
  348.                                          
  349.                             (to Recommendation Q.931)
  350.                                          
  351.                             Transit network selection
  352.                                          
  353.                                          
  354.        This annex describes  the  processing  of  the  transit  network  selection
  355. information element.
  356.  
  357. C.1    Selection not supported
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.        Some networks may not support transit network selection. In this case, when 
  366. a Transit network selection information  element  is  received,  that  information
  367. element is processed according to the rules for unimplemented non- mandatory information 
  368. elements (see  5.8.7.1).
  369.  
  370. C.2    Selection supported
  371.  
  372.        When transit network  selection  is  supported,  the  user  identifies  the
  373. selected transit network(s) in the SETUP message. One  Transit  network  selection
  374. information element is used to convey a single network identification.
  375.  
  376.        The user may specify more than one transit network. Each identification  is
  377. placed in a separate information element. The call would then be routed through the 
  378. specified transit networks in the order listed in the SETUP. For example,  a  user
  379. lists networks A and B, in that order, in two Transit network selection information 
  380. elements within a SETUP message. The call is first routed  to  network  A  (either
  381. directly or indirectly), and then to network B (either directly or indirectly), before 
  382. being delivered.
  383.  
  384.        As the call is  delivered  to  each  selected  network,  the  corresponding
  385. transit selection may be stripped from the call establishment signalling, in accordance 
  386. with the relevant internetwork signalling arrangement. The Transit network selection 
  387. information element(s) is/are not delivered to the destination user.
  388.  
  389.        No more than four Transit network selection  information  elements  may  be
  390. used in a single SETUP message.
  391.  
  392.        When a network cannot route the call because the route is busy, the network 
  393. shall initiate call clearing in accordance with    5.3  with  cause  No.  34  "no
  394. circuit/channel available".
  395.  
  396.        If a network does not recognize the specified transit network, the  network
  397. shall initiate call clearing in accordance with  5.3, with cause No. 2 "no  route
  398. to specified transit network". The diagnostic field shall contain a  copy  of  the
  399. contents of the Transit network  selection  information  element  identifying  the
  400. unreachable network.
  401.  
  402.        A network may screen all remaining transit  network  selection  information
  403. elements to:
  404.  
  405.        a)   avoid routing loops, or
  406.  
  407.        b)   ensure an appropriate business relationship  exists  between
  408.             selected networks, or
  409.  
  410.        c)   ensure compliance with national and local regulations.
  411.  
  412.        If the transit network selection is of an incorrect format, or  fails  to
  413. meet criteria a), b)  or  c),  the  network  shall  initiate  call  clearing  in
  414. accordance with  5.3, with cause No. 91 "invalid transit network selection".
  415.  
  416.        When a user includes the Transit network selection  information  element,
  417. pre-subscribed  default  Transit  network  selection  information  (if  any)  is
  418. overridden.
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.                                     Annex D
  436.                                         
  437.                            (to Recommendation Q.931)
  438.                                         
  439.                     Extensions for symmetric call operation
  440.                                         
  441.  
  442. D.1    Additional message handling
  443.  
  444.        In symmetric applications, the SETUP message will contain a
  445. Channel Identification information element indicating a particular B Channel  to
  446. be used for the call. A point-to-point data link shall be used to carry the SETUP 
  447. message.
  448.  
  449.        The procedure described in  5 for  the  user  side  should  normally  be
  450. followed. Where additional procedures are required, they are detailed below.
  451.  
  452. D.1.1  B Channel selection - symmetric interface
  453.  
  454.        Only B Channels controlled by the same D Channel will be the  subject  of
  455. the selection procedure. The selection procedure is as follows:
  456.  
  457.        a)   The SETUP message will indicate one of the following:
  458.  
  459.             1)   channel is indicated, no acceptable alternative, or
  460.  
  461.             2)   channel is indicated, any alternative is acceptable.
  462.  
  463.        b)   In cases 1) and 2), if the indicated channel is  acceptable  and
  464.             available, the recipient of the SETUP message  reserves  it  for
  465.             the call. In case 2), if the recipient of the SETUP message cannot 
  466.             grant the indicated channel, it reserves any other  available  B
  467.             Channel associated with the D Channel.
  468.  
  469.        c)   If the  SETUP  message  included  all  information  required  to
  470.             establish the call, the recipient of SETUP message indicates the 
  471.             selected B Channel in a CALL PROCEEDING message transferred across the 
  472.             interface and enters the Incoming Call Proceeding state.
  473.  
  474.        d)   If the SETUP message did not include all the  information  required
  475.             to  establish  the  call,  B  Channel  is  indicated  in  a   SETUP
  476.             ACKNOWLEDGE message sent across the interface. The additional  call
  477.             establishment information, if any, is sent in one or more INFORMATION messages 
  478.             transferred across the interface in the same direction as the SETUP 
  479.             message. When all call establishment information is received, a CALL 
  480.             PROCEEDING,  ALERTING,  or  CONNECT  message,  as  appropriate,  is
  481.             transferred across the interface.  
  482.  
  483.        e)   In case 1) if the indicated B Channel is not available, or in  case
  484.             2) if no B Channel is available, a RELEASE COMPLETE message with  a
  485.             cause value of No. 44 "requested circuit/channel not available"  or
  486.             No. 34 "no circuit/channel available" respectively is returned to the 
  487.             initiator of the call. The sender of this message  remains  in  the
  488.             Null state.
  489.  
  490.        f)    If  the  channel  indicated  in  the  CALL  PROCEEDING  or   SETUP
  491.             ACKNOWLEDGE message is unacceptable to the initiator of the call, it clears 
  492.             the call in accordance with  5.3.
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500. D.1.2  Call confirmation
  501.  
  502.        Upon receipt of a SETUP message, the equipment enters the  Call  Present
  503. state. Valid responses to the SETUP message are a SETUP ACKNOWLEDGE, an ALERTING, 
  504. a CALL PROCEEDING, a CONNECT, or a RELEASE COMPLETE message.
  505.  
  506.        If the indicated channel is acceptable to the initiator of the call, the 
  507. initiator shall attach to the indicated B Channel.
  508.  
  509. D.1.3     Clearing    by    the    called    user    employing    user-provided
  510. tones/announcements
  511.  
  512.        In addition to the procedures  described  in    5.3.3,  if  the  bearer
  513. capability is either audio or speech, the called user or private network may apply in-band tones/announcements in the clearing phase. When in-band 
  514. tones/announcements are provided, the DISCONNECT message contains progress indicator No. 8 "in-band information or appropriate pattern is now available" and the called user 
  515. or private network proceeds similarly as stipulated in
  516.  5.3.4.1 for the network.
  517.  
  518. D.1.4  Active indication
  519.  
  520.        Upon receipt of a CONNECT message,  the  initiator  of  the  call  shall
  521. respond with a CONNECT ACKNOWLEDGE message and enter the Active State.
  522.  
  523. D.2    Timers for call establishment
  524.  
  525.        User end points implement the network side timers T301,  T303  and  T310
  526. along with the corresponding network side procedures  for  actions  taken  upon
  527. expiration of these timers. See Table 9-2/Q.931 for the call establishment user- side 
  528. timers and procedures.
  529.  
  530. D.3    Call collisions
  531.  
  532.        In symmetric arrangements, call collisions can  occur  when  both  sides
  533. simultaneously transfer a SETUP message indicating the same channel. In the absence 
  534. of administrative procedures for assignment of channels to  each  side  of  the
  535. interface, the following procedure is employed.
  536.  
  537.        First, one side of the interface will be designated  the  "network"  and
  538. the other side of the interface will be designated the "user". Second, for  the
  539. three possible scenarios where the same channel is indicated by combinations of 
  540. preferred and exclusive from the user and network sides, the following procedure is 
  541. used:
  542.  
  543.        a)   "network" preferred, "user" preferred:
  544.  
  545.                         the "network" preferred channel is awarded and an alternate channel 
  546.             is indicated in the first response to the "user" SETUP message;
  547.  
  548.        b)   "network" exclusive, "user" exclusive:
  549.  
  550.                         the "network" exclusive channel is awarded and the "user" SETUP 
  551.             message is cleared with a RELEASE COMPLETE message with cause
  552.             No. 34 "no circuit/channel available";
  553.  
  554.        c)   "network" preferred, "user" exclusive; or  "network"  exclusive,
  555.             "user" preferred:
  556.  
  557.                         the side of the interface with an exclusive indicator in a SETUP 
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.             message is  awarded  the  channel  and  an  alternate  channel  is
  570.             indicated in the first response to the side using a preferred indicator in 
  571.             the SETUP message.
  572.  
  573.        Channel identification is allowed in both directions for  ALERTING  and
  574. CONNECT.
  575.  
  576.  
  577.  
  578.  
  579.  
  580.                                    Annex E
  581.                                        
  582.                           (to Recommendation Q.931)
  583.                                        
  584.                      Network specific facility selection
  585.  
  586.  
  587.        This annex describes the processing of the Network-specific  facilities
  588. information element. The purpose of this information element  is  to  indicate
  589. which network facilities are being invoked.
  590.  
  591. E.1    Default provider
  592.  
  593.        When the length of the network identification field is set to  zero  in
  594. the  Network-specific  facilities  information  element,  then  the   services
  595. identified in this information element are to be provided by the network side of the 
  596. interface receiving the information element (default provider). If the Network-specific facilities information element is recognized but the network 
  597. facilities are not understood, then this information element is processed according to 
  598. rules for non-mandatory information element content error (see
  599.  5.8.7.1).
  600.  
  601. E.2    Routing not supported
  602.  
  603.        Some networks may not support the routing to the remote network of  the
  604. contents of the Network-specific facilities information element. In this case, 
  605. when a Network-specific  facilities  information  element  is  received,  that
  606. information element is processed according to the rules for unimplemented non- 
  607. mandatory information elements (see  5.8.7.1).
  608.  
  609. E.3    Routing supported
  610.  
  611.        When  Network-specific  facility   information   element   routing   is
  612. supported, the user identifies the network provider in this information element in the 
  613. Q.931 SETUP message. One Network-specific facility information element is used 
  614. to identify a network provider. 
  615.  
  616.        The user may specify more than one network provider  by  repeating  the
  617. Network-specific facilities information element. Each identification is placed in 
  618. a separate information element. The information is  routed  to  the  indicated
  619. network provider as long as the call is also handled by the network provider (see 
  620. Annex C, Transit network selection). For example, if the  user  lists  network
  621. providers A and B in separate Network-specific facilities information elements in a 
  622. call control message, there must be corresponding  Transit  network  selection
  623. information elements in the SETUP message identifying those networks (or default 
  624. call routing via A and B that was established prior to call establishment).
  625.  
  626.        As  the  signalling  messages  containing  Network-specific  facilities
  627. information elements are delivered to the indicated remote network, they may be 
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634. stripped from  the  signalling  messages,  in  accordance  with  the  relevant
  635. internetworking signalling arrangement. The Network-specific facilities information 
  636. elements may be delivered to the identified user.
  637.  
  638.        No more than four Network-specific facilities information elements  may
  639. be used in a SETUP message. When the information element is repeated, the order 
  640. of presentation of the elements in a message is not significant. Further, there 
  641. does not have to  be  a  one-to-one  correspondence  between  Network-specific
  642. facilities information elements and Transit network selection information elements.
  643.        If a network cannot pass  the  information  to  the  indicated  network
  644. provider, either due to:
  645.  
  646.        -    the network indicated is not part of the call path, or
  647.  
  648.        -    no mechanism exists for passing the  information  to  identified
  649.             network.
  650.  
  651.        The network shall initiate call clearing in accordance with   5.3,  with
  652. cause No. 2 "no route to specified transit network". The  diagnostic  field  may
  653. optionally contain a copy of the first 5 octets of the network-specific facilities 
  654. information element.
  655.  
  656.        When  the  user  includes  the  Network-specific  facilities  information
  657. element in the SETUP message, pre-subscribed default service treatment (if any) is 
  658. overridden.  
  659.  
  660.  
  661.  
  662.  
  663.                                     Annex F
  664.                                         
  665.                            (to Recommendation Q.931)
  666.                                         
  667.                           D Channel backup procedures
  668.  
  669.  
  670. F.     Foreword
  671.  
  672.        The procedure defined in this  annex  can  be  used  when  non-associated
  673. signalling is applied to multiple primary rate access arrangements. This feature can 
  674. be provided on a subscription basis and is network dependent.
  675.  
  676. F.1    General
  677.  
  678.        In associated signalling, the D Channel signalling entity can only assign 
  679. calls to channels on the interface containing the D Channel. When the
  680. D Channel signalling entity can assign  calls  to  channels  on  more  than  one
  681. interface (including the one containing the D Channel), this is called non- associated 
  682. signalling. Figure F-1/Q.931 is an example of associated signalling used on each 
  683. of the three interfaces between a user (e.g., a PABX) and a  network.  Replacing
  684. associated signalling with non-associated signalling on these interfaces results in 
  685. the example shown in Figure F-2/Q.931.
  686.  
  687.        When non-associated  signalling  is  employed,  the  reliability  of  the
  688. signalling performance for the ISDN interfaces controlled by the D Channel may be 
  689. unacceptable. To improve the reliability, a D Channel backup procedure employing a 
  690. standby D Channel is necessary. The next section describes the backup  procedure
  691. which is optional for end-points that use non-associated signalling.
  692.  
  693.  
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721. FIGURE F-3/Q.931
  722.  
  723.  
  724.  
  725.  
  726.  
  727.