Hi Guys,
Anyone from you having the same issue and fixed for this.
We are transferring calls but one way audio, on the asterisk logs shows the error below.
We already checked all the submitted topics here related to this but nothing luck, especially this link below.
Appreciate your response.
chan_h323, chan_sip, or chan_pjsip?
Blind or attended transfer?
Protocol native transfer or Asterisk feature code transfer?
If native blind transfer, does the phone actually implement this as attended?
Are you certain this is not a genuine replay attack?
What do the logs show?
Hi david
We’re using PJSIP, TLS
Doing transfer via softphone button itself and the feature code Blind Transfer ##
Thats all errors the logs shows when initiating transfer to other extensions.
Yes, pretty sure that this is not an attack cause we have seen the error only when initiating transfer call.
Your logging verbosity isn’t high enough.
Hi david
How to elaborate further the logs?
Tried asterisk -rvvvvvvvvvvvvv ( more v but that all the error logs shown)
Any advise?
You want the full log, not the error log. I thought that FreePBX enabled that by default, but look at
Hi david55,
Here is the full logs below. Dailed the number and transfer to other extension number.
What’s the significance of 123.11.22.11. At the moment this looks like an attack from that address, as I don’t see any indication of a call to or from it. Maybe you haven’t consistently redacted?
Also, please take the logs from the log files, not a screen scrape, as the screen scrape lacks time stamps.
You may need to use “pjsip set logger on”, as well, so that one can understand what is happening at the SIP level.
Hi david,
We edited the IPs so we don’t publish our real IPs.
Sure, we will check that one, pjsip set logger on.
Hi david,
How about this logs below. Noticed also that it happens when I received a call and press hold then unhold the audio won’t work (one way audio). On the caller end the audio is working fine.
– PJSIP/5000-00000005 is ringing
> 0x7fcbdc00df60 – Strict RTP learning after remote address set to: 10.6.64.4:5006
– PJSIP/5000-00000005 answered PJSIP/5001-00000004
> 0x7fcbdc040880 – Strict RTP learning after remote address set to: 192.168.1.213:5008
– Channel PJSIP/5000-00000005 joined ‘simple_bridge’ basic-bridge <0a8dba67-3704-4ac5-8279-f8d11f2a4379>
– Channel PJSIP/5001-00000004 joined ‘simple_bridge’ basic-bridge <0a8dba67-3704-4ac5-8279-f8d11f2a4379>
> 0x7fcbdc00df60 – Strict RTP qualifying stream type: audio
> 0x7fcbdc00df60 – Strict RTP switching source address to 122.52.211.51:65422
> 0x7fcbdc040880 – Strict RTP qualifying stream type: audio
> 0x7fcbdc040880 – Strict RTP switching source address to 112.206.240.29:11802
> 0x7fcbdc040880 – Strict RTP learning complete - Locking on source address 112.206.240.29:11802
> 0x7fcbdc00df60 – Strict RTP learning complete - Locking on source address 122.52.211.51:65422
> 0x7fcbdc00df60 – Strict RTP learning after remote address set to: 10.6.64.4:5006
– Started music on hold, class ‘default’, on channel ‘PJSIP/5001-00000004’
> 0x7fcbdc00df60 – Strict RTP learning after remote address set to: 10.6.64.4:5006
– Stopped music on hold on PJSIP/5001-00000004
[2022-05-24 19:18:50] ERROR[10058]: res_stir_shaken.c:1196 ast_stir_shaken_sign: Failed to retrieve certificate for caller ID ‘5001’
[2022-05-24 19:18:50] ERROR[10058]: res_pjsip_stir_shaken.c:414 add_identity_header: Failed to sign STIR/SHAKEN payload
> 0x7fcbdc040880 – Strict RTP learning after remote address set to: 192.168.1.213:5008
== SRTP unprotect failed on SSRC 1280903828 because of authentication failure 10
== SRTCP unprotect failed on SSRC 1280903828 because of authentication failure
== SRTP unprotect failed on SSRC 1280903828 because of authentication failure 160
> 0x7fcbdc00df60 – Strict RTP learning complete - Locking on source address 122.52.211.51:65422
> 0x7fcbdc040880 – Strict RTP learning complete - Locking on source address 112.206.240.29:11802
== SRTP unprotect failed on SSRC 1280903828 because of authentication failure 160
== SRTP unprotect failed on SSRC 1280903828 because of authentication failure 160
== SRTCP unprotect failed on SSRC 1280903828 because of authentication failure
== SRTP unprotect failed on SSRC 1280903828 because of authentication failure 160
== SRTCP unprotect failed on SSRC 1280903828 because of authentication failure
– Channel PJSIP/5000-00000005 left ‘simple_bridge’ basic-bridge <0a8dba67-3704-4ac5-8279-f8d11f2a4379>
– Channel PJSIP/5001-00000004 left ‘simple_bridge’ basic-bridge <0a8dba67-3704-4ac5-8279-f8d11f2a4379>
== Spawn extension (macro-dial-one, s, 55) exited non-zero on ‘PJSIP/5001-00000004’ in macro ‘dial-one’
== Spawn extension (macro-exten-vm, s, 26) exited non-zero on ‘PJSIP/5001-00000004’ in macro ‘exten-vm’
== Spawn extension (ext-local, 5000, 3) exited non-zero on ‘PJSIP/5001-00000004’
– Executing [h@ext-local:1] Macro(“PJSIP/5001-00000004”, “hangupcall,”) in new stack
– Executing [s@macro-hangupcall:1] GotoIf(“PJSIP/5001-00000004”, “1?theend”) in new stack
– Goto (macro-hangupcall,s,3)
– Executing [s@macro-hangupcall:3] ExecIf(“PJSIP/5001-00000004”, “0?Set(CDR(recordingfile)=)”) in new stack
– Executing [s@macro-hangupcall:4] Hangup(“PJSIP/5001-00000004”, “”) in new stack
== Spawn extension (macro-hangupcall, s, 4) exited non-zero on ‘PJSIP/5001-00000004’ in macro ‘hangupcall’
== Spawn extension (ext-local, h, 1) exited non-zero on ‘PJSIP/5001-00000004’
I think you definitely need the pjsip set logger on output. You may need to capture the SRTP outside of Asterisk, as the authenticator is based on the encrypted media, so one cannot validate the authenticator calculation without the secure version of the frame. Actually, I hope that wireshark would be able to validate the authenticators.
Hi david,
Is it safe to share here the .pcap for the logs?
Probably not. In any case, pcaps tend to provide too much data to look at.
The only thing you need from the pcaps are the problem SRTP frames, and you don’t need the IP headers from those, although you should explain what the IPs represent in your network.
The SIP needs to be decrypted, so must come from Asterisk, and, in any case, people are most used to the way that Asterisk logs it.
I don’t know how to do it further to elaborate the logs but it happens only during call either the callee or caller hold the line then going back to the call and one way audio happens, on callee or recipient of the call can’t hear the caller but on the caller end everything works fine.
We see this errors every time we hold and going back to the call and that one way audio happens.
== SRTP unprotect failed on SSRC 1280903828 because of authentication failure 160
== SRTP unprotect failed on SSRC 1280903828 because of authentication failure 160
== SRTCP unprotect failed on SSRC 1280903828 because of authentication failure
== SRTP unprotect failed on SSRC 1280903828 because of authentication failure 160
== SRTCP unprotect failed on SSRC 1280903828 because of authentication failure
Also, this logs below which I think now fixed by updating the asterisk16.x86_64. See Reference
[2022-05-24 19:18:50] ERROR[10058]: res_stir_shaken.c:1196 ast_stir_shaken_sign: Failed to retrieve certificate for caller ID ‘5001’
[2022-05-24 19:18:50] ERROR[10058]: res_pjsip_stir_shaken.c:414 add_identity_header: Failed to sign STIR/SHAKEN payload
The SRTP packets have a cryptographic check sum to protect against, in particular, someone recording earlier media and playing . The error means that that checksum is bad. Personally, the only things I can think of are that you have a genuine replay attack, or you are receiving something which is not actually SRTP. One needs to understand what is going wrong in order to stand a chance of fixing it, and that, I think requires detailed examination of the packets.
Hopefully, if you force the packet type to SRTP, wireshark will check the checksum itself, as otherwise one is going to have to write some code to do that.
The only other guidance I can really give is the comment in the source code that logs this error:
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
