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]