ASTERISK-20234: SRTP not working with some devices (Eg snom320) - Message "We are requesting SRTP for audio, but they responded without it!"

[Home]

Summary: ASTERISK-20234: SRTP not working with some devices (Eg snom320) - Message "We are requesting SRTP for audio, but they responded without it!"

Reporter: tootai (tootai) Labels:

Date Opened: 2012-08-15 09:05:51 Date Closed: 2012-09-06 17:25:02

Priority: Major Regression?

Status: Closed/Complete Components: Channels/chan_sip/SRTP

Versions: 10.7.0 Frequency of
Occurrence Constant

Related
Issues:
is related to ASTERISK-20194 SRTP: after hold action no audio on holded peer.

is related to ASTERISK-23989 [patch]SDP offer/answer fails if crypto keys added to non-crypto offer

Environment: RHEL5 linux 2.6.18-308.11.1.el5 Attachments: ( 0) ASTERISK-20234_ignore_snom_optional_crypto.patch
( 1) asterisk-20234-sip.conf
( 2) full
( 3) srtp_patches_Asterisk12.diff
( 4) srtp_patches.diff

Description: As you can see, snom 320 (latest stable firmware snom320-SIP 8.7.3.10) is annoncing crypto but asterisk doesn't recognize it.

[Edit by Rusty Newton - removed debug excerpt since full log is now attached]

And call is not accepted

--
Daniel

Comments: By: Matt Jordan (mjordan) 2012-08-15 17:19:05.389-0500

We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Please make sure that 'sip set debug on' is enabled as well.
By: tootai (tootai) 2012-08-17 10:33:52.196-0500

This is the debug file.

--
Daniel
By: tootai (tootai) 2012-08-17 12:13:11.085-0500

I just tested with an asterisk 1.8.15.0 version, same behavior.

--
Daniel
By: Rusty Newton (rnewton) 2012-08-21 09:42:04.425-0500

Tootai, can you also provide a sanitized full sip.conf so we can see the configuration of the users and peers in question?

Please attach as a file to the issue.
By: tootai (tootai) 2012-08-21 12:01:31.766-0500

Hereunder, thanks for your support.

sip.conf:
========

[general]
context=default-SIP
allowoverlap=no
udpbindaddr=0.0.0.0
transport=udp
tcpenable=no
tcpbindaddr=0.0.0.0
srvlookup=yes
disallow=all ; First disallow all codecs
allow=g722
allow=ulaw
allow=alaw
allow=h264
allow=h263p
allow=h263
language=en
videosupport=yes
alwaysauthreject = yes
registerattempts=0 ; try for ever (default=10)
registertimeout=20 ; default

#include local/additional_sip-general.conf

[authentication]

#include local/sip.d/*.conf

additional_sip-general.conf:
===========================

useragent=MYPhone
sdpsession=MYPhone PBX
realm=my.realm.domain
tlsenable=yes
tlsbindaddr=0.0.0.0
tlscertfile=/var/lib/asterisk/keys/local/asterisk.pem
tlscafile=/var/lib/asterisk/keys/local/ca.crt
tlsdontverifyserver=no
tlscipher=ALL
tlsclientmethod=tlsv1

t38pt_udptl = yes,fec
faxdetect = yes

localnet=192.168.7.0/24
externaddr=xxx.xxx.xxx.xxx

nat=yes

peer definition:
===============

[Myphone-spec](!)
accountcode=accphone
secret=<protected>
context=from-Myphone
qualify=5000
busy-level=2
subscribecontext=MyphoneSubscribe
setvar=mySubscriptions=10
setvar=myPrivateEnv=Myphone
setvar=myPrivateVM=no
setvar=myOnNOANSWER=main
;insecure=port,invite

[Myphone-secure](!)
disallow=all
allow=g722,ulaw,alaw
transport=tls
encryption=yes

[myphone115](natted-phone,ulaw-phone,callgroup1,Myphone-spec,Myphone-secure)
defaultuser=Device 115

By: tootai (tootai) 2012-08-21 12:08:37.218-0500

Sorry, didn't saw that you ask for it as attached file.
By: Matt Jordan (mjordan) 2012-08-31 16:31:58.634-0500

Interestingly enough, the reason why this message is getting kicked back is because the phone isn't offering secure audio correctly. The SDP offer provided by the SNOM 320 is offering unsecure audio:

{noformat}
m=audio 49152 RTP/AVP 9 0 8 3 99 108 18 101
{noformat}

The audio format offered by the phone should be "RTP/SAVP".

I'm fully willing to believe that this was not checked in a prior version of 1.8. I'll have to look into how we want to handle this, since the phone itself is not compliant with RFC 4568.
By: tootai (tootai) 2012-09-01 06:52:22.923-0500

Thamks for this feedback.

I send this information on snom forum, hope I will get an answer.

http://forum.snom.com/index.php?showtopic=10381

Daniel
By: Matt Jordan (mjordan) 2012-09-04 13:39:29.652-0500

I've attached a patch that should be tolerant of your particular model of phones. It also contains a few other tweaks to srtp that have caused some folks some other problems.

If you could give this patch a try and test with it (particularly in HOLD/unHOLD scenarios, once you actually get a call up) I'd appreciate it. Thanks!
By: tootai (tootai) 2012-09-05 11:50:21.822-0500

Hi Matt,

I patched the 10.7 version -had to do it manualy- and it works. Will try against the 1.8 server wich is in production. Music on hold as well as transfer are also working.

Thanks for your time.

Daniel
By: Matt Jordan (mjordan) 2012-09-05 12:19:21.731-0500

Hm... I noticed on the SNOM forum that you can configure this properly in the phone. I'm not sure yet if we want to make Asterisk actually ignore the fact the SAVP wasn't specified, since doing so is technically non-RFC compliant behavior, and there is a workaround available in the phone.

Just letting you know that this patch may not get committed in the form that its in, so you may want to configure the phones as opposed to relying on this behavioral change.
By: Matt Jordan (mjordan) 2012-09-06 17:24:34.214-0500

Following up again.

After some further thought, so long as this is configurable in the SNOM phones, I think we're not going to change the behavior in Asterisk.

The concern for me is that we might end up in a situation where some (poorly written) UA sends us an INVITE request with AVP specified and a crypto line, but does *not* intend for us to process the crypto attribute. This would mean we would start to send SRTP to the device, but they would be expecting RTP.

I'm more on the side of thought that says if you want SRTP, you should negotiate for it properly.

You're more than welcome to continue to use this patch if you don't want to configure all of the phones.

If you find out that you cannot configure the SNOM phones to send SAVP, then this becomes a bit of a different issue - there's a common model of phone doing something "wrong", but there is no workaround for it in the phone, and we may want to consider putting the workaround for the behavior in Asterisk instead. If that's the case, please contact a bug marshal in #asterisk-bugs or on the asterisk-bugs mailing list and have them reopen this issue.

Thanks!
By: Alexander Traud (traud) 2014-06-20 15:29:08.059-0500

To add some user-agents affected by this issue:

*Configurable*
* [CSipSimple|https://play.google.com/store/apps/details?id=com.csipsimple] for Android (based on PJSIP)
* CounterPath [Bria Android Edition|https://play.google.com/store/apps/details?id=com.bria.voip]
* CounterPath [Bria iPhone Edition|https://itunes.apple.com/de/app/bria-voip-sip-phone-video/id373968636]
* CounterPath [Bria BlackBerry Edition|http://appworld.blackberry.com/webstore/content/28329074/]
* [Nokia Symbian/S60|http://developer.nokia.com/community/wiki/VoIP_support_in_Nokia_devices#Support_in_Symbian.2FS60_devices] since 2010, for example the Nokia E72

*Non-Configurable*
* [KeyTone Pro|https://play.google.com/store/apps/details?id=com.mocana.keytone]
* [Nokia Symbian/S60|http://developer.nokia.com/community/wiki/VoIP_support_in_Nokia_devices#Support_in_Symbian.2FS60_devices] till 2010
These are mobile phones with a VoIP client which do not get firmware updates anymore, for example the Nokia N86 8MP.

Thank you for this patch! It made those UAs work, regardless of the configuration of these UAs.
By: Alexander Traud (traud) 2014-07-25 01:33:30.977-0500

Although the attached patch still works today, I added a variant for Asterisk 12 which does not raise any questions/warnings by {{patch}}.

Optional SRTP is quite useful in combination with [RFC 3263|http://tools.ietf.org/html/rfc3263] and direct URI calling: The SIP user-agent queries DNS NAPTR to determine which transport is preferred by the SIP proxy (normally TLS over TCP over UDP). Then, the SIP user-agent uses DNS SRV to find the port and server. All this is determined from the domain part of the SIP-URI. In such a case, no outbound proxy is required.

On a SIP user-agent, this RFC allows:
SIP transport: Automatic
Media transport: SRTP preferred

This is not yet supported by Asterisk, but this is the rationale behind automatic/optional on some user-agents; those clients always use the best encryption offered by the remote proxy. If Asterisk is the fall-back outbound proxy for such a client and if Asterisk *requires* encryption, direct URI calling *breaks*.

Therefore, once again, thank you for this patch. With this my SIP user-agents are still able to do direct URI calling, still trying to negotiate TLS/SRTP.
By: Walter Doekes (wdoekes) 2016-07-19 10:26:34.712-0500

For the problem "Failed to receive SDP offer/answer with required SRTP crypto attributes for audio", here's an alternate fix:

the crypto is ignored but the call is not rejected. That keeps behaviour for the SNOM phones as if res_srtp wasn't enabled.

Not sure if it matches the original issue of this through ("*We* are requesting SRTP...").