home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD2.mdf / ccitt / 1992 / q / q730_a.asc < prev    next >
Text File  |  1991-12-31  |  29KB  |  640 lines
  1.                                                    ANNEX A
  2.                                      (to Recommendation Q.730)
  3.                  Signalling procedure for the explicit invocation of
  4.                      user-to-user signalling services 1, 2 and 3
  5.          A.1    User-to-user signalling service
  6.          A.1.1  General description of user-to-user service
  7.                See SS 2.1 and 2.2.
  8.          A.2    Procedures for user-to-user signalling associated  with  circuit  switched
  9.                calls
  10.          A.2.1  User-to-user signalling, Service 1
  11.          A.2.1.1   General characteristics
  12.                Service 1 allows users  to  communicate  with  user-to-user  signalling  by
  13.          transferring user-to-user information within ISDN user part messages  during  the
  14.          call set-up and clearing phases. The user-to-user signalling service provided  is
  15.          not a guaranteed service. If for any reason the combination  of  the  basic  plus
  16.          supplementary service information  causes  the  overall  maximum  length  of  the
  17.          message to be exceeded then if the User-to-user Signalling Service 1 is  included
  18.          the service should be rejected.
  19.          A.2.1.2   User-to-user signalling, Service 1 - Explicit service request
  20.                Procedures for call set-up are as described in Recommendation  Q.764,  S  2
  21.          with the following changes:
  22.                On call set-up, the Initial Address Message will contain  the  user-to-user
  23.          indicators  parameter  with  Service  1  indicated  as  "requested  essential/not
  24.          essential" and Service 2 and 3 indicated as "no information". The service request
  25.          will be received from call control at the originating exchange and will be passed
  26.          to the call control at the terminating exchange.
  27.                If the called user or network can support the transfer of  user-to-user,  a
  28.          Service 1 acceptance will be returned to the originating exchange in  an  Address
  29.          Complete or Call Progress Message for the point-to-point case or  the  Answer  or
  30.          Connect Message in the point-to-multipoint case with the  indication  "Service  1
  31.          provided" in the user-to-user indicators parameter. Services  2  and  3  will  be
  32.          indicated as "no information" in the  user-to-user  indicators  parameter.  These
  33.          explicit indications shall be forwarded to the call control  at  the  originating
  34.          exchange.
  35.                User-to-user information may be contained in any of the messages  that  may
  36.          be transferred in the call set-up phase.
  37.          A.2.1.3   Interworking
  38.                In the case of interworking with a  non-ISDN  network,  the  "interworking"
  39.          protocol control information will be returned to the originating exchange in  the
  40.          first appropriate message, e.g., and Address Complete Message. Two ISDN  networks
  41.          that interwork may have to retain knowledge of the service request  until  it  is
  42.          clear whether both can support the service.
  43.          A.2.1.4   Rejection of explicit service requests
  44.                If the called user or network does not understand  the  Service  1  request
  45.          then the Address Complete or Call Progress Message returned  to  the  originating
  46.          exchange shall not include either a Service 1 acceptance or rejection. This  type
  47.          of response will be taken as an implicit rejection of  Service  1.  (Note  -  The
  48.          Study Group XVIII service description does not allow this implicit rejection.)
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.          PAGE46  Fascicle VI.8 - Rec. Q.730
  71.  
  72.                If the network or  called  user  cannot  support  Service  1,  and  it  was
  73.          requested with a non-essential indication, a Service 1  rejection  indication  is
  74.          returned in the Address Complete or Call Progress  Message  with  the  indication
  75.          "Service 1 not provided" in the user-to-user indicators parameter.
  76.                If the Service 1 request is indicated as essential and the called  user  or
  77.          network cannot support  it  a  Release  Message  is  sent  with  cause  code  50,
  78.          "requested facility not subscribed", cause code 29,  "facility  rejected  by  the
  79.          network"  or  cause  code  69,  "requested  facility  not  implemented"  and  the
  80.          diagnostic containing the user-to-user indicators parameter.
  81.          A.2.1.5   User-to-user signalling in the call clearing phase
  82.                A user-to-user  information  parameter  may  be  included  in  the  Release
  83.          Message. The user-to-user information parameter received at the distant  exchange
  84.          in the Release Message is passed to the call control for the remote user. In  the
  85.          case of simultaneous clearing of the call the Release Message may not  reach  the
  86.          distant local exchange and the user-to-user information will be lost.
  87.          A.2.2  User-to-user signalling, Service 2
  88.          A.2.2.1   General characteristics
  89.                Service 2 allows the users to communicate with user-to-user  signalling  by
  90.          transferring up to two user-to-user information messages in each direction during
  91.          the call setup phase. As  a  network  option,  user-to-user  information  may  de
  92.          delivered to  the  called  party  after  the  call  is  answered  to  accommodate
  93.          situations where the information was sent at approximately the same time  as  the
  94.          call was answered. This service allows either an implicit or explicit rejection.
  95.                Service 2 is only applicable when a point-to-point configuration exists  at
  96.          the user-network interface at the terminating exchange.
  97.          A.2.2.2   Call set-up
  98.                Procedures for call set-up are as described in Recommendation  Q.764,  S  2
  99.          with the following changes:
  100.                On call set-up the Initial Address Message will  contain  the  user-to-user
  101.          indicators  parameter  with  Service  2  indicated  as  "requested  essential/not
  102.          essential" and Services 1 and 2 indicated  as  "no  information"1).  The  service
  103.          request will be received from call control. The service request will be passed to
  104.          call control at the terminating exchange.
  105.                If the called user or network can  support  the  transfer  of  user-to-user
  106.          information, a Service 2 acceptance will be returned to the originating  exchange
  107.          in an Address Complete or Call Progress Message with the  indication  "Service  2
  108.          provided" in the user-to-user indicators parameter2). Services 1 and  3  will  be
  109.          indicated as "no information" in the  user-to-user  indicators  parameter.  These
  110.          explicit indications shall be forwarded to the call control  at  the  originating
  111.          exchange.
  112.          A.2.2.3   Service rejection
  113.          A.2.2.3.1 Point-to-point calls
  114.                If the called user or network does not understand  the  Service  2  request
  115.          then the Address Complete or Call Progress Message returned  to  the  originating
  116.          exchange shall not include either a Service 2 acceptance or rejection. This  type
  117.          of response will be taken as an implicit rejection of Service 2.
  118.                If the network or  called  user  cannot  support  Service  2,  and  it  was
  119.          requested with a non-essential indication, a Service 2  rejection  indication  is
  120.          returned in the Address Complete or Call Progress  Message  with  the  indication
  121.          "Service 2 not provided" in the user-to-user indicators parameter3). (Note -  The
  122.          Study Group XVIII service description does not allow this implicit rejection.)
  123.                If the Service 2 request is indicated as essential and the called  user  or
  124.          network cannot support  it  a  Release  Message  is  sent  with  cause  code  50,
  125.          "requested facility not subscribed" cause code  29,  "facility  rejected  by  the
  126.          network"  or  cause  code  69,  "requested  facility  not  implemented"  and  the
  127.          diagnostic containing the user-to-user indicators parameter.
  128.          A.2.2.3.2 Point-to-multipoint calls
  129.                If the call is point-to-multipoint then Service 2  cannot  be  provided  at
  130.          the called party because the user is not identified until the user is  connected.
  131.          Consequently, Service 2 must be rejected using the point-to-point procedures. The
  132.          cause value in this case is code 88, "incompatible destination".
  133.  
  134.          1) The Connection Request parameter will be included if CO-SCCP method is selected, or the
  135.            call reference parameter if CL-SCCP method is selected.
  136.          2) The SCCP connection confirm message will be returned if CO-SCCP method is selected.
  137.          3) The SCCP connection refused message will be returned if CO-SCCP method is selected.
  138.  
  139.  
  140.  
  141.                                                         Fascicle VI.8 - Rec. Q.730  PAGE45
  142.  
  143.          A.2.2.4   Interworking
  144.                In the case of interworking with a  non-ISDN  network,  the  "interworking"
  145.          protocol control information will be returned to the originating exchange in  the
  146.          appropriate message, e.g., an Address Completed Message. Two ISDN  networks  that
  147.          interwork may have to retain knowledge of the service request until it  is  clear
  148.          whether both can support the service.
  149.          A.2.2.5   Transfer of messages containing user-to-user information
  150.                Once acceptance of Service 2 has been transmitted across the network,  both
  151.          of the involved users can transfer user-to-user information  between  themselves.
  152.          Within the network the user-to-user information parameter will be  carried  in  a
  153.          User-to-user Information Message. The network provides for the transfer of  these
  154.          messages from the calling to the called side and vice versa.
  155.                The  User-to-user  Information  Message  format  can  be  found  in   Table
  156.          20/Q.763.
  157.                If the Service 2 is provided, no more  than  two  User-to-user  Information
  158.          Messages carrying user-to-user information parameters may be transmitted in  each
  159.          direction during the call set-up phase. If more than two  messages  are  received
  160.          during call set-up, the additional messages are discarded. If only Service 2  has
  161.          been requested, one of the messages may also be received  and  passed  after  the
  162.          answer state has been reached.
  163.                No transfer of user-to-user information can  occur  until  the  service  is
  164.          acknowledged.
  165.          A.2.3  User-to-user signalling, Service 3
  166.          A.2.3.1   General characteristics
  167.                Service 3 allows the users to communicate with user-to-user  signalling  by
  168.          transferring User-to-user Information  Messages  in  each  direction  during  the
  169.          active phase of the call. This service allows  either  an  implicit  or  explicit
  170.          rejection.
  171.                Service 3 allows the service to be requested either during call  set-up  or
  172.          after call set-up. However, Service 3 should not be requested after  call  set-up
  173.          if it has been rejected during the call set-up phase.
  174.          A.2.3.2   Service 3 requested during call set-up
  175.                Procedures for call set-up are as described in Recommendation  Q.764,  S  2
  176.          with the following changes:
  177.                On call set-up the Initial Address Message will  contain  the  user-to-user
  178.          indicators  parameter  with  Service  3  indicated  as  "requested  essential/not
  179.          essential" and Services 1 and 2 indicated  as  "no  information"4).  The  service
  180.          request will be received from call  control  at  the  originating  exchange.  The
  181.          service request will be passed to the call control at the terminating exchange.
  182.                If the called user or network can  support  the  transfer  of  user-to-user
  183.          information, a Service 3 Acceptance will be returned to the originating  exchange
  184.          in an Answer or Connect Message with the indication "Service 3 provided"  in  the
  185.          user-to-user indicators parameter5). Services 1 and 2 will be  indicated  as  "no
  186.          information" in the user-to-user indicators parameter. These explicit indications
  187.          shall be forwarded to the call control at the originating exchange.
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.                4) The Connection Request parameter will be included if CO-SCCP method is selected, or the
  207.            call reference parameter if CL-SCCP method is selected.
  208.          5) The SCCP connection confirm message will be returned if CO-SCCP method is selected.
  209.  
  210.  
  211.  
  212.          PAGE46  Fascicle VI.8 - Rec. Q.730
  213.  
  214.                A.2.3.3   Rejection of Service 3 when requested during call set-up
  215.                If the called user or network does not understand  the  Service  3  request
  216.          then the Address Complete Call  Progress  Message,  Answer  or  Connect  Message,
  217.          returned to the originating  exchange  shall  not  include  either  a  Service  3
  218.          acceptance or rejection. This type of response  will  be  taken  as  an  implicit
  219.          rejection of Service 3.
  220.                If the network or  called  user  cannot  support  Service  3,  and  it  was
  221.          requested with a non-essential indication, a Service 3  rejection  indication  is
  222.          returned in the Address Complete, Call Progress Message, Answer or  Connect  with
  223.          the  indication  "Service  3  not  provided"  in  the   user-to-user   indicators
  224.          parameter6). (Note - The Study Group XVIII service  description  does  not  allow
  225.          this implicit rejection.)
  226.                If the Service 3 request is indicated as essential and the called  user  or
  227.          network cannot support  it  a  Release  Message  is  sent  with  cause  code  50,
  228.          "requested facility not subscribed", cause code 29,  "facility  rejected  by  the
  229.          network"  or  cause  code  69,  "requested  facility  not  implemented"  and  the
  230.          diagnostic containing the user-to-user indicators parameter.
  231.          A.2.3.4   Service 3 requested after call set-up
  232.                After call set-up has been completed either the  calling  or  called  party
  233.          may request to transfer Service 3 information. On reception of the  request  from
  234.          call control the ISDN User Part sends a Facility Request Message  containing  the
  235.          facility indicator parameter indicating user-to-user service and  a  user-to-user
  236.          indicators parameter requesting Service 3 to the distant local exchange using the
  237.          appropriate transport method. The facility request will contain the  user-to-user
  238.          indicators  parameter  with  Service  3  indicated  as  "requested  essential/not
  239.          essential" and Services 1 and 2 indicated as "no information"7).  On  receipt  of
  240.          the Facility message at the distant exchange call control will be notified  which
  241.          will then notify the remote user. If the user wishes to support Service 3  during
  242.          the active phase, a Service 3 acceptance will be returned  to  call  control.  On
  243.          notification of the acceptance by call control the ISDN User Part will generate a
  244.          Facility Accepted Message  with  the  indication  "Service  3  provided"  in  the
  245.          user-to-user indicators parameter8). Services 1 and 2 will be  indicated  as  "no
  246.          information" in the user-to-user indicators parameter.  On  the  receipt  of  the
  247.          message this explicit acceptance indication shall be forwarded  to  call  control
  248.          which will then notify the requesting user.
  249.          A.2.3.5   Rejection of Service 3 when requested after call set-up
  250.                If the requested user or network does not understand the Service 3  request
  251.          then no message is  returned.  This  response  shall  be  taken  as  an  implicit
  252.          rejection of the service request.
  253.                If the network or requested user cannot  support  Service  3,  and  it  was
  254.          requested with a non-essential indication, a Service 3  rejection  indication  is
  255.          returned in the Facility Reject  Message  with  the  indication  "Service  3  not
  256.          provided" in the user-to-user indicators parameter.
  257.                If the call control does not indicate acceptance or rejection  the  network
  258.          shall not return any explicit rejection to the exchange.
  259.                Note 1 - The Stage 1 service  description  does  not  allow  this  implicit
  260.          rejection.
  261.                Note 2 - The handling of essential/non essential Service 3 request  is  not
  262.          yet consistent with the State 1 service description.
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.          6) The SCCP connection refused message will be returned if CO-SCCP method is selected.
  277.          7) The Connection Request parameter will be included if CO-SCCP method is selected, or the
  278.            call reference parameter if CL-SCCP method is selected.
  279.          8) The SCCP connection confirm message will be returned if CO-SCCP method is selected.
  280.  
  281.  
  282.  
  283.                                                         Fascicle VI.8 - Rec. Q.730  PAGE45
  284.  
  285.                A.2.3.6   Interworking
  286.                In the case of interworking  with  a  non-ISDN  network  an  "interworking"
  287.          protocol control indicator will be returned to the originating  exchange  in  the
  288.          first appropriate message9). If Service 3 was  requested  after  call  set-up,  a
  289.          Facility Reject Message is returned9). Two ISDN networks that interwork may  have
  290.          to retain knowledge of the service request until it is  clear  whether  both  can
  291.          support the service.
  292.          A.2.3.7   Transfer of messages containing user-to-user information
  293.                Once acceptance of Service 3 has been transmitted across the network,  both
  294.          of the involved users can transfer user-to-user information  between  themselves.
  295.          Within the network the user-to-user information parameter will be  carried  in  a
  296.          User-to-user Information Message. The network provides for the transfer of  these
  297.          messages from the calling to the called side and vice versa.
  298.                The  User-to-user  Information  Message  format  can  be  found  in   Table
  299.          20/Q.763.
  300.          A.2.4  Requesting user-to-user signalling Services 1, 2 and 3
  301.                This section describes procedures for requesting Services 1, 2 and 3.
  302.                Note - User-to-user Service  1  implicit  request/response  procedures  are
  303.          also found in S 2.2.1. Only explicit Service 1 requests may follow the  procedure
  304.          in this section.
  305.          A.2.4.1   Call establishment
  306.                Procedures for call establishment are described in SS  A.2.1.2,  A.2.2  and
  307.          A.2.3.2 with the following modifications:
  308.                On service request one user-to-user indicators parameter will be sent  with
  309.          each service being indicated as "requested, essential/non essential".
  310.                If the called user can support  the  indicated  services,  then  all  three
  311.          services will be indicated as "provided" in the user-to-user indicators parameter
  312.          in the Address Complete or Call  Progress  Message.  Alternatively,  the  Address
  313.          Complete or Call Progress Message may indicate "Service 3,  no  information"  and
  314.          "Service 3 provided" in the Answer or Connect Message as provided in  S  A.2.3.2.
  315.          In the case that the  call  is  to  multi-point  users,  the  acknowledgement  of
  316.          Services 1 and 3 shall be delayed until the Answer or Connect Message is sent.
  317.          A.2.4.2   Service rejection
  318.                If the called user or network does not understand  the  service  requested,
  319.          then the Address Complete, Call Progress, Answer  or  Connect  Messages  returned
  320.          will not include either service(s) acceptance or rejection. This type of response
  321.          will be taken as an implicit rejection of all services.
  322.                If the called user or  network  does  not  understand  a  specific  service
  323.          request, that specific service is implicitly rejected following the procedures of
  324.          SS A.2.1.4, A.2.2.3 and A.2.3.3. Alternatively, if the  network  or  called  user
  325.          cannot support one or  more  service  requests  and  the  service  requests  were
  326.          indicated as non-essential, then the rejection may be  provided  in  the  Address
  327.          Complete or Call Progress Messages. (In the case of a call to  multi-point  users
  328.          only Service 2 may be rejected in this way, Service 1 and 3 must be  rejected  in
  329.          the Answer or Connect Message if the called user is  furnishing  the  rejection.)
  330.          The services may also be rejected following the procedures of SS A.2.1.4, A.2.2.3
  331.          and A.2.3.3.
  332.                If any or all of the services requested is indicated as essential  and  the
  333.          called user or network cannot support one or more  of  the  services,  a  Release
  334.          Message is sent with cause code 29, "facility rejected  by  the  network",  cause
  335.          code 50, "requested facility  not  subscribed",  or  cause  code  69,  "requested
  336.          facility  not  implemented"  and  the  diagnostic  containing  the   user-to-user
  337.          indicators parameter.
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.          9) The SCCP connection refused message will be returned if CO-SCCP method is selected.
  351.  
  352.  
  353.  
  354.          PAGE46  Fascicle VI.8 - Rec. Q.730
  355.  
  356.                If the call control does not indicate Service  1,  2  or  3  acceptance  or
  357.          rejection prior to the sending of the Address Complete, Call Progress, Answer  or
  358.          Connect Message, then no indication of service acceptance or rejection  shall  be
  359.          returned for the specific service(s).
  360.          A.2.4.3   Interworking
  361.                In the case of interworking with a  non-ISDN  network,  the  "interworking"
  362.          protocol information will be returned to the originating exchange  in  the  first
  363.          appropriate message, e.g., an Address Complete Message. Two  ISDN  networks  that
  364.          interwork may have to retain knowledge of the service request until it  is  clear
  365.          whether both can support the services.
  366.          A.2.4.4   Transfer of User-to-user Information Messages
  367.                The procedures for the transfer of  User-to-user  Information  Messages  is
  368.          covered in SS A.2.2.5 and A.2.3.7.
  369.          A.2.5  User-to-user information transport methods for Services 2 and 3
  370.                The Transport methods for Services  2  and  3  may  be  found  in  S  3  of
  371.          Recommendation Q.764.
  372.          A.2.6  Message flow diagrams
  373.                The message flow diagrams are shown in Figures A-1/Q.730 to A-7/Q.730.
  374.                For User-to-user Signalling Service 2 and 3  the  figures  only  show  ISDN
  375.          user part messages required for basic call control  and  user-to-user  signalling
  376.          and are not meant to imply any particular transfer  method.  The  parameters  and
  377.          indicators shown are for the  User-to-user  Signalling  Service  only,  i.e.  any
  378.          parameters or message associated with  the  various  transport  methods  are  not
  379.          shown.
  380.                The following notes apply to Figures A-1/Q.730 to A-7/Q.730:
  381.                Note 1 - In cases where  an  ALERTING  indication  is  carried  by  a  Call
  382.          Progress Message the user-to-user indicators parameter  and/or  the  user-to-user
  383.          information parameter may also be transported in the Call Progress Message.
  384.                Note 2 -  In  cases  where  the  called  user  is  an  automatic  answering
  385.          terminal, user-to-user indicators parameter and/or the  user-to-user  information
  386.          parameter may be transported in a Connect Message.
  387.                Figure A-1/Q.730 shows a successful use of user-to-user Signalling  Service
  388.          1 when explicitly requested in a point-to-point configuration.
  389.                Figure  A-2/Q.730  shows  both  the  successful  and  unsuccessful  use  of
  390.          user-to-user Signalling Service 2 in a point-to-point configuration.
  391.                Figure A-3/Q.730 shows  an  unsuccessful  use  of  user-to-user  Signalling
  392.          Service 2 in a point-to-multipoint configuration. This unsuccessful case is shown
  393.          because the network reactions will be the same in all similar cases.
  394.                Figure  A-4/Q.730  shows  both  successful  and  unsuccessful   cases   for
  395.          user-to-user Signalling  Service  3  when  the  service  is  non-essential  in  a
  396.          point-to-point configuration.
  397.                Figure A-5/Q.730 shows a successful use of user-to-user Signalling  Service
  398.          3 after the call is active in a point-to-point configuration.
  399.                Figure  A-6/Q.730  shows  a  successful  use  of  user-to-user   signalling
  400.          Services 1, 2 and 3 and where all services are non-essential in a  point-to-point
  401.          configuration.
  402.                Figure A-7/Q.730 shows successful use of user-to-user  signalling  Services
  403.          1 and 3 and unsuccessful use of Service 2 in a point-to-multipoint configuration.
  404.          It should be noted again that Service 2 will not work  in  a  point-to-multipoint
  405.          configuration.
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.                                                         Fascicle VI.8 - Rec. Q.730  PAGE45
  426.  
  427.                 The following abbreviations are used in the figures:
  428.  
  429.              Abbreviations              User-to-user Indicator Values
  430.                    ni           no information
  431.                    rne          requested, non essential
  432.                    re           requested, essential
  433.                     p           provided
  434.                    np           not provided
  435.               Abbreviations     Parameter name
  436.                    UUI          user-to-user information
  437.                 UUI ind.        user-to-user indicators
  438.               Abbreviations     Message name
  439.                    ACM          Address Complete
  440.                    ANM          Answer
  441.                    FAR          Facility Request
  442.                    FAA          Facility Accepted
  443.                    IAM          Initial Address
  444.                    REL          Release
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.           PAGE46  Fascicle VI.8 - Rec. Q.730
  497.  
  498.                   RLC          Release Complete
  499.                   USR          User-to-user Information
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.                                                         Fascicle VI.8 - Rec. Q.730  PAGE45
  568.  
  569.                The messages shown with dashed lines are not part of  the  ISDN  User  Part
  570.          protocol and are for information only. For detailed  information  on  the  access
  571.          protocol user-to-user procedures the ISDN access  protocol  Recommendation  Q.931
  572.          should be examined.
  573.                                        Figure A-1/Q.730 - T1115880-88
  574.  
  575.                                        Figure A-2/Q.730 - T1115890-88
  576.  
  577.                                        Figure A-3/Q.730 - T1115900-88
  578.  
  579.                                        Figure A-4/Q.730 - T1115910-88
  580.  
  581.                                        Figure A-5/Q.730 - T1115920-88
  582.  
  583.                                        Figure A-6/Q.730 - T1115930-88
  584.  
  585.                                        Figure A-7/Q.730 - T1115940-88
  586.  
  587.          A.2.7  Interaction with other supplementary services
  588.          A.2.7.1   Call forwarding services
  589.                Interactions with the call  forwarding  services  are  shown  in  the  call
  590.          forwarding protocol sections.
  591.          A.2.7.2   Call waiting service
  592.                Interactions with the call waiting service are shown in  the  call  waiting
  593.          protocol sections. (Call waiting is for further study.)
  594.          A.2.7.3   Other services
  595.                There are no known interactions with services other than those listed.
  596.          A.2.8  State transition diagrams
  597.                The state transition diagrams may be found in the Stage  2  description  of
  598.          the User-to-user Service.
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.          PAGE46  Fascicle VI.8 - Rec. Q.730
  639.  
  640.