rfc741.txt

RFC 的详细文档！

         or:  "5,<WHAT>,N",  meaning  inability  to accept  any  of  the
         options  offered  in the INQUIRY, but using "N" as a suggestion
         to  the  ANSWERER   about  another  possibility.  Examples  are
         presented later in this report.

      #6  READY (on L or K)

         Sent by either  party to indicate readiness to accept data. Its
         format  is "6,L"  in the reply  to the initial  call,  and  "6"
         thereafter.

      #7  NOT READY (on L or K)

         Sent by either party to indicate unreadiness to accept data. It
         is always a single word: "7".

      #8  INQUIRY (on L or K)

         Sent by either  party to inquire about the status of the other.
         It is always  a single  word: "8". It is answered by #6, #7, or
         #9.



Cohen                                                           [Page 5]

NWG/RFC 741                                           DC 22 Nov 77 42444
Specifications for the Network Voice Protocol (NVP)



      #9  RINGING (on K)

         Sent  by  the  ANSWERER   after  the  negotiations   have  been
         successfully  terminated  and human  permission  is  needed  to
         proceed  further. The ringing will continue for 10 seconds, and
         then stop,  UNLESS  a #8 is received.  This message is always a
         single word: "9".

      #10  ECHO REQUEST (on L or K)

         Sent by whichever  party is interested in measuring the network
         delays.  Its only purpose  is to  be  echoed  immediately.  The
         format  is "10,<ID>",  where <ID> is any word used to  identify
         the ECHO.

      #11  ECHO (on L or K)

         Sent in response  to ECHO REQUEST.  The  format  is  "11,<ID>",
         where <ID> is the word specified  by #10. The implementation of
         this feature  is not compulsory,  and no connection  should  be
         terminated due to lack of response to ECHO-REQUEST.

      #12  RENEGOTIATION REQUEST (on L or K)

         Can be sent by either party at ANY stage after LINKS are agreed
         upon.  This message consists of the two words "12,<IM>". If the
         word <IM> (for I  MASTER)  is  non-zero,  the  sender  of  this
         message  requests  to be the NEGOTIATION MASTER. If it is zero,
         the receiver of this message is requested to be the NEGOTIATION
         MASTER. Renegotiation is described later.

      #13  RENEGOTIATION APPROVAL (on L or K)

         This message  may be  sent  by  either  party  in  response  to
         RENEGOTIATION   REQUEST.   It  consists   of  the  three  words
         "13,<YM>,<OK>".  If  <OK>  is  non-zero,  this  is  a  positive
         acknowledgment  (approval).  If it is zero,  this is a negative
         acknowledgment  (i.e., refusal). <YM> is set to be equal to the
         <IM> of #12, for identification purposes.

      Messages #7, #8, and #9 are always a single word. Messages #1, #3,
      #4, and #5 are several words long. Messages #2 and #6 are either a
      single word or two words long. #10, #11 and #12 are always 2 words
      long.  Message  #13 is always 3 words long. Message #1 is always 4
      words long.

      Message  #1 is sent only by the CALLER, #3 only by the NEGOTIATION
      MASTER, and #4 and #5 only by the NEGOTIATION SLAVE. Message #9 is




Cohen                                                           [Page 6]

NWG/RFC 741                                           DC 22 Nov 77 42444
Specifications for the Network Voice Protocol (NVP)



      sent only by the ANSWERER.  All the other  control messages may be
      sent by either party.

      The last <HOW> which was both suggested  by the NEGOTIATION MASTER
      (in #3)  and accepted  by the NEGOTIATION  SLAVE  (in #4) for each
      <WHAT> is assumed to be in use.














































Cohen                                                           [Page 7]

NWG/RFC 741                                           DC 22 Nov 77 42444
Specifications for the Network Voice Protocol (NVP)



   DEFINITION OF THE <WHAT> AND <HOW> NEGOTIATION TABLES:

      <WHAT>                          <HOW>

      1. VOCODING                   * 1. LPC
                                    + 2. CVSD
                                      3. RELP
                                      4. DELCO

      2. SAMPLE PERIOD

         (in microseconds)            N. N (*150) (+62)

      3. VERSION

                                    * 1. V1 (see definition below)
                                    + 2. V2 (see definition below)

      4. MAX MSG LENGTH (in bits)

         NVP header included          N. N (*976 and +976)
         (32 bits) but not HOST/IMP
         leader and not HOST/IMP padding

      5. If LPC:

         Degree                       N. For N coefficients (*10)

         If CVSD:

         Time Constant
         (in milliseconds)            N. N (+50)

      6. Samples per Parcel           N. N (*128) (+224)

      7. If LPC:

         Acoustic Coding            * 1. SIMPLE (see below)
                                      2. OPTIMIZED

      8. If LPC:

         Info Coding                * 1. SIMPLE (see below)
                                      2. OPTIMIZED








Cohen                                                           [Page 8]

NWG/RFC 741                                           DC 22 Nov 77 42444
Specifications for the Network Voice Protocol (NVP)



      9. If LPC:

         Pre-emphasis                 N. N (*58, for
         1 - mu x [Z**-1]               mu = 58/64 = 0.90625)
         N = 64 x mu

      10. If LPC:

         Table-set                    N. N (*1)
                                         See definition of Set #1
                                         in Appendix 1

      (* indicates recommended options for LPC)
      (+ indicates recommended options for CVSD)

      No parameter  (<WHAT>) should be inquired about by the NEGOTIATION
      MASTER  if some option (<HOW>) for it has been previously accepted
      by the NEGOTIATION  SLAVE implicitly in the "VERSION". The purpose
      of this restriction  is  to  avoid  a  possible  conflict  between
      individual parameters and the VERSION-option.

         Version 1 (V1) is defined as:

            1-1    LPC
            2-150  150 microseconds sampling
            3-1    V1
            5-10   10 coefficients
            6-128  128 samples per parcel
            7-1    SIMPLE acoustic coding
            8-1    SIMPLE information coding
            9-58   mu = 58/64 = 0.90625
            10-1   Tables set #1

         Version 2 (V2) is defined as:

            1-2    CVSD
            2-62   62 microseconds sampling (16 KHz sampling)
            3-2    V2
            5-50   50 msec time constant
            6-192  192 samples per parcel

         Note that this defines  every negotiated  parameter, except MAX
         MSG LENGTH.

         SIMPLE and OPTIMIZED codings will be described below in Section
         3.

         All the negotiation  is managed  by the NEGOTIATION MASTER, who
         decides  how much negotiation is needed, and what to do in case



Cohen                                                           [Page 9]

NWG/RFC 741                                           DC 22 Nov 77 42444
Specifications for the Network Voice Protocol (NVP)



         some discrepancy (incompatibility) is discovered: either to try
         alternative options or to abort the connection. Upon completion
         of successful  negotiation, the NEGOTIATION MASTER sends either
         #9 (RINGING)  only  if it is the ANSWERER  and if  this  is  an
         initial  connection,  else it sends  #6  (READY-FOR-DATA),  and
         probably  inquires  with #8 about the readiness  of  the  other
         party.  The inquiries  (#8) before the successful completion of
         the negotiation are ignored. However, these inquiries after the
         first RINGING  (#9)  and before the first READY (#6) are needed
         to keep the ANSWERER ringing.

         Note that the negotiation process can be shortened by using the
         VERSION option, as shown in the examples that follow.

   ON RENEGOTIATION

      At any stage after links  are  agreed  upon,  either  party  might
      request  a RENEGOTIATION.  If the request is approved by the other
      party, either party might become the NEGOTIATION MASTER, depending
      on the type of renegotiation  request.  When renegotiation starts,
      no previously  negotiated  agreements  (except LINK numbers) hold,
      and all items have to be  renegotiated  from  scratch.  Note  that
      renegotiation  may entirely  replace  the  negotiation  phase  and
      allows the CALLER to be the NEGOTIATION MASTER.

      Upon issuance  (or reception)  of RENEGOTIATION  REQUEST, all data
      messages   are  ignored  until  the  positive  indication  of  the
      successful completion of the renegotiation (#6).

      After the completion  of renegotiation,  the frame-count  (see the
      section on MESSAGE-HEADER) may be reset to zero.

   THE HEADER OF DATA MESSAGES

      Data messages  are the messages  which contain vocoded speech. The
      first 32 bits of each data message  is the  MESSAGE-HEADER,  which
      carries sequence and timing information as described below.

      For each vocoding  scheme a "FRAME" is defined as the transmission
      interval  (as agreed  upon at the negotiation  stage in <WHAT#6>).
      Since this interval  is defined  by the  number  of  samples,  its
      duration  can be found by multiplying the sampling period <WHAT#2>
      by the interval  length  (in samples) <WHAT#6>. For example, in V1
      the sampling  period  is 150  microseconds  and  the  transmission
      interval is 128 samples, which yields:

         128*150 microseconds = 19.2 milliseconds.

      The data describing  a FRAME is called a PARCEL. Each parcel has a



Cohen                                                          [Page 10]

NWG/RFC 741                                           DC 22 Nov 77 42444
Specifications for the Network Voice Protocol (NVP)



      serial  number.  The first parcel  created after the completion of
      the negotiation  (or every RENEGOTIATION)  has the  serial  number
      zero. Each message contains an integral number of parcels.

      The serial number of the first parcel in the message is put in the
      first   16  bits  of  the  message  and  is  referred  to  as  the
      MESSAGE-TIME-STAMP. Note that this time stamp is synchronized with
      the data stream.  Note also that these  16 bits are  actually  the
      third  word  of  the  message,  following  the  2  words  used  as
      IMP-to-HOST leader (see BBN Report 1822).

      The next bit in the header is the WE-SKIPPED-PARCELS bit, which is
      described  later.  The next 7 bits tell how many parcels there are
      in  the  message;   this  number  is  called  the  COUNT,  or  the
      PARCEL-COUNT.

      Note that if message  number  N has the time stamp  T(N)  and  the
      count  C(N),  then  T(N+1)  must  be  greater  than  or  equal  to
      T(N)+C(N). Usually T(N+1) = T(N)+C(N), unless the XMTR decided not
      to send some parcels  due to silence.  If this  happens  then  the
      WE-SKIPPED-PARCELS  bit is set to ONE,  else it is  set  to  ZERO.
      Hence, if T(N+1) is found by the RCVR to be greater than T(N)+C(N)
      and the WE-SKIPPED-PARCELS is zero, some message must be lost.

      Note that by definition  the time stamps on messages monotonically
      increase, except for wrap-around.

      The message  header  structure  is illustrated  by  the  following
      diagram:

       WORD 1           WORD 2           WORD 3          WORD 4
!................!................!................!................!...
!P000TTTTHHIIIIII!LLLLLLLLZZZZZZZZ!TTTTTTTTTTTTTTTT!WCCCCCCCSSSSSSSS!DDD
!................!................!................!^...............!...
!<--HOST/IMP-OR-IMP/HOST-LEADER-->!<--TIME-STAMP-->!^<COUNT><-SAVE->!<-D
                                                    ^
                                           WE-SKIPPED-PARCELS

         P = PRIORITY (one bit = 1)
         T = MESSAGE TYPE (4 bits = 0011)
         L = link ("L" OR "K", 8 bits, greater than 337 octal)
         D = data bits (from here to the end of the message)

         ZZZZZZZZ = 8 ZERO bits
         HHIIIIII = HOST (8 bits, destination or source)
         CCCCCCC = parcel COUNT (7 bits)
         SSSSSSSS = 8 bits saved for future applications
         TTTTTTTTTTTTTTTT = TIME STAMP (16 bits)




Cohen                                                          [Page 11]

NWG/RFC 741                                           DC 22 Nov 77 42444
Specifications for the Network Voice Protocol (NVP)



         The first parcel  sent by either party after the NEGOTIATION or
         RENEGOTIATION should have the serial number set to zero.

         During  silence  periods,  the XMTR might  send a  "6"  or  "7"
         message  periodically.  If it does not do so,  the  RCVR  might
         interrogate  the livelihood of the XMTR by sending periodically
         "8" ("ARE-YOU-THERE?") or #10 (ECHO-REQUEST) messages.













































Cohen                                                          [Page 12]

NWG/RFC 741                                           DC 22 Nov 77 42444
Specifications for the Network Voice Protocol (NVP)



                       3.  THE LPC DATA PROTOCOL

   The DATA sent at each transmission interval is called a PARCEL.

   Network messages always contain an integral number of PARCELs.

   There are two independent  issues  in the coding.  One is, obviously,
   the acoustic  coding,  i.e., which parameters have to be transmitted.
   SIMPLE  acoustic  coding  is sending  all  the  parameters  at  every
   transmission interval. OPTIMIZED acoustic coding sends only as little
   as acoustically  needed.  DELCO is an example  of OPTIMIZED  acoustic
   coding.

   In this document  only the format  of the SIMPLE  acoustic  coding is
   defined.

   All the transmitted  parameters are sent as pointers into agreed-upon
   tables.  These tables  are  defined  as  two  lists  of  values.  The
   transmitter table {X(J)} is used in the following way: The value V is
   coded  as the code  J if X(J-1) < V =< X(J). The receiver table {R(J)
   is used to retrieve  the value R(J) if the code J was received. X(-1)
   is implicitly  defined  as minus-infinity,  and X(Jmax) is explicitly
   defined as plus-infinity.

   For each parameter, {X(J)} and {R(J)} may be defined independently.

   The second  coding  issue is the information  coding  technique.  The
   SIMPLE  (information-wise)  way of sending  the information is to use
   binary   coding  for  the  codes  representing  the  parameters.  The
   OPTIMIZED  way is to compute  distributions for each parameter and to
   define the appropriate coding. It is very probable that the PITCH and
   GAIN will be decoded  absolutely in the first PARCEL of each message,
   and incrementally thereafter.

   At present, only the SIMPLE (information-wise) coding is used.

   The details  of the LPC data protocol  and its Tables-Set-#1  can  be
   found in Appendix 1.














Cohen                                                          [Page 13]

NWG/RFC 741                                           DC 22 Nov 77 42444
Specifications for the Network Voice Protocol (NVP)