[dispatch] Thoughts on draft-rosenbergjennings-dispatch-ripp-03

[Eric Burger <[e-mail]>]

General: For the most part, I like the idea of a draft that basically says, “we tried to be pure but failed. This proposal is not pure but it for the most part represents running code.” PHB will be happy (ref. the NAT discussion on the IETF list).


Section 1.1: background
Will much of it be meaningful to a protocol implementer in a year, no less five? I.e., referencing Kubernetes, Istio, CanaryDeploys, etc., more especially without going into detail as to what they are? Sure, if you are an AWS developer you know them like the back of your hand. However, not many folks in IETF-land are.

1.2:
Why is it ‘unfortunate’ that people want to deploy cloud applications that interact with the PSTN? Is that not an opportunity? I would take out the initial “Unfortunately.” It’s just a statement of fact that applications like to call and be called to most any person on the planet on a fully interoperable basis.

There needs to be more justification than “Web people don’t understand SIP.” You might want to explain how RIPP is different than ParlayX. I would offer that RIPP:ParlayX::LDAP:X.500, but you don’t say that anywhere. All the draft implies is Web people cannot grok SIP and SIP does not grok Web deployment, which does not reflect well on either community.

The last paragraph of 1.2 implies that SIP is the source of robocalls and a mechanism that will be even easier to inject boatloads of calls will be better. Please explain how this will be so (or remove the assertion). As you know, I personally wish it would be so, so PLEASE give me ammunition!

1.4:
Given the virtual mandate to use SIP over TCP, is saying “we can finally use HTTP over UDP” not kind of a retrograde assertion?

REQ 12 (supporting only audio) is an odd requirement. Moreover, most applications in the U.S. would require at least RTT support if not video. I am not a lawyer, but since we are talking interoperability with the PSTN, one is likely to run into Section 255 and 706 issues if RTT (and video) is not there from day one.

REQ 13 looks totally duplicative of REQ 10 (use secure caller ID technologies). Is there a distinction? If so, please make it clearer

Section 3.6:
This is a place where we need to distinguish between theory and reality. In theory, SIP could provide end-to-end media security. In practice, no one figured it out. The good news is RIPP is no worse than SIP as it is deployed today. Moreover, RIPP is no worse than HTTP. My concern is RIPP structurally will never have end-to-end media security. While that is no worse than today, will we be running into some privacy expectations of users and regulators? For example, a RIPP server can record everything. Problems here are (1) in the U.S. that is likely to be a violation of the Wiretap Act and (2) people can use those recordings for very nefarious purposes (see RealTalk, Lyrebird, etc.).

Section 8.2:
Just curious: why MUST NOT the identifier included the authority component for uniqueness? Is that a Web best practice? A reference or explanation would be helpful.

Section 8.3:
What are the capabilities *of*? Are they codec parameters? Are they decoded stream parameters? Are they codec dependent? Is there any value to these parameters, outside parameterized codec negotiation that I am missing?

For example, is the max-bitrate the decoded maximum bitrate or the bitrate of the codec? What is the purpose?
If I come up with a cool LPC that can do better than G.711 with 4000 samples per section, why cannot I use it?

BIG ONE: force-cbr
Do we require a CBR codec or do we require uniform packet sizes (in bytes)? If the former, why not just ask for a CBR codec in the request. If the latter, change the parameter to something like “require privacy.” There are much better ways of achieving privacy than using a CBR codec; see e.g., https://repository.library.georgetown.edu/handle/10822/1040699 <https://repository.library.georgetown.edu/handle/10822/1040699>

Section 8.4:
I agree with Cullen. It goes against the design principle of using HTTP/3 for transport and then start putting application semantics into the transport layer. Is there a reason to break layers, e.g., for load balancing or something else?

Section 8.7
Why 20 for forward and 10 for reverse? Are these rules of thumb, calculated optimal places to start, SWAGs, or irrelevant?
Also (and in Section 8.8), what about the speed of light and the appearance of blocking?

Section 8.8
Perhaps I missed it, but what happens if a byway appears to be blocked for a ‘while’? Since this is voice and this is UDP and I am tolerant of packet loss, do I care a packet was lost? Also, I’m highly skeptical of 1:1 packet:ack this protocol offers. That sounds like a bad thing for LANs and a terrible thing for WANs. Really?

Section 8.10
I kind of agree with Cullen’s point, but here is an opposite observation that I came up with before I saw Cullen’s point (that SIP result codes don’t cover ISDN). Why have a separate ‘rejected’ result in light of ‘failed.’ Unless rejected is referencing the SIP 607 result code, I would think all the call center cares about is whether the call completed and if it did not, will a retry be likely to succeed or fail.


There are a ton of typos in the draft. I’d be happy to hand my mark-up to whomever wants it in DISPATCH.