Skip to main content

Real Time Internet Peering Protocol
draft-rosenbergjennings-dispatch-ripp-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Jonathan Rosenberg , Cullen Fluffy Jennings , Anthony Minessale , Jason Livingood
Last updated 2019-07-08
Replaced by draft-rosenbergjennings-dispatch-ript
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-rosenbergjennings-dispatch-ripp-02
Rosenberg, et al.        Expires January 9, 2020               [Page 24]
Internet-Draft                    RIPP                         July 2019

   o  max-samplerate: The maximum sample rate for audio.  This is
      specified in Hz.  It MUST be greater than or equal to 8000.  Its
      default is 8000.

   o  max-samplesize: The maximum sample size for audio.  This is
      specified in bits.  It MUST be greater than or equal to 8.  The
      default is 16.

   o  force-cbr: Indicates whether the entity requires CBR media only.
      It MUST be either "true" or "false".  The default is "false".  If
      "true", the sender MUST send constant rate audio.

   o  two-channel: Indicates whether the entity supports receiving two
      audio channels or not.  Two channel audio is specifically used for
      RIPP trunks meant to convey listen-only media for the purposes of
      recording, similar to SIPREC [RFC7866].  It MUST be either "true"
      or "false".  The default is "false".

   o  tnt: Indicates whether the entity supports the takeback-and-
      transfer command.  Telcos supporting this feature on a trunk would
      set it to "true".  The value MUST be "true" or "false".  The
      default is "false".

   In addition, codecs can be listed as capabilities.  This is done by
   using the media type and subtype, separated by a "/", as the
   capability name.  Media type and subtype values are taken from the
   IANA registry for RTP payload format media types, as defined in
   [RFC4855].  The value of the capability is "true" if the codec is
   supported, "false" if it is not.  The default is "false" for all
   codecs except for "audio/PCMU", "audio/opus", "audio/telephone-event"
   and "audio/CN", for which the default is "true".  Because codec
   capabilities are receive-only, it is possible, and totally
   acceptable, for there to be different audio codecs used in each
   direction.

   In general, an entity MUST declare a capability for any
   characteristic of a call which may result in the call being rejected.
   This requirement facilitates prevention of call failures, along with
   clear indications of why calls have failed when they do.  For
   example, if a RIPP trunk provider provisions a trunk without support
   for G.729, but the consumer configures their to utilize this codec,
   this will be known as a misconfiguration immediately.  This enables
   validation of trunk configurations in an automated fashion, without
   placing test calls or calling customer support.

Rosenberg, et al.        Expires January 9, 2020               [Page 25]
Internet-Draft                    RIPP                         July 2019

8.4.  Initiating Calls

   HTTP connections are completely independent of RIPP trunks or calls.
   As such, RIPP clients SHOULD reuse existing HTTP connections for any
   request targeted at the same authority to which an existing HTTP
   connection is open.  RIPP clients SHOULD also utilize 0-RTT HTTP
   procedures in order to speed up call setup times.

   To initiate a new call, a RIPP client creates an HTTPS POST request
   to /calls endpoint on the RIPP trunk URI of its peer.  For a trunking
   consumer, this is the RIPP trunk URI provisioned during the OAuth2.0
   flow.  For the trunking provider, it is the RIPP trunk consumer URI
   learned through the provisioning POST operation.  This MUST be an
   HTTP/3 transaction.  The client MUST validate that the TLS
   certificate that is returned matches the authority component of the
   RIPP trunk URI.

   This request MUST contain the token that the client has obtained out-
   of-band.  For the RIPP trunk consumer, this is the OAuth token.  For
   the RIPP trunk provider, it is the bearer token learned through the
   provisioning POST operation.

   The client MUST also add the "target" URI parameter.  This parameter
   MUST be of the form user@domain.  If the target is a phone number on
   the PSTN, this must take the form @e164.arpa, where is a valid E.164
   number.  RIPP also supports private trunks, in which case the it MUST
   take the form @, where the number is a non-E164 number scoped to be
   valid within the domain.  This form MUST NOT be used for E.164
   numbers.  Finally, RIPP can be used to place call to application
   services - such as a recorder - in which case the parameter would
   take the form of an RFC822 email address.

   The client MUST add an HTTP Identity header field.  This header field
   is defined in Section Section 11 as a new HTTP header field.  Its
   contents MUST be a valid Identity header field as defined by
   [RFC8224].  This ensures that all calls utilize secure caller ID.  A
   RIPP client MUST NOT place the caller ID in any place except for the
   Identity header field in this request.  Specifically, a "From",
   "Contact", or "P-Asserted-ID" header field MUST NOT ever appear.

   o  CJ - I would prefer to add this another way without using a
      header.

   The server MUST validate the OAuth token, MUST act as the verifying
   party to verify the Identity header field, and then authorize the
   creation of a new call, and then either accept or reject the request.
   If accepted, it indicates that the server is willing to create this
   call.  The server MUST return a 201 Created response, and MUST

Rosenberg, et al.        Expires January 9, 2020               [Page 26]
Internet-Draft                    RIPP                         July 2019

   include a Location header field containing an HTTPS URI which
   identifies the call that has been created.  The URI identifying the
   call MUST include a path segment which contains a type 4 UUID,
   ensuring that call identifiers are globally unique.

   The server MAY include HTTP session cookies in the 201 response.  The
   client MUST support receipt of cookies [RFC6265].  It MUST be
   prepared to receive up to 10 cookies per call.  The client MUST
   destroy all cookies associated with a call, when the call has ended.
   Cookies MUST NOT be larger the 5K.

   The usage of an HTTP URI to identify the call itself, combined with
   session cookies, gives the terminating RIPP domain a great deal of
   flexibility in how it manages state for the call.  In traditional
   softswitch designs, call and media state is held in-memory in the
   server and not placed into databases.  In such a design, a RIPP
   server can use the session cookie in combination with sticky session
   routing in the load balancers to ensure that subsequent requests for
   the same call go to the same call server.  Alternatively, if the
   server is not using any kind of HTTP load balancer at all, it can use
   a specific hostname in the URI to route all requests for this call to
   a specific instance of the server.  This technique is particularly
   useful for telcos who have not deployed HTTP infrastructure, but do
   have SBCs that sit behind a single virtual IP address.  The root URI
   can use a domain whose A record maps to this IP.  Once a call has
   landed on a particular SBC, the call URI can indicate the specific IP
   of the SBC.

   For example, the RIPP trunk URI for such a telco operator might be:

   <https://sbc-farm.comcast.com/trunks/6ha937fjjj9>

   which always resolves to 1.2.3.4, the VIP shared amongst the SBC
   farm.  Consequently, a request to this RIPP trunk would hit a
   specific SBC behind the VIP.  This SBC would then create the call and
   return a call URL which points to its actual IP, using DNS

   <https://sbc23.sbc-farm.comcast.com/call/ha8d7f6fso29s88clzopa>

   However, the HTTP URI for the call MUST NOT contain an IP address; it
   MUST utilize a valid host or domain name.  This is to ensure that TLS
   certificate validation functions properly without manual
   configuration of certificates (a practice which is required still for
   SIP based peering).

   Neither the request, nor the response, contain bodies.

Rosenberg, et al.        Expires January 9, 2020               [Page 27]
Internet-Draft                    RIPP                         July 2019

8.5.  Establishing the Signaling Byways

   To perform signalling for this call, the client MUST initiate an HTTP
   GET and PUT request towards the call URI that it just obtained,
   targeted at the /event endpoint.

   The signaling is accomplished by a long running HTTP transaction,
   with a stream of JSON in the PUT request, and a stream of JSON in the
   GET response.

   The body begins with an open curly bracket, and after that is a
   series of JSON objects, each starting with a curly bracket, and
   ending with a curly bracket.  Consequently, each side MUST
   immediately send their respective open brackets after the HTTP header
   fields.  We utilize streaming JSON in order to facilitate usage of
   tools like CURL for signalling operations.

8.6.  The Media Sequence

   In RIPP, media is represented as a continuous sequence of RIPP media
   frames embedded in a media byway.  Each ripp media frame encodes a
   variable length sequence number offset, followed by a variable length
   length field, followed by a codec frame equal to that length.  The
   media byway itself, when created, includes properties that are shared
   across all media frames within that byway.  These parameters include
   the sequence number base, the timestamp base, the codec type, and the
   frame size in milliseconds for the codec.

   This is a significantly different design than RTP, which conveys many
   repeated parameters (such as the payload type and timestamp) in every
   packet.  Instead, RIPP extracts information that will be shared
   across many packets and associates it with the byway itself.  This
   means the media frames only contain the information which varies -
   the sequence number and length.  [[OPEN ISSUE: we could maybe even
   eliminate the sequence number by computing it from offset in the
   stream.  Worried about sync problems though?]]

   Consequently, each media frame has the following properties:

   o  The sequence number, which is equal to the sequence number base
      associated with the media byway, PLUS the value of the sequence
      number offset

   o  The timestamp, which is equal to the timestamp base from the
      byway, PLUS the sequence number offset TIMES the frame size in
      milliseconds.  Note that this requires that frame size must remain
      fixed for all media frames in a byway.

Rosenberg, et al.        Expires January 9, 2020               [Page 28]
Internet-Draft                    RIPP                         July 2019

   o  The codec type, which is a fixed property of the byway.  There are
      no payload type numbers in RIPP.

   RIPP does not support gaps in the media sequence due to silence.
   Something must be transmitted for each time interval.  If a RIPP
   implementation wishes to change codecs, it MUST utilize a different
   byway for that codec.

8.7.  Opening Media Byways

   The client bears the responsibility for opening media byways - both
   forward and reverse.  Consequently, the server is strongly dependent
   on the client opening reverse byways; it cannot send media unless
   they've been opened.

   A client MUST open a new forward byway whenever it has a media frame
   to send, all existing forward byways (if any) are in the blocked
   state, and the client has not yet opened 20 byways.

   Furthermore, the client MUST keep a minimum of 10 reverse byways open
   at all times.  This ensures the server can send media.  The client
   MUST open these byways immediately, in parallel.

   The use of multiple media byways in either direction is essential to
   low latency operation of RIPP.  This is because, as describe below,
   media frames are sprayed across these byways in order to ensure that
   there is never head-of-line blocking.  This is possible because, in
   HTTP/3, each transaction is carried over a separate QUIC stream, and
   QUIC streams run on top of UDP.  Furthermore, a QUIC stream does not
   require a handshake to be established - creation of new QUIC streams
   is a 0-RTT process.

   The requests to create these transactions MUST include Cookie headers
   for any applicable session cookies.

   To open a forward media byway, the client MUST initiate a POST
   request to the /media-forward endpoint on the call URI, and MUST
   include a RIPP-Media header field in the request headers.  Similarly,
   to open a reverse media byway, the client MUST initiate a POST
   request to the /media-reverse endpoint of the call URI.  It MUST NOT
   include a RIPP-Media header field in the request headers.  The server
   MUST include the RIPP-Media header in the response headers.  The
   RIPP-Media header contains the properties for the byway - the
   sequence number base, the timestamp base, and the name of the codec.

   RIPP supports multiple audio channels, meant for SIPREC use cases.
   Each channel MUST be on a separate byway.  When multi-channel audio

Rosenberg, et al.        Expires January 9, 2020               [Page 29]
Internet-Draft                    RIPP                         July 2019

   is being used, the client MUST include the multi-channel parameter
   and MUST include the channel number, starting at 1.

   All RIPP implementations MUST support G.711 and Opus audio codecs.
   All implementations MUST support [RFC2833] for DTMF, and MUST support
   [RFC3389] for comfort noise, for both sending and receiving.

   The sequence number space is unique for each direction, channel, and
   call (as identified by the call URI).  Each side MUST start the
   sequence number at zero, and MUST increment it by one for each
   subsequent media frame.  The sequence number base is represented as a
   string corresponding to a 32 bit unsigned integer, and the sequence
   number offset in the media frame is variable length, representing an
   unsigned integer.  Consequently, the sequence number space for a
   media stream within a call has a total space of 32 bits.  With a
   minimum frame size of 10ms, RIPP can support call durations as long
   as 11,930 hours.  Rollover of the sequence number is not permitted,
   the client or server MUST end the call before rollover.  This means
   that the combination of call URI, direction (client to server, or
   server to client), channel number, and sequence number represent a
   unique identifier for media packets.

8.8.  Sending and Receiving Media

   The approach for media is media striping.

   To avoid HOL blocking, we cannot send a second media packet on a
   byway until we are sure the prior media packet was received.  This is
   why the client opens multiple media byways.

   When either the client or server sends a media frame on a byway, it
   immediately marks the byway as blocked.  At that point, it SHOULD NOT
   send another media frame on that byway.  The client or server notes
   the sequence number and channel number for that media frame.  Once it
   receives an acknowledgement for that corresponding media frame, it
   marks the byway as UNBLOCKED.  A client or server MAY send a media
   frame on any unblocked byway.

   The sequence number for the media frame is computed based on the
   rules described above.

   Per the logic described above, the client will open additional byways
   once the number of blocked byways goes above a threshold.  If a the
   number of blocked byways in either direction hits 75% of the total
   for that direction, this is a signal that congestion has occurred.
   In such a case, the client or server MUST either drop packets at the
   application layer, or buffer them for later transmission.  [[TODO:

Rosenberg, et al.        Expires January 9, 2020               [Page 30]
Internet-Draft                    RIPP                         July 2019

   can we play with QUIC priorities to prioritize newer media frames
   over older?]]

   When a client or server receives a media frame, it MUST send an
   acknowledge message.  This message MUST be sent on the same byway on
   which the media was received.  This acknowledgement message MUST
   contain the full sequence number and channel number for the media
   packet that was received.  It MUST also contain the timestamp,
   represented as wallclock time, at which the media packet was
   received.

   If the server has marked 75% of the reverse media byways as blocked,
   it MUST send a signaling event instructing the client to open another
   reverse media byway.  Once this command is received, the client MUST
   open a new reverse byway, unless the total number of byways has
   reached 20.

   A client MAY terminate media byways gracefully if they have not sent
   or received packets on that byway for 5 or more seconds.  This is to
   clean up unused byways.

   There is no need for sender or receiver reports.  The equivalent
   information is knowable from the application layer acknowledgements.

8.9.  Terminating and Re-establishing Connections and Byways

   The state of the connection, the QUIC streams, and byways, is
   separate from the state of the call.  The client MAY terminate an
   HTTP connection or byway at any time, and re-establish it.
   Similarly, the server or client may end the a byway at any time.

   If a byway ends or the connection breaks or is migrated, the client
   MUST re-initiate the byways immediately, or risk loss of media and
   signalling events.  However, to deal with the fact that re-
   establishment takes time, both client and server MUST buffer their
   signalling and media streams for at least 5 seconds, and then once
   the connections and byways are re-established, it sends all buffered
   data immediately.

   Note that it is the sole responsibility of the client to make sure
   byways are re-established if they fail unexpectedly.

8.10.  Signaling - Events

   Signaling is performed by having the client and server exchange
   events.  Each event is a JSON object embedded in the signalling
   stream, which conveys the event as perceived by the client or server.
   Each event has a sequence number, which starts at zero for a call,

Rosenberg, et al.        Expires January 9, 2020               [Page 31]
Internet-Draft                    RIPP                         July 2019

   and increases by one for each event.  The sequence number space is
   unique in each direction.  The event also contains a direction field,
   which indicates whether the event was sent from client to server, or
   server to client.  It also contains a timestamp field, which
   indicates the time of the event as perceived by the sender.  This
   timestamp is not updated when retransmissions happen; the timestamp
   exists at the RIPP application layer and RIPP cannot directly observe
   HTTP retransmits.

   It also contains a call field, which contains the URI of the call in
   question.

   Finally, there is an event type field, which conveys the type of
   event.  This is followed by additional fields which are specific to
   the event type.

   This structure means that each event carried in the signalling is
   totally self-describing, irregardless of the enclosing connection and
   stream.  This greatly facilitates logging, debugging,
   retransmissions, retries, and other race conditions which may deliver
   the same event multiple times, or deliver an event to a server which
   is not aware of the call.

   Events are also defined so that the resulting state is uniquely
   defined by the event itself.  This ensures that knowing the most
   recent event is sufficient to determine the state of the call.

   This specification defines the following events:

   alerting: Passed from server to client, indicating that the recipient
   is alerting.

   accepted: Passed from server to client, indicating that the call was
   accepted.

   rejected: Passed from server to client, indicating that the call was
   rejected by the user.

   failed: Passed from server to client, indicating that the call was
   rejected by server or downstream servers, not by the user, but due to
   some kind of error condition.  This event contains a response code
   and reason phrase, which are identical to the response codes and
   reason phrases in SIP.

   noanswer: Passed from server to client, indicating that the call was
   delivered to the receiving user but was not answered, and the server
   or a downstream server timed out the call.

Rosenberg, et al.        Expires January 9, 2020               [Page 32]
Internet-Draft                    RIPP                         July 2019

   end: initiated by either client or server, it indicates that the call
   is to be terminated.  Note that this does NOT delete the HTTP
   resource, it merely changes its state to call end.  Furthermore, a
   call cannot be ended with a DELETE against the call URI; DELETE is
   not permitted and MUST be rejected by the server.  The call end event
   SHOULD contain a reason, using the Reason codes defined for SIP.

   o  CJ - Not keen on SIP reason codes - they did not conatin enough
      info for all the Q950 stuff and were not particually extensible.
      I think it would be better to define a set here with clear mapping
      to SIP and SIP +Q950 reasons.

   migrate: sent from server to client, it instructs the client to
   terminate the connections and re-establish them to a new URI which
   replaces the URI for the call.  The event contains the new URI to
   use.  This new URI MUST utilize the same path components, and MUST
   have a different authority component.

   open-reverse: sent from server to client, it instructs the client to
   open an additional set of reverse media byways.

   o  CJ - would it work to have this all far simplier and just have the
      trunk cap advertisemtn say how many to open up ?

   tnt: send from consumer to provider, it invokes a takeback-and-
   transfer operation.  It includes the phone number to which the call
   should be transferred.  The provide will then transfer the call to
   the target number.  This event is meant to invoke the feature as it
   has been implemented by the provider.  RIPP does not define
   additional behaviors.

8.11.  Call Termination

   Signaling allows an application layer call end to be sent.  This will
   also cause each side to terminate the the outstanding transactions
   using end flags per HTTP/3 specs.  However, the opposite is not true
   - ending of the transactions or connection does not impact the call
   state.

   A server MUST maintain a timer, with a value equal to one second, for
   which it will hold the call in its current state without any active
   signalling byway.  If the server does not receive a signalling byway
   before the expiration of this timer, it MUST consider the call as
   ended.  Once the call has ended, the call resource SHOULD be
   destroyed.

Rosenberg, et al.        Expires January 9, 2020               [Page 33]
Internet-Draft                    RIPP                         July 2019

   If the server receives a signalling or media byway for a call that is
   TERMINATED, it MUST reject the transaction with an 404 response code,
   since the resource no longer exists.

8.12.  GET Transactions

   A client MAY initiate a GET request against the call URI at any time.
   This returns the current state of the resource.  This request returns
   the most recent event, either sent by the server or received by the
   server.

   o  CJ - lets call this previosEvent as the event part waits till the
      next event on a long poll.  Be good to say something about how
      this is used as it is not clear to me it is needed.

8.13.  Graceful Call Migration: Server

   To facilitate operational maintenance, the protocol has built in
   support for allowing a server instance to drain all active calls to
   another server instance.

   The server can issue a migrate event over the signalling byway, which
   includes a new call URI that the peer should use.  Once received, the
   client closes all transactions to the current call URI.  It then
   establishes new signalling, media and media control byways to the URI
   it just received.  All media that the client wishes to transmit, but
   was unable to do so during the migration, is buffered and then sent
   in a burst once the media byways are re-established.  This ensures
   there is no packet loss (though there will be jitter) during the
   migration period.

   We don't use QUIC layer connection migration, as that is triggered by
   network changes and not likely to be exposed to applications.

8.14.  Graceful Call Migration: Client

   Clients can move a call from one client instance to another easily.
   No commands are required.  The client simply ends the in-progress
   transactions for signalling and media, and then reinitiates them to
   the existing call URI from whatever server is to take over.  Note
   that the client MUST do this within 1s or the server will end the
   call.

8.15.  Ungraceful Call Migration

   Since all media packets are acknowledged at the application layer, it
   is possible for endpoints to very quickly detect remote failures,
   network failures, and other related problems.

Rosenberg, et al.        Expires January 9, 2020               [Page 34]
Internet-Draft                    RIPP                         July 2019

   Failure detection falls entirely at the hands of the client.  A
   failure situation is detected when any one of the following happens:

   1.  The QUIC connection closes unexpectedly

   2.  Any outstanding signalling or media byway is reset by the peer

   3.  No media packets are received from the peer for 1s

   4.  No acknowledgements are received for packets that have been sent
       in the last 1s

   If the client detects such a failure, it MUST abort all ongoing
   transactions to the server, terminate the QUIC connection, and then
   establish a new connection using 0-RTT, and re-establish signalling
   and media transactions.  If this retry fails, the client MUST
   consider the call terminated.  It SHOULD NOT a further attempt to re-
   establish the call.

   o  CJ - Note there is no way to know if it can use 0-RTT or not, all
      depends on cached state so the best it can do is hope it might
      work.

9.  SIP Gateway

   RIPP is designed to be easy to gateway from SIP.  The expectation is
   that RIPP will be implemented in SBCs and softswitches.  A SIP to
   RIPP gateway has to be call-stateful, acting as a B2BUA, in order to
   gateway to RIPP.  Furthermore, a SIP to RIPP gateway has to act as a
   media termination point in SIP.  It has to perform any SRTP
   decryption and encryption, and it must de-packetize RTP packets to
   extract their timestamps, sequence numbers, and codec types.

   SIP to RIPP gateways are not transparent.  SIP header fields which
   are unknown or do not map to RIPP functionality as described here,
   MUST be discarded.

   Any configuration and provisioning for RIPP happens ahead of receipt
   or transmission of SIP calls.  Consequently, the logic described here
   applies at the point that a gateway receives a SIP INVITE on the SIP
   side, or receives a POST to the RIPP trunk URI on the RIPP side.

   This specification does define some normative procedures for the
   gateway function in order to maximize interoperability.

Rosenberg, et al.        Expires January 9, 2020               [Page 35]
Internet-Draft                    RIPP                         July 2019

9.1.  RIPP to SIP

9.2.  SIP to RIPP

10.  RAML API

#%RAML 1.0
---
title: RIPP
baseUri: http://ripp.example.net/{version}
version: v1
protocols: [ HTTPS ]
securedBy: [ oauth_2_0 ]
securitySchemes:
  oauth_2_0: !include securitySchemes/oauth_2_0.raml

types:
    InboundEndpoint:
        type: object
        properties:
            consumerTrunkURI: string
            consumerToken: string
    Event:
        type: object
        properties:
            name:
                enum: [ alerting, accepted, rejected, failed, tnt, migrate, end,open-reverse ]
            direction:
                enum: [c2s, s2c]
            sequence number:
                type: number
            timestamp:
                type: number
            ended:
                type: boolean
            timeStamp:
                type: datetime
            tntDestination:
                type: string
                note: only in events with name tnt
            migrateToURl:
                type: string
                note: only in events with name migrate
     Advertisement:
        type object
        properties:
            max-bitrate: number
            max-samplerate: number

Rosenberg, et al.        Expires January 9, 2020               [Page 36]
Internet-Draft                    RIPP                         July 2019

            max-channels: number
            non-e164: boolean
            force-cbr: boolean
            tnt: boolean
    Frame:
        seqNumOffset: number
        dataLen: number
        data: string
    FrameAck:
        seqNum: number
    BywayPreamble:
        baseSeqNum: number
        baseTime: number
        frameTime: number
        codec:
            enum: [ opus, g711, dtmf, cn, ack ]
     BywayMedia:
        mediaFrames: array

/trunks:
   /{trunkID}:
      /consumerTrunk:
        put:
            description: Set the URI and security token for consumer trunk URI
            securedBy: [oauth_2_0]
      /capAdv:
        get:
            description: Get the Capability Advertisement for this trunk
            securedBy: [oauth_2_0]
            responses:
                200:
                    body:
                         application/json:
                            type: Advertisement
      /calls:
        post:
            queryParameters:
              target:
            securedBy: [oauth_2_0]
            description: Create a new call. Returns a Call URI
            responses:
                202:

/call:
    /{callID}:

Rosenberg, et al.        Expires January 9, 2020               [Page 37]
Internet-Draft                    RIPP                         July 2019

        /prevEvent:
            get:
                description: Retreive the previous event from server
                responses:
                    200:
                        body:
                            application/json:
                                type: Event
        /event:
            get:
                description: Wait for next event then retreive the most recent event from server
                responses:
                    200:
                        body:
                            application/json:
                                type: Event
            put:
                description: Tell server about recent event
                body:
                    application/json:
                        type: Event
                responses:
                    200:
        /media-forward:
            post:
                 description: Starts an infinite flow of media frames from client to server
                 body:
                    application/octet-stream:
                        type: BywayFlow
                 responses:
                    200:
                        application/octet-stream:
                            type: BywayFlow
        /media-reverse:
            post:
                 description: Starts an infinite flow of media frames from server to client
                 body:
                    application/octet-stream:
                        type: BywayFlow
                 responses:
                    200:
                        application/octet-stream:
                            type: BywayFlow

Rosenberg, et al.        Expires January 9, 2020               [Page 38]
Internet-Draft                    RIPP                         July 2019

11.  IANA Considerations

12.  Security Considerations

13.  Acknowledgements

14.  Informative References

   [I-D.ietf-quic-http]
              Bishop, M., "Hypertext Transfer Protocol Version 3
              (HTTP/3)", draft-ietf-quic-http-20 (work in progress),
              April 2019.

   [I-D.ietf-quic-transport]
              Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", draft-ietf-quic-transport-20 (work
              in progress), April 2019.

   [RFC2833]  Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF
              Digits, Telephony Tones and Telephony Signals", RFC 2833,
              DOI 10.17487/RFC2833, May 2000,
              <https://www.rfc-editor.org/info/rfc2833>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <https://www.rfc-editor.org/info/rfc3261>.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              DOI 10.17487/RFC3264, June 2002,
              <https://www.rfc-editor.org/info/rfc3264>.

   [RFC3389]  Zopf, R., "Real-time Transport Protocol (RTP) Payload for
              Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389,
              September 2002, <https://www.rfc-editor.org/info/rfc3389>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <https://www.rfc-editor.org/info/rfc3550>.

   [RFC4855]  Casner, S., "Media Type Registration of RTP Payload
              Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
              <https://www.rfc-editor.org/info/rfc4855>.

Rosenberg, et al.        Expires January 9, 2020               [Page 39]
Internet-Draft                    RIPP                         July 2019

   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
              DOI 10.17487/RFC6265, April 2011,
              <https://www.rfc-editor.org/info/rfc6265>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,
              <https://www.rfc-editor.org/info/rfc7540>.

   [RFC7866]  Portman, L., Lum, H., Ed., Eckel, C., Johnston, A., and A.
              Hutton, "Session Recording Protocol", RFC 7866,
              DOI 10.17487/RFC7866, May 2016,
              <https://www.rfc-editor.org/info/rfc7866>.

   [RFC8224]  Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
              "Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 8224,
              DOI 10.17487/RFC8224, February 2018,
              <https://www.rfc-editor.org/info/rfc8224>.

Authors' Addresses

   Jonathan Rosenberg
   Five9

   Email: jdrosen@jdrosen.net

   Cullen Jennings
   Cisco Systems

   Email: fluffy@iii.ca

   Anthony Minessale
   Signalwire/Freeswitch

   Email: anthm@signalwire.com

   Jason Livingood
   Comcast

   Email: jason_livingood@comcast.com

Rosenberg, et al.        Expires January 9, 2020               [Page 40]