Creating SDP with both RTP and SRTP sections

[ydinari]

Hi,
I'd like RTPEngine to rewrite an offer SDP with both RTP and SRTP media sections, because when sending out an INVITE I don't know in advance if the callee supports SRTP or not. Then, according to the response the media connection with that end point will be either RTP or SRTP.
Is there a way to achieve that?
Thanks

[rfuchs]

That's not supported right now. The usual way to do this is to first send an SRTP invite, catch the 488 error response, and then re-send as a plain RTP invite.

[adil-mafzool]

Hi
Well, I need a similar situation where I wish to offer both RTP and SRTP media sections but with incoming SIP INVITE contains RTP only.
Is it be possible to offer the SDP with append SRTP media section based upon RTP media section?
Thanks

[rfuchs]

Sounds like what is described in #432. Not supported right now as I'm not aware of an RFC that describes this usage.

[adil-mafzool]

Well, I understand there is no RFC.
I am trying to achieve SIP forking among RTP and SRTP endpoints.
Doing 488 error response solution works fine as long as all endpoints are either RTP or SRTP but when you have mix the endpoints of RTP and SRTP it doesn't work.

This means I have to put an extra freeswitch server as b2bua before the rtpengine to achieve the above scenario unless you can suggest me some.

[alexcme]

It actually very easy to implement on application level, we do it to convert WebRTC offer (SAVPF) to AVP + SAVP and it works fine:

1. send request to rtpengine to generate AVP offer
2. on receiving response, save it and generate request to generate SAVP offer
3. on receiving response combine both AVP + SAVP send it to destination
4. on receiving answer from destination inspect received media and delete the other one
5. request rtpengine to generate SAVPF answer based on media received

[mbodbg]

I've similar question. If I'm using freeswitch I can just add the option "rtp_secure_media=optional" and I see in the SDP of the INVITE

...
m=audio 30916 RTP/SAVP 102 9 0 8 103 101
...
m=audio 30916 RTP/AVP 102 9 0 8 103 101
...

that both, RTP and SRTP is offered to the client. Is there in the meantime an option to do the same with kamailio+rtpengine? Or is the only way to first offer RTP/SAVP and than handle 415 Unsupported Media Type or 488 Not Acceptable Here responses ?

[rfuchs]

Still not supported by rtpengine, but we do support OSRTP (RFC 8643)

[mbodbg]

Thanks for the answer. Has it just not been implemented yet, or has it not been implemented because it is not really compliant with the RFC? Does anyone know if there is any sample script how OSRTP can be used in a Kamailio script ?

[rfuchs]

Thanks for the answer. Has it just not been implemented yet, or has it not been implemented because it is not really compliant with the RFC?

A little bit of both. I'm reluctant to implement something that looks like a nonstandard hack, especially without knowing what the expected behaviour is supposed to be, and without a way to test it.

Does anyone know if there is any sample script how OSRTP can be used in a Kamailio script ?

I don't have a sample, but it's pretty simple. For an initial offer that is going towards an OSRTP client, use OSRTP=offer. For an offer that is coming from an OSRTP endpoint (or in fact any other offer, as this flag is safe to use in all other cases), use OSRTP=accept

[mbodbg]

Thanks for clarification. So if I understand it correctly, when I put OSRTP=offer I should see in the SDP of the outgoing INVITE (Kamailio-> Zoiper in my case) something like:

...
m=audio 10154 RTP/AVP 8 101
...

but also the crypto-stuff
...
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:gs0Ni+rK55SQeLBTfiVz4QfiTwZJ/pjRg11JZoys
...

I've tested it with version 8.5.4.1, I can see m= ... is set to RTP/AVP, but there are no crypto lines. Are there any additional parameter which matter?

[rfuchs]

No that should be enough. You may have to use OSRTP-offer (dash instead of equals sign) depending on your control module.

[mbodbg]

With OSRTP-offer finally the SDP is as expected, however Zoiper rejects the call also with SIP/2.0 415 Unsupported Media Type when the Zoiper-setting SRTP key negotiation is set to SDES. It seem not support OSRTP.

[rfuchs]

We now support legacy non-RFC "best effort" OSRTP in current master.