Getting 253 exit code for RTP to SRTP call.

[nikhildhupkar]

@jeannotlanglois -

Media is failing with UAC exit code 253 for RTP to SRTP call(only audio)

Please find attached traces and logs in zip file.

1=>Logs for BOTH the SIPP-UAC side AND the SIPP-UAS side - Attached

2=> Additionally I will also ideally need a wireshark capture of both the SIPP-UAC and SIPP-UAS side - attached

SIPP-UAS side pcap file does not show SRTP packets received but RTP engine pcap file shows SRTP packets are sent to UAS sipp.

Below is the UAS sipp-script part as per the PDF document:
a=crypto:[cryptotag1audio] [cryptosuiteaescm128sha1801audio] inline:[cryptokeyparams1audio]

rtp_echo="startaudio,0,PCMU/8000"
rtp_echo="updateaudio,0,PCMU/8000"
rtp_echo="stopaudio,0,PCMU/8000"

When I remove rtp_echo="startaudio/updateaudio/stopaudio" nop blocks from sipp-uas script and replace with below rtp_stream(which is not as per the PDF document), then I can see SRTP packets are being received at UAS-sipp side.
This does not do SRTP-echo but its generating SRTP packets which are being dropped at RTPEngine due to Auth failed error.

rtp_stream="apattern,1,8,PCMA/8000"

Observation - When rtp_echo="startaudio/updateaudio/stopaudio" is used in UAS script RTP engine, SRTP packets are not being received by UAS sipp but when we remove it, SRTP packets are being received by UAS sipp. It means there is no network issue from RTP engine to UAS-sipp machine.

3=> I also need to see the exact command lines that you are using to launch SIPP-UAC and SIPP-UAS (e.g. BOTH sides).

UAS

sipp -i 10.10.14.137 -p 5060 -key account_name sipp-uas.xconnect.lab -key sipp_server_public_ip 54.221.150.22 -sf outbound_call_srtp_uas.xml -rtpcheck_debug -srtpcheck_debug

UAC

sipp -i 10.10.14.202 -p 5030 -m 1 10.10.6.78:5085 -key account_name sipp-uac.xconnect.lab -key called_number +1555333111 -key source_number +12082137662 -key sipp_client_public_ip 98.81.121.17 -sf outbound_call_srtp_uac.xml -rtpcheck_debug -srtpcheck_debug

4=> Finally I will need a quick description of your setup
Below is the setup:
UAC-SIPP(10.10.14.202/98.81.121.17) --> Kamailio/RTPEngine(10.10.14.50/3.215.2.108) --> UAS-SIPP(10.10.14.137/54.221.150.22)

SIPP_RTP_to_SRTP_issue.zip

outbound_call_srtp_uac.xml
outbound_call_srtp_uas.xml

[jeannotlanglois]

@nikhildhupkar :

Alright,
I've finally got some time to look into the traces today. Thanks for providing all the details.

In a few words I see that SIPP is doing what it is told -- but it is told the wrong things in MANY places -- so it is badly misconfigured which leads to an obvious failure.

Additionally, amongst the misconfigurations I see a usage attempt that appears unsupported by SIPP so additional changes might be needed in the setup.

But let's go step by step to begin with.
This might take a few back and forths to get working right.

1. The setup IP addresses specified for the B2BUA Kamailio/RTPEngine are INCORRECT ( they do not match what I see in the wireshark traces which is what represents reality of what happens ).

Those need to be clarified beforehand since the rest of the problems occur in part because of them.

So the correct setup is rather:

UAC-SIPP (those have been correctly specified):
SIP signalling IP:port : 10.10.14.202:5030
RTP streaming IP:port : 98.81.121.17:6000

KAMAILIO B2BUA GW (those have been incorrectly specified):
NOTE: This is a B2BUA GW so there's TWO network interfaces (TWO sides) with TWO IP:port combinations - one on each side:
a) UAC-SIPP-facing-side:
SIP signalling IP:port: 10.10.6.78
RTP streaming IP:port: 3.215.2.108:8858
b) UAS-SIPP-facing-side:
SIP signalling IP:port 52.70.77.181:5062
SRTP streaming IP:port: 3.215.2.108:8838

UAS-SIPP (those have been correctly specified):
SIP signalling IP:Port : 10.10.14.137:5060
SRTP streaming IP:Port: 54.221.150.22:6000

2. Your SIPP command lines contain obvious mismatches with the REAL setup listed above -- I've reformulated their parameters using an order that I'm familiar with to make it easier for me to spot problems:

SIPP-UAC:

./sipp 10.10.6.78:5085 -sf outbound_call_srtp_uac.xml -i 10.10.14.202 -p 5030 -m 1 -rtpcheck_debug -srtpcheck_debug -key account_name sipp-uac.xconnect.lab -key called_number +1555333111 -key source_number +12082137662 -key sipp_client_public_ip 98.81.121.17

There's a number of issues with that command line itself:

a) The target IP:port given ( 10.10.6.78:5085 ) is the UAC-SIPP-facing-side KAMAILIO IP:port -- this is the remote IP:port that SIPP-UAC actually connects to. So the ones you had initially mentioned in your SETUP description were incorrect. That value is the correct one. I've fixed your setup above to match this.

b) The local port to use for SIP signalling ( -p 5030 ) is wrong -- what I see in wireshark is that the value used is 5031 -- so this parameter should rather be "-p 5031".

c) The "-key called_number +1555333111" is wrong - it is missing one digit (probably at the end) -- the North American Dialing Plan specifies that numbers should be 10 digits in length (excluding the international country exit code specified as "+1" here) -- so this string should be a total of 11 digits long -- so you've probably forgot to add an extra "1" at the end -- one correct value for this parameter would rather be: "-key called_number +15553331111".

d) The "-key sipp_client_public_ip 98.81.121.17" represents the IP address you want to use for RTP streaming.

As things stand today I think that this media streaming IP address (currently 98.81.121.17) has to be the same as the SIP signalling IP (10.10.14.202) -- at least I've never got to test whether it works when both the SIP signalling IP and the RTP/SRTP streaming IP addresses are different from each other. So we might have to come back to this later. We'll try to continue with the way you've set things up for now.

If after doing more testing we end up finding that SIPP does not support different values for the SIP signalling + RTP/SRTP streaming you'll have to modify your setup so that they become the same.

The CORRECT SIPP-UAC command line therefore becomes:

./sipp 10.10.6.78:5085 -sf outbound_call_srtp_uac.xml -i 10.10.14.202 -p 5031 -m 1 -rtpcheck_debug -srtpcheck_debug -key account_name sipp-uac.xconnect.lab -key called_number +15553331111 -key source_number +12082137662 -key sipp_client_public_ip 98.81.121.17

SIPP-UAS:

./sipp -sf outbound_call_srtp_uas.xml -i 10.10.14.137 -p 5060 -rtpcheck_debug -srtpcheck_debug -key account_name sipp-uas.xconnect.lab -key sipp_server_public_ip 54.221.150.22

I believe the command line above is probably correct -- however same note as I made above regarding the fact that the SIP signalling IP address (10.10.14.137) is also different from the RTP/SRTP streaming IP address (currently 54.221.150.22) and I'm not 100% positive that SIPP supports this.

Again if after doing more testing we end up finding that SIPP does not support different values for the SIP signalling + RTP/SRTP streaming you'll have to modify your setup so that they become the same.

Also I see that the "-m 1" parameter is missing - let's add it to make sure... so the CORRECT SIPP-UAS command line therefore becomes:

./sipp -sf outbound_call_srtp_uas.xml -i 10.10.14.137 -p 5060 -m 1 -rtpcheck_debug -srtpcheck_debug -key account_name sipp-uas.xconnect.lab -key sipp_server_public_ip 54.221.150.22

3. This statement is incorrect:

but RTP engine pcap file shows SRTP packets are sent to UAS sipp.

If you look closely at the RTP engine PCAP, none of the IP addresses it contains correspond to any of the RTP/SRTP streaming media IPs used by the SIPP-UAC and SIPP-UAS endpoints.

So what the RTP engine pcap shows is misleading and correspond to other traffic not related to yours.

With all the above taken into account, what I see overall on each callleg (e.g. each side of KAMAILIO):

Call Leg "A" (between SIPP-UAC and KAMAILIO's SIPP-UAC-facing side):

• SIPP-UAC is told by KAMAILIO to send RTP packets to 3.215.2.108:8858 ( in the SDP answer of the 200-OK-to-INVITE) so SIPP-UAC does just that.
• SIPP-UAC NEVER receives back any RTP from KAMAILIO -- this is why SIPP-UAC terminates with exit code 253 -- it detects a one-way audio condition ( this is what the RTPCHECK functionality does... it is telling you that something is not happening as expected with the media path ).

Call Leg "B" (between KAMAILIO'S SIPP-UAS-facing side and SIPP-UAS):

• KAMAILIO tells SIPP-UAS to send its SRTP packets to 3.215.2.108:8838 ( in the SDP offer of the INITIAL INVITE ) -- so SIPP-UAS prepares to do that.
• But KAMAILIO NEVER sends any SRTP to SIPP-UAS -- so SIPP-UAS has NOTHING to forward back to KAMAILIO... this is part of the reason why SIPP-UAC in callleg "A" SIPP-UAC exits with error code 253.
• Most importantly - why KAMAILIO never sends SRTP to SIPP-UAS? You'll have to determine why this is happening.

.
.
.

=> I suggest fixing all the configuration errors in the SIPP command lines ( on both sides ) as I've indicated above, then re-run the tests.

=> That would be the first "layer" of problem resolution.

=> Then, the second "layer" of problem resolution will be to figure out why KAMAILIO never seems to send SRTP (to SIPP-UAS) and send RTP (to SIPP-UAC). That part is outside the context of SIPP endpoints so you'll have to troubleshoot this issue with your setup on your own.

=> Finally, the third "layer" of problem resolution will be to determine if SIPP can handle using separate IP addresses for SIP signalling and RTP/SRTP streaming -- if it does then great -- you should have a working setup at this point; but if it doesn't, you'll need to modify your setup so that you use "sipp_client_public_ip" and "sipp_server_public_ip" values that correspond to the same value being used for SIP streaming on each side respectively.

After fixing the first "layer" of problem resolution you can re-run your test and recapture all the same info as initially asked:

a) Quick description of your setup ( in case it has changed to use different IP addresses )
b) Exact SIPP command lines used on both the SIPP-UAC and SIPP-UAS sides
c) Logs for BOTH the SIPP-UAC side AND the SIPP-UAS side
d) Wireshark capture of both the SIPP-UAC and SIPP-UAS side

Regards... :)

[lemenkov]

Likely a SRTP key negotiation problem. Ypu're mentioning "Auth failed" errors at RTPEngine side, which is suggesting key mismatch. This really looks like a configuration/usage issue with SRTP crypto parameters.