5 Sep
2017
5 Sep
'17
5:08 p.m.
On 05.09.17 16:08, Richard Fuchs wrote:
On 09/05/2017 02:32 AM, Daniel-Constantin Mierla
wrote:
Thanks for the info.
The use case is to do 'best possible' secure communication, in the way
that SRTP is offered, but call should not fail if not supported. Doing
re-routing on 415 could be a solution, however, I met the situation when
the call was accepted but then now audio was heard. It may be a broken
UA after wall.
Anyhow, if it is easy to add and you have some spare time at some point,
it would simplify doing best possible secure session.
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com
Hello,
wondering if anyone has a quick answer to spare some time searching the
web or source code -- is there a way to offer optional SRTP (just SDES
is also fine) in SDP with RTPEngine? The use case is when the target
device is not yet known to support (or not) SRTP.
There are couple of ways in specs or practices (e.g., RFC5939/6871, or
advertising crypto attributes on RTP/AVP stream, or offering two streams
one RTP and one SRTP), I am looking to find if it is possible to do it
with RTPEngine and which of the options are supported/what are the
parameters for doing it...
That's not currently supported (neither as an offerer nor as an
accepter). AFAIK the usual mantra is to offer SRTP first and then
fallback to RTP when a "not supported" (415) is received.
However, it shouldn't be too hard to implement if there's a specific
use case.