Closed apsaras closed 5 years ago
This doesn't seem to be related to OpenSIPS, since it doesn't pass anything to rtpengine regarding the SRTP keys - it just sends the SDP body in plain text. Just to double check, can you try to activate debugging in rtpengine and check if the body is received correctly?
Best regards, Răzvan
Yes you are right
Feb 27 18:34:18 esbc rtpengine[3781]: INFO: [5SEcn5l4a9k3YMrvKqj3GQ..]: Received command 'answer' from 127.0.0.1:51868 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Dump for 'answer' from 127.0.0.1:51868: { "sdp": "v=0#015#012o=root 212864899 212864899 IN IP4 192.168.1.15#015#012s=Microbase CommServer#015#012c=IN IP4 192.168.1.15#015#012t=0 0#015#012m=audio 10118 RTP/AVP 9 8 101#015#012a=rtpmap:9 G722/8000#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101 0-16#015#012a=ptime:20#015#012a=sendrecv#015#012", "ICE": "force", "direction": [ "internal", "external" ], "flags": [ "trust-address" ], "replace": [ "origin", "session-connection" ], "transport-protocol": "RTP/SAVP", "call-id": "5SEcn5l4a ... Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: ... 9k3YMrvKqj3GQ..", "received-from": [ "IP4", "192.168.1.15" ], "from-tag": "b7a0fa51", "to-tag": "as4cde2347", "command": "answer" } Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Eliminating asymmetric inbound codec G729/8000 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Default sink codec is G722/8000 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Eliminating asymmetric outbound codec G729/8000 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Creating codec handler for G722/8000 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Sink supports codec G722/8000 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Creating codec handler for PCMA/8000 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Sink supports codec PCMA/8000 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Creating codec handler for telephone-event/8000 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: set FILLED flag for stream 192.168.1.15:10118 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: set FILLED flag for stream 192.168.1.15:10119 Feb 27 18:34:18 esbc rtpengine[3781]: INFO: [5SEcn5l4a9k3YMrvKqj3GQ..]: Replying to 'answer' from 127.0.0.1:51868 (elapsed time 0.001119 sec) Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Response dump for 'answer' to 127.0.0.1:51868: { "sdp": "v=0#015#012o=root 212864899 212864899 IN IP4 1.1.1.1#015#012s=Microbase CommServer#015#012c=IN IP4 1.1.1.1#015#012t=0 0#015#012m=audio 10000 RTP/SAVP 9 8 101#015#012a=rtpmap:9 G722/8000#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101 0-16#015#012a=sendrecv#015#012a=rtcp:10001#015#012a=crypto:9 AES_CM_256_HMAC_SHA1_80 inline:FHiACl7307mrBo1m+ehfNlaL3IGbbcvVS10PK9hCr7fAkL6k49zludbAM8HA2g#015#012a=ptime:20#015#012a=candidate:LMrEXbGChlG7LZGJ 1 UDP 2130706431 185.106.19.5 10000 ... Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: ... typ host#015#012a=candidate:LMrEXbGChlG7LZGJ 2 UDP 2130706430 1.1.1.1 10001 typ host#015#012", "result": "ok" }
If anyone else has the same issue, here is the reply from RTPEngine
Issue was resolved by adding pad-crypto on rtpengine flags
ie
rtpengine_offer(trust-address replace-origin replace-session-connection address-family=IP4 SRTP ICE=force pad-crypto)
Regards
Thanks for the update, @apsaras, I'm glad it sorted out!
Hello
I am configuring a new SBC for TLS to UDP transcoding and I have the following issue.
During SRTP setup, wrong cypto size is sent to the TLS end point.
More specifically, the received key size sent is 45 bytes instead of the required 46 (256 bit key + 112 bit salt = 368/8=46) and thus the negotiation fails.
I am not sure if this is an OpenSIPs issue or RTPEngine. When AES_128 is used instead of AES_256, negotiation works fine.
OS: Centos 7 OpenSIPs: 2.4.3 RTPEngines: 6.5.3