Re: [Rum] Let's get into it

Gunnar Hellström <> Tue, 23 July 2019 21:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB16C1202CC for <>; Tue, 23 Jul 2019 14:20:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lNQPC57zYVRe for <>; Tue, 23 Jul 2019 14:20:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B28E1202C3 for <>; Tue, 23 Jul 2019 14:20:47 -0700 (PDT)
X-Halon-ID: b894f67e-ad8f-11e9-bdc3-005056917a89
Received: from [] (unknown []) by (Halon) with ESMTPSA id b894f67e-ad8f-11e9-bdc3-005056917a89; Tue, 23 Jul 2019 23:20:41 +0200 (CEST)
To: "Olle E. Johansson" <>, Brian Rosen <>
References: <> <>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <>
Message-ID: <>
Date: Tue, 23 Jul 2019 23:20:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------6247E26842754230531789EB"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Rum] Let's get into it
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Jul 2019 21:20:52 -0000


I agree with Olle.

For now, just a couple of minor comments.


Section 5. General requirements.

These requirements are not exactly general. Most of them are security 
related. Security interested readers might miss them under the current 

I suggest to make two subsections under 5:

5.1 General security requirements

5.2 General coding requirements

(the last two lines)


Section 8:

"All media streams between the RUE and another endpoint or relay

    Provider MUST be exchanged using the secure real-time transport
    protocol (SRTP) [RFC3550  <>] using DTLS [RFC5763  <>], [RFC5764  <>], except
    that for backwards compatibility with older video endpoints, RTP MAY
    be negotiated if SRTP negotiation fails.

I assume that the reference for SRTP should be RFC 3711.
You may move the reference to RFC 3550 one line forwards, to after RTP.

Good work


Den 2019-07-10 kl. 12:28, skrev Olle E. Johansson:
>> On 9 Jul 2019, at 21:48, Brian Rosen < 
>> <>> wrote:
>> Please comment on anything.
> Section 5:
> "Both HTTPS and all SIP Transactions MUST use TLS 1.2”
> “Transactions” doesn’t work well here. “Connections” would be better.
> Instead of hard-coding a specific version of TLS you may want to point 
> to the BCP by the UTA wg,
> unless you anyway will update this profile from time to time.
> "During the establishment of secure connections with a provider, the
>     RUE MAY be asked by the server for a client certificate.  In that
>     case it SHOULD provide a client certificate.  Providers MAY reject
>     requests that fail to provide a recognized certificate.”
> What’s in the client cert? How do you validate the client certs?
> Section 6 doesn’t mentionSIP over WebSockets. I assume that would apply.
> Since you are using phone numbers as identifiers, I from an EU standpoint
> suggest disallowing all non-secure transports. Phone numbers are
> considered personal identifiers and are affected by the EU GDPR.
> Section 6.2.1 forbids Route headers in initial INVITE requests. The example
> in 6.2.2 has a very visible Route: header in the initial request.
> Section 6.2.3 talks about an xCard without any references or comments
> about trust for that information.
> Section 6.2.4:
> "The RUE MUST accept inbound calls sent to it by the proxy mentioned
>     in the configuration.”
> The proxy is found using DNS and may be a list created from NATPR/DNS SRV
> records. What is the defintion of “the proxy” in this statement?
> "If Multiple simultaneous RUE SIP registrations from different RUE
>     devices with the same SIP URI exist, the Provider MUST parallel fork   the call to all registered RUEs so that they ring at the same time.
>     The first RUE to reply with a 200 OK answers the call and the
>     Provider MUST CANCEL other call branches.
> "
> Is this normative (you have many MUST here). If so - how does this
> change the behaviour of RFC 3261?
> Also, I think this texts forgets about SIP outbound. Since Outbound is a MUST,
> you need to clarify the mix of parallell and serial forking that will happen.
> Section 6.3:
> "The RUE MUST support   REFER to enable call transfer.“
> Which combination of REFER? I assume that “Mid call signaling” is 
> “in-dialog transactions” in SIP lingo,
> but REFER with or without Replaces? With or without subscription for 
> updates?
> Section 6.4:
> "Relay Service URIs and User Address of Records (AoR) MUST resolve (in
>     accord with [RFC3263  <>]) to globally routable IPv4 addresses.  The AoRs
>     MAY also resolve to IPv6 addresses.”
> How do you resolve a complete URI into an IP address? I guess you mean
> the domain part that resolves to a list of addresses using DNS.
> Why is IPv4 a MUST?
> Section 8:
> "All media streams between the RUE and another endpoint or relay
>     Provider MUST be exchanged using the secure real-time transport
>     protocol (SRTP) [RFC3550  <>] using DTLS [RFC5763  <>], [RFC5764  <>], except
>     that for backwards compatibility with older video endpoints, RTP MAY
>     be negotiated if SRTP negotiation fails.
> “
> How do you handle the risk of downgrade attacks here? That exception 
> is dangerous
> and maybe should be handled elsewhere, not in the client.
> Section 11.1
> The example operator URI for 
> <> seems to lack “;user=dialstring”
> Section 11.2
> "outbound-proxies: (OPTIONAL) A list of URIs of SIP proxies to be
>        used when sending requests to the Provider.  Multiple URIs
>        identify alternative (redundant) paths to the Provider.
> “
> Outbound proxy is of course something you look up in DNS to get the 
> list of
> actual servers. Is there a need to have an additional list in this 
> json format?
> "ice-servers” - propably a bad name. I don’t remember seeing “ice 
> server” as a term.
> As turn servers are also STUN servers, I think “turn-servers” is better.
> “credentials”: This is tricky indeed. Sending credentials in clear 
> text like this,
> even if it’s over HTTPS is an interesting approach in this age and time.
> Regardless of that, make sure you consider OAuth/OpenID connect auth
> for some services.
> “lifetime”:; You are really not clear on what happens when the 
> configuration
> expires. Is the RUE forbidden to use anything here? What about 
> emergency calls
> - will they work even without configuration?
> General:
> You do not mention bundling of RTP streams, which may be beneficial here.
> Good work!
> /O
Gunnar Hellström
+46 708 204 288