Cisco SPA112 ver. 1.3.1(003) - Loud noise instead of 'Call Progress Tone' when using TLS/SRTP Secure Calling Mode

[danielr77]

Hello,

I have recently purchased the Cisco SPA112 to take advantage of secure calls using the TLS/SRTP combination. I am using a German provider that supports TLS with SRTP.

Incoming calls work flawlessly.

When I place outgoing calls, the call progress tone sounds like a loud noise which only stops when the remote party picks up. Then, the call is working fine and I can hear the 'Secure Call Indication Tone' three times.

To ensure that this is not a problem at the provider, I have used a soft phone called MicroSIP. I ensured with wireshark that the softphone uses TLS and SRTP in combination and made a test call. The call progress tone using the same account was normal and working fine.

The SPA112 appears to play the stream without de-crypting it, possibly because it doesn't know that the call has started? These are only wild speculations on my end.

I would appreciate any help in this matter,
Daniel Rueppel

[Dan Lukes]

Full syslog&debug messages may help to analyze the issue

Debug and syslog Messages from SPA1x2 and SPA232D ATA (Analog Telephone Adapters)

[danielr77]

Attached is the syslog level 3 for the call to 001 718 362 6705 (New York, USA)

The call progress tone was alike a chainsaw and once the call was answered, the call connected successfully with the SPA indicating a secure call.

I hope some details emerge.

Thank you,
Daniel Rueppel

[Dan Lukes]

It seems you are true, it seems to be another firmware bug. Unfortunatelly, I'm not developper not person authorized to create issues in bug database. Hope that someone else will create the case.  for it.

Let's allow me to higlight relevant parts of your's log only.

-----------------------------------------------

"Session progress" part:

SIP/2.0 183 Session Progress

...

a=sendrecv

a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:Yj+3rllNAUdQ65tnTHBrqodtZaej9+G9TuMyBgub

Jun  2 00:56:24 192.168.1.98 CC_eventProc(), event: CC_EV_SIG_CALL_PROGRESS(0x37), lid: 0, par: 13, par2: (nil)

Jun  2 00:56:24 192.168.1.98 AUD_ccEventProc: event 55 vid 0 par 0xd par2 0x0

Jun  2 00:56:24 192.168.1.98 callEventProcTable[3] is cepCallingProc

Jun  2 00:56:24 192.168.1.98 cepCallingProc(line=0x1f81b0, call=0x1f81b4, event=55(CC_EV_SIG_CALL_PROGRESS), par=13, par2=(nil))

-----------------------------------------------

"Final response" part:

SIP/2.0 200 OK

...

a=sendrecv

a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:Yj+3rllNAUdQ65tnTHBrqodtZaej9+G9TuMyBgub

Jun  2 00:56:38 192.168.1.98 CC_eventProc(), event: CC_EV_SIG_SECURE_PEER(0x3D), lid: 0, par: 13, par2: (nil)

Jun  2 00:56:38 192.168.1.98 AUD_ccEventProc: event 61 vid 0 par 0xd par2 0x0

Jun  2 00:56:38 192.168.1.98 callEventProcTable[4] is cepCallingProc

Jun  2 00:56:38 192.168.1.98 cepCallingProc(line=0x1f81b0, call=0x1f81b4, event=61(CC_EV_SIG_SECURE_PEER), par=13, par2=(nil))

...

Jun  2 00:56:38 192.168.1.98 cepCallingProc(line=0x1f81b0, call=0x1f81b4, event=46(CC_EV_SIG_CALL_RESUMED), par=13, par2=(nil))

...

Jun  2 00:56:38 192.168.1.98 cepCallingProc(line=0x1f81b0, call=0x1f81b4, event=44(CC_EV_SIG_CALL_CONNECTED), par=13, par2=(nil))

-----------------------------------------------

Based on CC_EV_SIG_SECURE_PEER event, it seems that peer has been recognized secure (=encrypted RTP) too late. Encrypted early audio has been processed as unencrypted on receiving side then.

[danielr77]

Hi Dan,

You have done a great job identifying the issue quickly.

There could be an option on the web based interface to encrypt everything without waiting for any events to be triggered first. This is in case there is a valid use case for not activating the encryption right from the beginning.

Hopefully this will be entered as a defect soon.

Best Regards,

Daniel Rueppel

[Dan Lukes]

I either missed your idea or it's not possible at all. Even if you force both parties to use SRTP only (so unencrypted streaming is not possible) you can't start (en|dec)cryption of RTP untill you exchanged the keys with peer (a=crypto ... SDP parameter in your log). So you still need to parse crypto parameters in SDP and use the values accordingly which seems not to work for 183 response now.

[danielr77]

Thank you for your explanation.

Quick update to confirm that issue is also applicable to the latest Firmware: 1.3.2 (014) May  9 2013

Best Regards,

Daniel Rueppel

[MarkT____]

I have just verified this in a test environment and opened case #627120215 with Cisco to see if upcoming 1.3.3 does better.

[MarkT____]

Just to talk to myself here... defect CSCui90759 was filed today for this issue.

[Dan Lukes]

Talking to yourself may be early symptom of schizophrenia. But lying to self is common and reveal no disease.

The URL you mentioned claim "Bug CSCui90759 does not exist" ;-)

[MarkT____]

Dan, I think you have to wait a couple of days for it to appear officially where you can see it.

Obviously not talking to myself at all (heh), and no self-deceit either. Just ahead of everybody else.

Edit: The URL was apparently auto-generated by the forum, I only pasted the defect number.