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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev