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

[Jonathan Rosenberg <[e-mail]>]

Hi Eric - thanks for taking the time to read and for the thoughtful
comments.

Responses inline below - but as a high level response - right now we're
less interested in the details of the spec (for which the authors
themselves dont all agree...), but rather to see if there is interest in
solving this problem. The co-authors will be working on prototyping from
here, so if anyone is interested, let us know... goal is working code
before next ietf.


On Sun, Jul 21, 2019 at 6:24 PM Eric Burger <[e-mail]>
wrote:

> 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).
>

Yes, this is very much a pragmatic spec, aimed at solving some very
real-world problems (ie., i've personally been beating my head against the
wall trying to usefully deploy freeswitch within Istio on GKE. Let me know
if you figured it out - its all hard due to how different http is from sip.)



>
>
> 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.
>

Happy to remove later on. Right now its just looknig to motivate the
problem.



>
> 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.
>

Stray word from a few rounds of edits, will remove thx.


>
> 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.
>

No - its not about how well people understand anything. Its about how
applicable modern cloud paas is to SIP and real-time services (which it
really isnt), and how easy it is to build real-time apps which follow
established design patterns for scalable and reliable systems (its super
hard if not impossible).


>
> 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!
>

It mandates passport as the one and only way to even know the caller ID.
COnsequently, the protocol drags stir along for the ride. There is no other
special magic or anything.


>
> 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?
>

I wasn't being specific enough here. "SIP" refers to the whole community of
specs needed for it, and this specific sentence is referring to RTP. I'll
change to RTP.



>
> 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.
>

I dont object - was just trying to start simple and solve one specific
problem well. Do current SIP trunking providers support RTT and video?



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

Bug - thx.


>
> 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.).
>

I would assert that RIPP would be better than SIP today. There is a lot of
SIP trunking out there (note RIPP *only* addresses inter-domain trunking
cases, so thats the point of comparison). Most SIP trunking interconnection
is over private IP with no TLS or SRTP. There is also some over public
Internet, I suspect much of it is without SRTP and probably runs over VPN
often. So, a peering protocol which requires hop encryption of signaling
and media, and actually authenticates both sides, is a big improvement over
the current situation.

E2E encryption isnt really relevant for the applicability of RIPP, since it
is targeted at inter-domain connectivity towards PSTN. PSTN as you well
know has no e2e encryption, and there must be decryption at the pstn
gateway.

I dont follow how having a server at the edge of a provider network might
be in violation of the wiretap act, or somehow make recordings worse. THis
is no different than the situation today with SBCs, where the vast majority
have no SRTP at all, and even those that do, are decrypting so they have
access to the media.




>
> 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.
>

THis is the text:
"The path component MUST

   be a globally unique identifier for this trunk, and not depend on the
   authority component as part of the namespace for purposes of
   uniqueness."


The main motivation is to eliminate the need for wildcard certs to authorize:

https://12345abcdef.ripp-provider.com requires one, whereas:

https://ripp-provider.com/12345abcdef does not


I'll include a mention on that, thanks.





>
> 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?
>

THese are the capabilities of the ripp trunk. These are things normally
configured as capabilities/configuration of sip trunks today. Codecs,
bitrates, etc. They avoid the need for per-call capabilities exchange.
Practically speaking, such exchanges are un-needed since the capabilities
are static properties of the configured sip trunks. Again, we're not
replacing sip overall - just providing a solution for inter-domain peering
for voip to the pstn.



>
> 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?
>

No this is the max codec bitrate, same as current RTP definition. Meant
more for like opus.
The protocol of course is extensible to new codecs - each side advertises
the codecs they support and their associated max rates. If someone however
says they dont want to receive 4000 samples per second, they'd advertise a
lower upper bound. This part is really no different than offer/answer.


>
> 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
>

Cullen was the one who wanted this one - so he's better positioned to speak
to it. There was a study that found you could actually figure out what was
being said just by looking at patterns of lengths of variable bitrate audio
codecs.


>
> 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?
>

Adding http headers is very common for web apps, so this isnt really
different from normal web practice. That said, i dont feel that strongly on
this one. Per above, right now its not so much about the specicic details
of this proposal, as it is a starting point strawman for working on the
problem.



>
> 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?
>

TOtal SWAGs right now - we need some implementation experience to make this
a more usable spec.

Not sure I follow what you mean by speed of light?


>
> 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?
>

We didnt spec out yet what happens if its blocked for a while. This would
happen under significant packet loss, so things are really bad. Probably
drop the call.

Do you care if a packet is lost? in normal voip cases, no. There are some
use cases where the retransmission would be handy (same reason we have an
RTP extension for it..)

On the 1-1 packet:ack - thats a good comment. Definitely a drawback. Would
be better if its piggybacked on reverse media, but we also currently have
reverse media in separate byways. SO thats a tradeoff to be explored.



>
> 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.
>


Rejected is meant to handle the case, like mobile, where the end user
actually hits the decline button.



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

Thanks! Probably not worth fixing till we've gotten more experience under
our belt and revised it to reflect that.




> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>


-- 
Jonathan Rosenberg, Ph.D.
[e-mail]
http://www.jdrosen.net