[asterisk-dev] DTLS-SRTP SDP correction?

[Joshua Colp]

On 14-01-28 08:25 AM, Daniel Pocock wrote:
> 
> Hi,

Greetings,

> I realize Digium is not necessarily going to fix the DTLS-SRTP issues
> immediately
> 
> However, I think it would be really important to clarify the situation
> with the media sub-field for the protocol, if the current Asterisk
> behavior is not correct, then it would be good to tell people not to try
> and duplicate this behavior in other products that are intended to work
> with Asterisk
> 
> Specifically, Asterisk is expecting "UDP/TLS/RTP/SAVPF" in the protocol
> sub-field of an INVITE message

According to RFC5764 our behavior is correct, specifically the part on
session description:

This specification defines new tokens to describe the protocol used
   in SDP media descriptions ("m=" lines and their associated
   parameters).  The new values defined for the proto field are:

   o  When a RTP/SAVP or RTP/SAVPF [RFC5124] stream is transported over
      DTLS with the Datagram Congestion Control Protocol (DCCP), then
      the token SHALL be DCCP/TLS/RTP/SAVP or DCCP/TLS/RTP/SAVPF
      respectively.

   o  When a RTP/SAVP or RTP/SAVPF stream is transported over DTLS with
      UDP, the token SHALL be UDP/TLS/RTP/SAVP or UDP/TLS/RTP/SAVPF
      respectively.

   The "fmt" parameter SHALL be as defined for RTP/SAVP.

> 
> The RFC 5763 examples seem to show that the INVITE should just say
> "RTP/SAVPF" and the full value of "UDP/TLS/RTP/SAVPF" is only used in
> the SDP sent with a 200 OK response.

The examples are including RFC 5939 (SDP capability negotiation) which
changes things. Asterisk doesn't support this.

Cheers,

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org