SRTP from RTPEngine with kamailio signalling

[quinn Manchester Symons]

Hi,

I am trying to setup SRTP to flow from the RTPEngine to an oracle SBC. The SBC is setup correctly to receive SRTP and I see in the SDP between them that crypto is being negotiated. The a=media line also includes RTP/SAVP but when performing a wireshark trace I see normal RTP flowing to the SBC.

I've attached the SDP for this call.

Any help would be greatly appreciated.

Thanks very much

[Richard Fuchs]

And what does the other signalling look like? The answer SDP and options in particular.

Cheers

[quinn Manchester Symons]

OPTIONS was not sent in this example. 

This is the SDP from the 200 OK from the SBC

t=0 0 m=audio 29972 RTP/SAVP 111 110 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10;useinbandfec=1 a=rtpmap:110 telephone-event/8000 a=ssrc:2049898032 cname:20498...@redwoodtech.com a=sendrecv a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:8A7BLewWDmTYb1ucLWWw52H1edjxdVubo3+PFpjg
I've also attached a wireshark trace of the call,  

[Richard Fuchs]

On 30/05/2024 10.37, quinn Manchester Symons wrote:

OPTIONS was not sent in this example. 

This is the SDP from the 200 OK from the SBC

t=0 0 m=audio 29972 RTP/SAVP 111 110 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10;useinbandfec=1 a=rtpmap:110 telephone-event/8000 a=ssrc:2049898032 cname:20498...@redwoodtech.com a=sendrecv a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:8A7BLewWDmTYb1ucLWWw52H1edjxdVubo3+PFpjg

I wasn't talking about OPTIONS, I was talking about the options or flags given to rtpengine during handling of the answer.

Cheers

[quinn Manchester Symons]

Oooh, my bad.

When handling the answer we give it these flags to setup the connection between the client and rtpengine.

`trust-address replace-origin replace-session-connection ICE=force RTP/SAVPF SDES-off direction=int direction=ext`

I should give context that the client -> rtpengine connection uses RTP/SAVPF and we had RTPengine converting this to RTP/AVP to send to the SBC, but we want to change it to SRTP on both sides now.

[quinn Manchester Symons]

I'll say looking at this now, I'm realising that we never send an answer with `direction=ext direction=int`. Could this be affecting the behaviour?

[Richard Fuchs]

On 30/05/2024 11.33, quinn Manchester Symons wrote:
> I'll say looking at this now, I'm realising that we never send an
> answer with `direction=ext direction=int`. Could this be affecting the
> behaviour?

Not really. Many flags are optional and unnecessary in answers, and
direction is one of them. The transport protocol is another.

If there's no RTP/AVP in any signalling anywhere, how does your
Wireshark figure it's not SRTP?

Cheers

[quinn Manchester Symons]

I can see that the protocol is RTP instead of SRTP, I've attached a snippet. 

All the RTP lines are going to the SBC or from the SBC, and the SRTP ones are to/from the client.

[quinn Manchester Symons]

That trace was taken on the RTPengine btw

[Richard Fuchs]

On 30/05/2024 12.03, quinn Manchester Symons wrote:
> I can see that the protocol is RTP instead of SRTP, I've attached a
> snippet.
>
> All the RTP lines are going to the SBC or from the SBC, and the SRTP
> ones are to/from the client.

That doesn't answer my question. Wireshark determines whether a stream
is RTP or SRTP from what's in the relevant SDPs. If there's no RTP/AVP
in any SDPs, why would it think it's not SRTP?

Cheers

[Richard Fuchs]

In fact, the screenshot shows that both input and output directions of
the same packet are the same size. SRTP packets are generally larger as
there's an extra authentication tag. The fact that there's no size
difference between input and output packets makes me think it's simply
Wireshark that has falsely classified the packets as RTP instead of SRTP.

Cheers

[quinn Manchester Symons]

Ah very interesting. I'll take a look at this again tomorrow.

Thanks very much for the help today.

[quinn Manchester Symons]

Morning,

I'm convinced that you are completely correct in the fact that wireshark has a bug here.

Thanks very much again for all your support. :)

[Richard Fuchs]

On 31/05/2024 06.31, quinn Manchester Symons wrote:
> Morning,
>
> I'm convinced that you are completely correct in the fact that
> wireshark has a bug here.

FTR, it's not really a bug. SRTP isn't distinguishable from RTP just by
looking at a packet (except in certain cases where you can take an
educated guess). The only way to know for sure whether it's RTP or SRTP
is by having the matching signalling (i.e. the SDPs) available.
Wireshark decodes media as SRTP only if some SDP indicates that it is.
In all other cases (in particular when you manually tell it "decode as
.. RTP") it will assume that it's plain RTP, simply because it cannot
know any better.

Cheers